背景介绍

早期 Kafka 的定位是一个高吞吐的分布式消息系统，目前则演变成了一个成熟的分布式消息引擎，以及流处理平台。本文主要针对Kafka的架构体系和Kafka消息的订阅和发布进行介绍。

1.afka-定义

Kafka是一个分布式、数据流平台. 具备以下基本能力:

1.发布、订阅消息流；

2.容错方式存储消息流到存储介质；

3.处理即时消息。

2.Kafka-特点

1.解耦：

允许你独⽴的扩展或修改两边的处理过程，只要确保它们遵守同样的接⼝约束。

2.冗余：

消息队列把数据进⾏持久化直到它们已经被完全处理，通过这⼀⽅式规避了数据丢失⻛险。许多消息队列所采⽤的"插⼊-获取-删除"范式中，在把⼀个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从⽽确保你的数据被安全的保存直到你使⽤完毕。

3.扩展性：

因为消息队列解耦了你的处理过程，所以增⼤消息⼊队和处理的频率是很容易的，只要另外增加处理过程即可。

4.灵活性 & 峰值处理能⼒：

在访问量剧增的情况下，应⽤仍然需要继续发挥作⽤，但是这样的突发流量并不常⻅。如果为以能处理这类峰值访问为标准来投⼊资源随时待命⽆疑是巨⼤的浪费。使⽤消息队列能够使关键组件顶住突发的访问压⼒，⽽不会因为突发的超负荷的请求⽽完全崩溃。

5.可恢复性：

系统的⼀部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使⼀个处理消息的进程挂掉，加⼊队列中的消息仍然可以在系统恢复后被处理。

6.顺序保证：

在⼤多使⽤场景下，数据处理的顺序都很重要。⼤部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证⼀个 Partition 内的消息的有序性）。

7.缓冲：

有助于控制和优化数据流经过系统的速度，解决⽣产消息和消费消息的处理速度不⼀致的情况。

8.异步通信：

很多时候，⽤户不想也不需要⽴即处理消息。消息队列提供了异步处理机制，允许⽤户把⼀个消息放⼊队列，但并不⽴即处理它。想向队列中放⼊多少消息就放多少，然后在需要的时候再去处理它们。

3. Kafka-架构图及相关概念

Kafka发送端采用push模式将消息发送到Broker，Kafka消费端采用pull模式订阅并消费信息。如图3.1所示：

$ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-72zRRExF-1591687049866)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps14.jpg)]$
图3.1Kafka-架构图

图3.1大致的工作流程：Kafka集群将 Record 流存储在称为Topic的类别中，每个记录由一个键、一个值和一个时间戳组成。Kafka存储的消息来自任意多被称为Producer生产者的进程，Producer生产的数据会不断追加到该log文件末端，且每条数据都有自己的Offset。数据可以被发布到不同的Topic主题下的不同 Partition分区。在一个分区内，这些消息被索引并连同时间戳存储在一起。被称为Consumer消费者的进程可以从分区订阅消息，消费者组中的每个消费者，都会实时记录自己消费到了哪个Offset，以便出错恢复时，从上次的位置继续消费。目前，Kafka依靠Zookeeper做分布式协调服务，负责存储和管理Kafka集群中的元数据信息，包括集群中的broker信息、topic信息、topic的分区与副本信息等。

4. Kafka-相关术语概念

1.producer：

消息⽣产者，发布消息到 kafka 集群的终端或服务。

2.broker：

kafka 集群中安装Kafka的服务器。

3.topic：

Topic是逻辑上的概念，每条发布到 kafka 集群的消息属于的类别，即 kafka 是⾯向topic的(相当于数据库中的表)

4.partition：

partition是物理上的概念，每个topic包含⼀个或多个 partition。kafka分配的单位是partition。

5.consumer：

从 kafka 集群中消费消息的终端或服务。

6.Consumer group：

high-level consumer API中，每个consumer都属于⼀个consumer group，每条消息只能被

consumer group 中的⼀个 Consumer 消费，但可以被多个consumer group消费。

7.replica：

partition的副本，保障partition的⾼可⽤。

8.leader：

replica中的⼀个⻆⾊，producer和consumer只跟leader交互。

9.follower：

replica中的⼀个⻆⾊，从 leader中复制数据。

10.zookeeper：

kafka 通过zookeeper来存储集群的meta信息。

offset：

偏移量，分区中的消息位置，由Kafka自身维护，Consumer消费时也要保存一份offset以维护消费过的消息位置。Kafka 0.9 版本之前，Consumer默认将Offset保存在Zookeeper中，从0.9 版本开始，Consumer默认将Offset保存在Kafka一个内置的Topic中： __consumer_offsets。

message：

消息，或称日志消息，是Kafka服务端实际存储的数据，每一条消息都由一个key、一个value 以及消息时间戳timestamp组成。

5.Kafka-消息订阅和发布

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PdF5aBet-1591687049867)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps15.jpg)]$

图5.1 Kafka-消息订阅和发布图

图5.1是Kafka消息发布/订阅的基本流程图：一对多，生产者将消息发布到Topic中，有多个消费者订阅该主题，发布到Topic的消息会被所有订阅者消费，被消费的数据不会立即从Topic清除。

5.1.Kafka 消息发送机制

Kafka 生产端发送消息的机制非常重要，这也是Kafka高吞吐的基础，生产端的基本流程如下图所示：

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZwRn93KI-1591687050519)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps16.jpg)] |$

图5.2 Kafka-生产端的基本流程图

图5.2大致过程可以概括为：Kafka自从0.8.2版本就引入了新版本 Producer API，新版Producer完全是采用异步方式发送消息。生产端构建的 ProducerRecord先是经过keySerializer、valueSerializer序列化后，再是经过 Partition 分区器处理，决定消息落到 topic具体某个分区中，最后把消息发送到客户端的消息缓冲池accumulator 中，交由一个叫作Sender的线程发送到broker端。

按照上图所示的流程，消息发送机制的设计主要分为：异步发送、批量发送和消息重试。针对这三个方面的设计有如下简单总结：

1.缓冲池 accumulator的最大大小由参数 buffer.memory 控制，默认是32M，当生产消息的速度过快导致buffer满了的时候，将阻塞 max.block.ms时间，超时抛异常，所以buffer的大小可以根据实际的业务情况进行适当调整。

2.发送到缓冲buffer中消息将会被分为一个一个的batch，分批次的发送到broker端，批次大小由参数 batch.size 控制，默认16KB。一般减小 batch 大小有利于降低消息延时，增加batch大小有利于提升吞吐量。Kafka生产端提供了另一个重要参数 linger.ms，该参数控制了batch 最大的空闲时间，超过该时间的 batch 也会被发送到 broker 端。

3.Kafka生产端支持重试机制，对于某些原因导致消息发送失败的，比如网络抖动，开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries控制，参数含义代表重试次数，默认值为0表示不重试，建议设置大于0比如3。

5.2.Kafka存储机制

在谈论存储机制之前，我们可以了解一下Broker的存储策略，无论消息是否被消费，Kafka都会保留所有消息。有两种策略可以删除旧数据：

\1. 基于时间：log.retention.hours=168

\2. 基于大小：log.retention.bytes=1073741824

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h3DR9ngM-1591687050520)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps17.jpg)] |$

图5.3 Kafka-存储机制的流程图

需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。

图5.3中Topic是逻辑上的概念，而Partition是物理上的概念，由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制。每个Partition分为多个Segment，每个Segment对应两个文件：“.index”索引文件和 “.log”数据文件。

5.3 Kafka分区机制

5.3.1.分区原因

①方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个Topic又可以有多个Partition组成，因此可以以 Partition 为单位读写了。

②可以提高并发，因此可以以Partition为单位读写了。

注：Kafka并不支持读写分区，生产消费端所有的读写请求都是由leader副本处理的，follower副本的主要工作就是从leader副本处异步拉取消息，进行消息数据的同步，并不对外提供读写服务。

5.3.2.分区原则

Kafka 有两种分配策略，一个是RoundRobin(下面会提及到，轮询算法)，一个是 Range，默认为Range(按主题进行分区)，当消费者组内消费者发生变化时，会触发分区分配策略(方法重新分配)。

我们需要将Producer发送的数据封装成一个ProducerRecord对象。该对象需要指定一些参数：

topic：string类型，NotNull。

partition：int 类型，可选。

timestamp：long类型，可选。

key：string类型，可选。

value：string类型，可选。

headers：array类型，Nullable。

①指明Partition的情况下，直接将给定的Value作为Partition的值。

②没有指明Partition但有Key的情况下，将Key的Hash值与分区数取余得到Partition值。

③既没有 Partition 有没有Key的情况下，第一次调用时随机生成一个整数(后面每次调用都在这个整数上自增)，将这个值与可用的分区数取余，得到Partition值，也就是常说的Round-Robin轮询算法。

5.3.3.RoundRobin和Range分区的区别

①RoundRobin

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-X4Fui38T-1591687050522)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps18.jpg)] |$

图5.4 RoundRobin方式分区图

RoundRobin轮询方式将分区所有作为一个整体进行Hash排序，消费者组内分配分区个数最大差别为1，是按照组来分的，可以解决多个消费者消费数据不均衡的问题。

但是，当消费者组内订阅不同主题时，可能造成消费混乱，如图5.5所示，Consumer0订阅主题A，Consumer1订阅主题B。

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gTQaZGCJ-1591687050522)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps19.jpg)] |$

图5.5 RoundRobin方式造成消费混乱图

将A、B主题的分区排序后分配给消费者组，TopicB分区中的数据可能分配到 Consumer0中。

②Range

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-saCWDay6-1591687050523)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps20.jpg)] |$

图5.6 Range方式分区图

Range 方式是按照主题来分的，不会产生轮询方式的消费混乱问题。

但是，如图5.7所示，Consumer0、Consumer1 同时订阅了主题A和B，可能造成消息分配不对等问题，当消费者组内订阅的主题越多，分区分配可能越不均衡。

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6w8oDyYa-1591687050524)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps21.jpg)] |$

图5.7 Range方式消息分配不对等图

5.4.Kafka 副本机制

副本机制也称Replication机制是Kafka实现高可靠、高可用的基础。Kafka中有leader和follower两类副本。

5.4.1.副本的作用

Kafka默认只会给分区设置一个副本，由broker端参数 default.replication.factor 控制，默认值为 1，通常我们会修改该默认值，或者命令行创建 topic 时指定 replication-factor 参数，生产建议设置 3 副本。副本作用主要有两方面：

①消息冗余存储，提高 Kafka 数据的可靠性；

②提高 Kafka服务的可用性，follower副本能够在leader副本挂掉或者broker宕机的时候参与leader选举，继续对外提供读写服务。

5.4.2.读写分离*

上文提及到Kafka不支持读写分区，Kafka 之所以这样设计，主要是为了保证读写一致性，因为副本同步是一个异步的过程，如果当 follower 副本还没完全和leader同步时，从follower副本读取数据可能会读不到最新的消息。

这就涉及到ISR副本同步策略，Kafka为了维护分区副本的同步，引入 ISR（In-Sync Replicas）副本集合的概念，ISR是分区中正在与leader副本进行同步的replica列表，且必定包含leader副本。

ISR 列表是持久化在 Zookeeper 中的，任何在ISR列表中的副本都有资格参与leader选举。

图5.8 Kafka-副本同步策略图

ISR 是动态变化的，所以ISR列表就有为空的时候，ISR为空说明 leader副本也“挂掉”了，此时Kafka 就要重新选举出新的leader。当ISR 为空，就需要Unclean leader选举。Kafka broker端提供了一个参数unclean.leader.election.enable，用于控制是否允许非同步副本参与 leader选举。如果开启Unclean leader选举，可能会造成数据丢失，但可以保证始终有一个leader副本对外提供服务。

这就是典型的CAP理论，即一个系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个。所以在这个问题上，Kafka 赋予了我们选择 C 或 A 的权利。

5.5.Kafka数据可靠性保证

Kafka有ACK机制，为保证Producer发送的数据，能可靠地发送到指定的Topic，Topic的每个Partition收到Producer发送的数据后，都需要向Producer发送ACK(ACKnowledge确认收到)。

如果 Producer收到 ACK，就会进行下一轮的发送，否则重新发送数据。

5.5.1.通过副本同步策略

确保有 Follower与 Leader同步完成，Leader再发送ACK，这样才能保证Leader挂掉之后，能在 Follower中选举出新的 Leader而不丢数据。那么多少个Follower同步完才发送ACK机制，分为：半数以上完成和全部完成，它们的区别主要是延迟和当机器出现故障时所需要的副本数不同。

5.5.2.ISR机制

5.4章节提到过。

5.5.3.ACK应答机制

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的 Follower 全部接受成功。这里主要是设计ACK参数的三种配置0，1和-1：

0：Producer不等待Broker的ACK，这提供了最低延迟，Broker一收到数据还没有写入磁盘就已经返回，当Broker故障时有可能丢失数据。

1：Producer等待 Broker的 ACK，Partition的Leader落盘成功后返回ACK，如果在 Follower 同步成功之前 Leader 故障，那么将会丢失数据。

-1(all)：Producer等待Broker的ACK，Partition的Leader和Follower全部落盘成功后才返回ACK。但是在Broker发送ACK时，Leader发生故障，则会造成数据重复。

5.5.4.故障处理细节

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-soNAlLkb-1591687050526)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps23.jpg)] |$

图5.9 Kafka-LEO\HW位置图

LEO：每个副本最大的 Offset。HW：消费者能见到的最大的Offset，ISR队列中最小的LEO。

Follower 故障：Follower发生故障后会被临时踢出ISR集合，待该 Follower恢复后，Follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步数据操作。

等该Follower的LEO大于等于该Partition的HW，即Follower追上 Leader 后，就可以重新加入 ISR 了。

Leader故障：Leader 发生故障后，会从ISR中选出一个新的 Leader，之后，为保证多个副本之间的数据一致性，其余的Follower会先将各自的 log文件高于HW的部分截掉，然后从新的Leader同步数据。

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

6.[补充]Kafka-控制器介绍

控制器（Controller）是Kafka的核心组件，它的主要作用是在 Zookeeper的帮助下管理和协调整个Kafka集群。集群中任意一个broker 都能充当控制器的角色，但在运行过程中，只能有一个broker成为控制器。

6.1.Zookeeper的Znode节点和Watch机制介绍

控制器的产生依赖于Zookeeper的ZNode模型和Watcher机制。Zookeeper的数据模型是类似Unix操作系统的ZNode Tree即ZNode树，ZNode 是Zookeeper中的数据节点，是Zookeeper存储数据的最小单元，每个 ZNode 可以保存数据，也可以挂载子节点，根节点是 /。基本的拓扑图如图6.1：

$| | || ---- | ------------------------------------------------------------ || | [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WiQq4gok-1591687050527)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps24.jpg)] |$

图6.1 Zookeeper的Znode节点图

Zookeeper有两类ZNode节点，分别是持久性节点和临时节点。持久性节点是指客户端与Zookeeper断开会话后，该节点依旧存在，直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起，客户端与Zookeeper断开会话后，临时节点就会被自动删除。

Watcher 机制是Zookeeper非常重要的特性，它可以在ZNode节点上绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于Zookeeper实现分布式锁、集群管理等功能。

6.2.控制器选举

当集群中的任意broker启动时，都会尝试去Zookeeper中创建 /controller节点，第一个成功创建/controller节点的broker则会被指定为控制器，**其他broker则会监听该节点的变化。**当运行中的控制器突然宕机或意外终止时，其他broker能够快速地感知到，然后再次尝试创建 /controller节点，创建成功的broker会成为新的控制器。

6.3.控制器功能

控制器主要作用是管理和协调Kafka集群，那么Kafka控制器都做了哪些事情呢，具体如下：

主题管理：创建、删除topic，以及增加topic分区等操作都是由控制器执行。

分区重分配：执行Kafka的reassign脚本对topic分区重分配的操作，也是由控制器实现。

Preferred leader选举： Preferred replica即优先副本，表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现leader负载不均衡时，会选择preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。

集群成员管理：控制器能够监控新 broker 的增加，broker的主动关闭与被动宕机，进而做其他工作。这里也是利用前面所说的 Zookeeper的 ZNode模型和Watcher机制，控制器会监听 Zookeeper中/brokers/ids下临时节点的变化。

数据服务：控制器上保存了最全的集群元数据信息，其他所有broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

从上面内容我们大概知道，控制器可以说是Kafka的心脏，管理和协调着整个Kafka集群，因此控制器自身的性能和稳定性就变得至关重要。

社区在这方面做了大量工作，特别是在0.11版本中对控制器进行了重构，其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案，消除了多线程的资源消耗和线程安全问题，另外一个改进是把之前同步操作Zookeeper 改为了异步操作，消除了Zookeeper端的性能瓶颈，大大提升了控制器的稳定性。

7.[补充]Kafka-消费端Rebalance机制

前面介绍消费者术语时，提到了消费组的概念，一个topic可以让若干个消费者进行消费，若干个消费者组成一个Consumer Group即消费组，一条消息只能被消费组中的一个消费者进行消费。我们用图7.1表示Kafka的消费模型。

图7.1 Kafka的消费模型图

7.1.Rebalance概念

就Kafka消费端而言，有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance是让一个消费组的所有消费者就如何消费订阅 topic的所有分区达成共识的过程，在Rebalance 过程中，所有Consumer 实例都会停止消费，等待Rebalance的完成。因为要停止消费等待重平衡完成，因此 Rebalance会严重影响消费端的TPS，是应当尽量避免的。

7.2.Rebalance发生条件

关于何时会发生 Rebalance，总结起来有三种情况：

①消费组的消费者成员数量发生变化

②消费主题的数量发生变化

③消费主题的分区数量发生变化

其中后两种情况一般是计划内的，比如为了提高消息吞吐量增加 topic分区数，这些情况一般是不可避免的，后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的Rebalance。

7.3.Kafka协调器

在介绍如何避免Rebalance问题之前，先来认识下Kafka的协调器 Coordinator，和之前Kafka控制器类似，Coordinator也是Kafka的核心组件。

主要有两类 Kafka 协调器：

①组协调器（Group Coordinator）

②消费者协调器（Consumer Coordinator）

Kafka 为了更好的实现消费组成员管理、位移管理，以及Rebalance 等，broker 服务端引入了组协调器（Group Coordinator），消费端引入了消费者协调器（Consumer Coordinator）。每个 broker 启动的时候，都会创建一个GroupCoordinator实例，负责消费组注册、消费者成员记录、offset等元数据操作，这里也可以看出每个broker都有自己的 Coordinator组件。另外，每个Consumer实例化时，同时会创建一个 ConsumerCoordinator 实例，负责消费组下各个消费者和服务端组协调器之前的通信。可以用图7.2表示协调器原理：

图7.2 Kafka协调器原理图

客户端的消费者协调器Consumer Coordinator和服务端的组协调器 Group Coordinator会通过心跳不断保持通信。

7.4.如何避免消费组Rebalance

接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况，一种是有新的消费者加入，通常是我们为了提高消费速度增加了消费者数量，比如增加了消费线程或者多部署了一份消费程序，这种情况可以认为是正常的；另一种是有消费者退出，这种情况多是和我们消费端代码有关，是我们要重点避免的。

正常情况下，每个消费者都会定期向组协调器 Group Coordinator发送心跳，表明自己还在存活，如果消费者不能及时的发送心跳，组协调器会认为该消费者已经“死”了，就会导致消费者离组引发Rebalance问题。这里涉及两个消费端参数session.timeout.ms和heartbeat.interval.ms，含义分别是组协调器认为消费组存活的期限，和消费者发送心跳的时间间隔，其中heartbeat.interval.ms 默认值是3s，session.timeout.ms在 0.10.1 版本之前默认 30s，之后默认10s。另外，0.10.1版本还有两个值得注意的地方：

从该版本开始，Kafka维护了单独的心跳线程，之前版本中 Kafka 是使用业务主线程发送的心跳。增加了一个重要的参数 max.poll.interval.ms，表示Consumer两次调用pull方法拉取数据的最大时间间隔，默认值5min，对于那些忙于业务逻辑处理导致超过max.poll.interval.ms时间的消费者将会离开消费组，此时将发生一次Rebalance。

此外，如果 Consumer 端频繁FullGC也可能会导致消费端长时间停顿，从而引发 Rebalance。因此，我们总结如何避免消费组Rebalance问题，主要从以下几方面入手：

合理配置session.timeout.ms和heartbeat.interval.ms，建议 0.10.1之前适当调大 session 超时时间尽量规避 Rebalance。根据实际业务调整max.poll.interval.ms，通常建议调大避免Rebalance，但注意0.10.1版本之前没有该参数。监控消费端的GC情况，避免由于频繁FullGC导致线程长时间停顿引发 Rebalance。

合理调整以上参数，可以减少生产环境中Rebalance发生的机率，提升 Consumer端的TPS和稳定性。

x.poll.interval.ms，表示Consumer两次调用pull方法拉取数据的最大时间间隔，默认值5min，对于那些忙于业务逻辑处理导致超过max.poll.interval.ms时间的消费者将会离开消费组，此时将发生一次Rebalance。