kafka生产者与消费者详细架构

参考链接：

https://blog.csdn.net/LeoHan163/article/details/105902707

https://developer.aliyun.com/article/763602

1、生产者工作流程

在生产者将消息发送出去之前，需要经历拦截器（Interceptor）、序列化器（Serializer）和分区器（Partitioner）等一系列的作用，随后才真正进入发送消息发送流程。

整个生产者客户端由两个线程协调运行，这两个线程分别为主线程和Sender线程（发送线程）。在主线程中由KafkaProducer创建消息，然后通过可能的拦截器、序列化器和分区器的作用之后缓存到消息累加器（RecordAccumulator，也称为消息收集器）中。Sender线程负责从RecordAccumulator中获取消息并将其发送到Kafka中。

根据上图，我们可以将生产者工作流程分为以下几步：

步骤一：一条消息过来首先会被封装成为一个 ProducerRecord 对象。

步骤二：接下来要对这个对象进行序列化，因为 Kafka 的消息需要从客户端传到服务端，涉及到网络传输，所以需要实现序列。Kafka 提供了默认的序列化机制，也支持自定义序列化（这种设计也值得我们积累，提高项目的扩展性）。

步骤三：消息序列化完了以后，对消息要进行分区，分区的时候需要获取集群的元数据。分区的这个过程很关键，因为这个时候就决定了，我们的这条消息会被发送到 Kafka 服务端到哪个主题的哪个分区了。

步骤四：分好区的消息不是直接被发送到服务端，而是放入了生产者的一个缓存里面。在这个缓存里面，多条消息会被封装成为一个批次（batch），默认一个批次的大小是 16K。

步骤五：Sender 线程启动以后会从缓存里面去获取可以发送的批次。

步骤六：Sender 线程把一个一个批次发送到服务端。大家要注意这个设计，在 Kafka0.8 版本以前，Kafka 生产者的设计是来一条数据，就往服务端发送一条数据，频繁的发生网络请求，结果性能很差。后面的版本再次架构演进的时候把这儿改成了批处理的方式，性能指数级的提升，这个设计值得我们积累。

2、生产者分区

根据之前的描述，我们知道生产者得到的消息最终是以分区为分类的，那么为什么要使用分区，以及使用分区有什么好处呢？

①使用分区的原因

（1）方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了；

（2）可以提高并发，因为可以以 Partition 为单位读写了，在之前我们聊到过，消费者其实是以分区为消费对象的，因为如果一个消费者组消费一个topic，没有必要消费者组中每个消费者都要得到所有消息，只需要这个消费者组得到就行，那么如何将消息平均发送给消费者组中的消费者，那么就是利用分区。

②分区分配策略

一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及到 partition 的分配问题，即确定那个 partition 由哪个 consumer 来消费。Kafka 有两种分配策略，一是 RoundRobin，一是 Range。

（1）RoundRobin分区分配策略

将每个topic中的分区进行排序，然后按照轮询的方式给每个consumer分配分区

注：是每个topic都按上述过程分配一遍，而不是所有topic加起来排序再分配

（1）Range分区分配策略

如图我们可以发现，range分配是按一个范围一个范围的分，即先将所有分区数除以consumer个数，然后按范围分配

③如何判断一个消息要传到那个分区中

首先我们知道一个消息传到生产者处时会封装成 ProducerRecord 对象。

下面我们根据api中相应的函数来说明一下kafka是如何判断一个消息是要传到那个分区中的：

（1）指明 partition 的情况下，直接将指明的值直接作为 partiton 值，传到对应partition分区中；

（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition数进行取余得到 partition 值；

（3）既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition值，也就是常说的 round-robin 算法。

3、数据可靠性保证

为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。

我们知道，kafka为了保证数据真正落实到partition和follower，引入了ack机制，即如果我返回ack即我同步成功，那么你就可以继续下一条消息的同步了。

然后根据kafka的follower，我们有以下两种确认机制

Kafka 选择了第二种方案，原因如下：

1.同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1个副本，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。

2.虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。

但kafka并不是完全按照第二种方法来的，因为kafka需要面对的是大数据，高同步、高并发，所以有没有什么折中的优化方法呢？

首先我们看一下第二种方法会产生什么问题

采用第二种方案之后，设想以下情景：leader 收到数据，所有 follower 都开始同步数据，但有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去，直到它完成同步，才能发送 ack。这个问题怎么解决呢？

这时候就引入了kafka的一个重要的数据结构：ISR

Leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集合。当 ISR 中的 follower 完成数据的同步之后，leader 就会给 follower 发送 ack。如果 follower长时间 未 向 leader 同 步 数 据 ， 则 该 follower 将 被 踢 出 ISR ， 该 时 间 阈 值 由replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR 中选举新的 leader。

所以ISR的作用就是选出同步最快，延迟最低的一些broker集合，然后，全部同步的范围也只是ISR中的主机，这样既提高了安全性，也提高了数据处理速度

4、ack应答机制

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 follower 全部接收成功。

所以 Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置：

acks 参数配置：

acks：

0：producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟，broker 一接收到还没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据；

1：producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么将会丢失数据；

5、故障处理细节

根据之前的配置，我们很可能得到这样的数据，即leader与各个follower中的消息条数不一样，那么若leader突然挂掉了，如何处理？

LEO：指的是每个副本最大的 offset；

HW：指的是消费者能见到的最大的 offset，ISR 队列中最小的 LEO。

（1）follower 故障

follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

6、Exactly Once语义

将服务器的 ACK 级别设置为-1，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。相对的，将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被发送一次，即 At Most Once 语义。

At Least Once 可以保证数据不丢失，但是不能保证数据不重复；相对的，At Least Once 可以保证数据不重复，但是不能保证数据不丢失。但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即 Exactly Once 语义。在 0.11 版本以前的 Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。

0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据，Server 端都只会持久化一条。幂等性结合 At Least Once 语义，就构成了 Kafka 的 Exactly Once 语义。即：

At Least Once + 幂等性 = Exactly Once

要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而Broker 端会对做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。

但是 PID 重启就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区跨会话的 Exactly Once。

7、kafka消费者

consumer 采用 pull（拉）模式从 broker 中读取数据。

push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。

pull 模式不足之处是，如果 kafka 没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费，consumer 会等待一段时间之后再返回，这段时长即为 timeout。

8、offset

由于 consumer 在消费过程中可能会出现断电宕机等故障，consumer 恢复后，需要从故障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢 复后继续消费。

Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始，consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为__consumer_offsets。