Kafka消费组重平衡的流程

前面说过了重平衡，它的作用是让组内所有的消费者实例就消费哪些主题分区达成一致。重平衡需要借助 Kafka Broker 端的 Coordinator 组件，在Coordinator 的帮助下完成整个消费者组的分区重分配。在给我们带来的便利和一些问题。这篇来分析一下重平衡的整个流程。
1.触发条件
大体的触发条件有下面三个

1. 组成员数量发生变化。
2. 订阅主题数量发生变化。
3. 订阅主题的分区数发生变化。

• 1
• 2
• 3

上一篇文章也提到过这些。一般对于生产环境来说订阅主题数量发生变化和订阅分区发生变化发生的频率还是比较低的。一般都需要许多的流程你的修改进入生产环境。差不多百分比90的的重平衡都是由1引起的。组内成员发生变化很容易联想到有新的机器加入或者有机器宕机。在上一篇也讲述了还有心跳原因引起的。那么在协调者决定重平衡是怎么通知到消费者的呢。其实靠得也是心跳线程。。当协调者决定开启新一轮重平衡后，它会将“REBALANCE_IN_PROGRESS”封装进心跳请求的响应中，发还给消费者实例。当消费者实例发现心跳响应中包含了“REBALANCE_IN_PROGRESS”，就能立马知道重平衡又开始了，这就是重平衡的通知机制。在kafka 中有一个参数heartbeat.interval.ms前面也介绍过这个是心跳线程的发送间隔时间但是由于重平衡的通知是由心跳线程返回的所以同时也决定者心跳线程的响应时间。如果想消费者更快或者更慢的感知重平衡可以通过调节这个参数。
1.2 消费者组状态机
重平衡一旦开启，Broker 端的协调者组件就要开始忙了，主要涉及到控制消费者组的状态流转。当前，Kafka 设计了一套消费者组状态机，来帮助协调者完成整个重平衡流程。
目前，Kafka 为消费者组定义了 5 种状态，它们分别是：Empty、Dead、
PreparingRebalance、CompletingRebalance 和 Stable。下面用个图片解释下。

了解了这些状态的含义之后，我们来看一张图片，它展示了状态机的各个状态流转。

稍微解释下一个消费者组最开始是 Empty 状态，当重平衡过程开启后，它会被置于 PreparingRebalance 状态等待成员加入，之后变更到CompletingRebalance 状态等待分配方案，最后流转到 Stable 状态完成重平衡。
当有新成员加入或已有成员退出时，消费者组的状态从 Stable 直接跳到
PreparingRebalance 状态，此时，所有现存成员就必须重新申请加入组。当所有成员都退出组后，消费者组状态变更为 Empty。Kafka 定期自动删除过期位移的条件就是，组要处于 Empty 状态。因此，如果你的消费者组停掉了很长时间（超过 7 天），那么 Kafka 很可能就把该组的位移数据删除了。这就是 Kafka 在尝试定期删除过期位移。只有 Empty 状态下的组，才会执行过期位移删除的操作。
1.3 消费者端重平衡流程
重平衡的完整流程需要消费者端和协调者组件共同参与才能完成。我们先从消费者的视角来审视一下重平衡的流程。在消费者端，重平衡分为两个步骤：分别是加入组和等待领导者消费者（LeaderConsumer）分配方案。这两个步骤分别对应两类特定的请求：JoinGroup 请求和SyncGroup 请求。当组内成员加入组时，它会向协调者发送 JoinGroup 请求。在该请求中，每个成员都要将自己订阅的主题上报，这样协调者就能收集到所有成员的订阅信息。一旦收集了全部成员的JoinGroup 请求后，协调者会从这些成员中选择一个担任这个消费者组的领导者。通常情况下，第一个发送 JoinGroup 请求的成员自动成为领导者。你一定要注意区分这里的领导者和之前我们介绍的领导者副本，它们不是一个概念。这里的领导者是具体的消费者实例，它既不是副本，也不是协调者。领导者消费者的任务是收集所有成员的订阅信息，然后根据这些信息，制定具体的分区消费分配方案。选出领导者之后，协调者会把消费者组订阅信息封装进 JoinGroup 请求的响应体中，然后发给领导者，由领导者统一做出分配方案后，进入到下一步：发送 SyncGroup 请求。在这一步中，领导者向协调者发送 SyncGroup 请求，将刚刚做出的分配方案发给协调者。值得注意的是，其他成员也会向协调者发送SyncGroup 请求，只不过请求体中并没有实际的内容。这一步的主要目的是让协调者接收分配方案，然后统一以 SyncGroup 响应的方式分发给所有成员，这样组内所有成员就都知道自己该消费哪些分区了。
接下来，我用一张图来形象地说明一下 JoinGroup 请求的处理过程

就像前面说的，JoinGroup 请求的主要作用是将组成员订阅信息发送给领导者消费者，待
领导者制定好分配方案后，重平衡流程进入到 SyncGroup 请求阶段。
下面这张图描述的是 SyncGroup 请求的处理流程。

SyncGroup 请求的主要目的，就是让协调者把领导者制定的分配方案下发给各个组内成
员。当所有成员都成功接收到分配方案后，消费者组进入到 Stable 状态，即开始正常的消费工作。讲完这里，消费者端的重平衡流程我已经介绍完了。接下来，我们从协调者端来看一下重平衡是怎么执行的。
1.4 Broker 端重平衡场景剖析
要剖析协调者端处理重平衡的全流程，我们必须要分几个场景来讨论。这几个场景分别是新成员加入组、组成员主动离组、组成员崩溃离组、组成员提交位移。接下来，我们一个一个来讨论。
1.4.1 ：新成员入组。
新成员入组是指组处于 Stable 状态后，有新成员加入。如果是全新启动一个消费者组，
Kafka 是有一些自己的小优化的，流程上会有些许的不同。我们这里讨论的是，组稳定了之后有新成员加入的情形。当协调者收到新的 JoinGroup 请求后，它会通过心跳请求响应的方式通知组内现有的所有成员，强制它们开启新一轮的重平衡。具体的过程和之前的客户端重平衡流程是一样的。现在，我用一张时序图来说明协调者一端是如何处理新成员入组的。

1.4.2：组成员主动离组。
何谓主动离组？就是指消费者实例所在线程或进程调用 close() 方法主动通知协调者它要退出。这个场景就涉及到了第三类请求：LeaveGroup 请求。协调者收到 LeaveGroup 请求后，依然会以心跳响应的方式通知其他成员，因此我就不再赘述了，还是直接用一张图来说明.

1.4.3 组成员崩溃离组
崩溃离组是指消费者实例出现严重故障，突然宕机导致的离组。它和主动离组是有区别的，因为后者是主动发起的离组，协调者能马上感知并处理。但崩溃离组是被动的，协调者通常需要等待一段时间才能感知到，这段时间一般是由消费者端参数 session.timeout.ms 控制的。也就是说，Kafka 一般不会超过 session.timeout.ms 就能感知到这个崩溃。当然，后面处理崩溃离组的流程与之前是一样的，我们来看看下面这张图。

1.4.4 重平衡时协调者对组内成员提交位移的处理
正常情况下，每个组内成员都会定期汇报位移给协调者。当重平衡开启时，协调者会给予成员一段缓冲时间，要求每个成员必须在这段时间内快速地上报自己的位移信息，然后再再开启正常的 JoinGroup/SyncGroup 请求发送。我们使用一张图来说明.

1.5 小结
本篇主要介绍了4块
(1) .触发条件: 组成员数量发生变化, 订阅主题数量发生变化，订阅主题的分区数发生变化。
(2) .5种状态Empty、Dead、PreparingRebalance、CompletingRebalance 和 Stable
(3) 重平衡步骤：加入组和等待领导者消费者 分别对应joinGroup 和syncGroup
(4) 重平衡场景：分别是 新成员入组，组成员主动离组，组成员崩溃离组，重平衡时协调者对组内成员提交位移的处理*