Kafka简介

一、作用
1. 解耦。避免了消费者和生产者之间的耦合
2. 消峰限流。能够有效的降低消费者的负载量
3. 持久化存储

二、概述
1. Kafka是发布订阅模式的消息队列
2. Kafka是由LinkedIn（领英）公司开发后来贡献给了Apache的消息队列
3. Kafka的特征：
a. 发布和订阅消息流
b. 在存储消息流的时候要提供容错机制
c. 当数据流出现的时候能够及时处理
4. Kafka的应用场景：
a. 能够在系统或者应用之间构建可靠的数据传输的实时流管道
b. 能够构建一个转化或者应对数据流的实时流应用
5. Kafka是利用了Scala语言构建的，Scala天然支持并发和吞吐，保证Kafka的并发量和吞吐量是比较高的，实际过程中，Kafka的吞吐量是在60~80M/s - Kafka底层采用了零拷贝的技术
6. Kafka在收到数据之后会把数据写入本地磁盘上保证数据不丢失。默认情况下，Kafka不会清理写入的数据
7. Kafka中不存在单点故障
a. Kafka集群中可以随时动态增删节点
b. Kafka中存在副本策略

三、基本概念
1. broker：
a. 就表示Kafka中的节点
b. 每一个broker都需要给一个编号，这个编号只要不相同的就可以

2. topic：
a. 作用是用于对数据进行分类的
b. 在Kafka中，每一条数据都要发送到一个指定主题中
c. 每一个主题对应一个到多个partition
d. 当删除主题的时候，这个主题所对应的目录并不会被立即删除，而是被标记为删除状态，等待一分钟左右会将标记的目录删除
e. 如果需要删除操作立即生效，需要将delete.topic.enable设置为true

3. partition：
a. 每一个partition对应一个目录
b. 如果有多个Kafka节点，分区会平均分到每一个节点上，这样设计的目的是为了提高Kafka的吞吐量
c. 如果出现了多个分区，则数据在向分区中写入的时候是轮训写入

4. replicas：
a. Kafka中，为了保证数据的可用，可以去设置多个副本
b. 如果设置了多个副本，则副本是以分区为单位进行备份

5. leader和follower
a. 在Kafka中，如果设置了多个副本，则副本之间会自动通过Controller进行选举，选举出一个leader副本以及其他的follower副本
b. 注意：leader和follower是指的副本之间的主从关系而不是Kafka节点之间的主从关系
c. Producer和Consumer只和leader副本进行交互，不会和follower副本进行交互

6. Controller：
a. 用于进行leader副本和follower副本的选举
b. Controller会在某一个Kafka节点上
c. 如果Controller宕机，那么Zookeeper会在其他的Kafka节点上再来启动一个Controller进程

7. Consumer Group：
a. 默认情况下，每一个消费者对应一个消费者组
b. 一个消费者组中可以包含1个到多个消费者
c. 同一条消息可以被不同的消费者组订阅，但是同一个组内的消费者只能有一个去消费这个消息 - 组间共享，组内竞争

四、指令

五、数据同步
1. 生产者将数据写到leader副本上
2. follower副本会给leader发送消息询问是否有需要更新的数据
3. leader会把需要更新的数据发送给follower，并且等待follower的反馈
4. 如果follower记录成功，则返回一个ack信号
5. leader收到ack之后，会把follower副本所在的brokerid放入ISR队列中
ISR是维系在Zookeeper上的，一旦leader副本lost，则Controller会优先从ISR中选择一个副本成为leader

六、语义
在一个分布式发布订阅消息系统中，组成系统的计算机总会由于各自的故障而不能工作。在Kafka中，一个单独的broker，可能会在生产者发送消息到一个topic的时候宕机，或者出现网络故障，从而导致生产者发送消息失败。根据生产者如何处理这样的失败，产生了不同的语义：
a. 至少一次语义（At least once semantics）：如果生产者收到了Kafka broker的确认（acknowledgement，ack），并且生产者的acks配置项设置为all（或-1），这就意味着消息已经被精确一次写入Kafka topic了。然而，如果生产者接收ack超时或者收到了错误，它就会认为消息没有写入Kafka topic而尝试重新发送消息。如果broker恰好在消息已经成功写入Kafka topic后，发送ack前，出了故障，生产者的重试机制就会导致这条消息被写入Kafka两次，从而导致同样的消息会被消费者消费不止一次。每个人都喜欢一个兴高采烈的给予者，但是这种方式会导致重复的工作和错误的结果
b. 至多一次语义（At most once semantics）：如果生产者在ack超时或者返回错误的时候不重试发送消息，那么消息有可能最终并没有写入Kafka topic中，因此也就不会被消费者消费到。但是为了避免重复处理的可能性，导致接受有些消息可能被遗漏处理
c. 精确一次语义（Exactly once semantics）：即使生产者重试发送消息，也只会让消息被发送给消费者一次。精确一次语义是最令人满意的保证，但也是最难理解的。因为它需要消息系统本身和生产消息的应用程序还有消费消息的应用程序一起合作。比如，在成功消费一条消息后，又把消费的offset重置到之前的某个offset位置，那么将收到从那个offset到最新的offset之间的所有消息。这解释了为什么消息系统和客户端程序必须合作来保证精确一次语义