消费者组重平衡全流程解析

1.什么是消费者组重平衡
消费者组重平衡的作用就是让组内的所有消费者实例就消费哪些主题分区达成一致。
重平衡需要借助Kafka的broker端的Coordinator 组件，Coordinator在整个重平衡过程中充当协调器，协助消费者组完成重平衡。

2.什么情况下会触发重平衡
·消费者组内成员发生变化
·消费者组订阅的主题数量发生变化
·订阅的主题内的分区数发生变化

一般情况下，第一种情况比较常发生，当我们依次启动消费者组内的消费者实例的时候其实就会触发重平衡。

3.重平衡过程是如何通知到其他消费者实例的呢
是通过消费者端的心跳线程。Kafka的消费者需要定时给broker端的协调者发送心跳请求，以证明它还存活着。原先消费者发送请求是在主线程做到，就是调用poll方法的时候做的，这样有可能因为逻辑处理时间过久，导致在时间内没有发送心跳，broker端误认为该消费者挂掉了，所以后面就单独使用一个线程来发送心跳请求。
重平衡的通知机制就是通过心跳线程来完成的，当broker端的协调者决定开始新一轮的重平衡后，它会将“REBALANCE_IN_PROGRESS”封装进心跳请求的响应中，发还给消费者实例。当消费者实例发现心跳响应中包含了“REBALANCE_IN_PROGRESS”，就能立马知道重平衡又开始了，这就是重平衡的通知机制。
heartbeat.interval.ms这个参数就是配置心跳发送频率的，其实它也是控制重平衡通知的时间。

4.消费者组状态机
Empty：组内没有任何成员，但消费者组可能存在已提交的位移数据，而且这些位移尚未过期。
Dead：同样是组内没有任何成员，但组的元数据信息已经在协调者端被移除了。协调者组件保存着当前向它注册过的所有组信息，所谓的元数据信息就类似于这个注册信息。
PreparingRebalance：消费者组准备开启重平衡，此时所有成员都要重新请求加入消费者组。
CompletingRebalance：消费者组下所有成员已经加入，各个成员正在等待分配方案。
Stable:消费者组的稳定状态，该状态表明重平衡已经完成，组内各成员能够正常消费数据了。

了解了这些状态后，下图展示了状态机的各个状态流转。

需要注意的是，Kafka 定期自动删除过期位移的条件就是，组要处于 Empty 状态。因此，如果你的消费者组停掉了很长时间（超过 7 天），那么 Kafka 很可能就把该组的位移数据删除了。我相信，你在 Kafka 的日志中一定经常看到下面这个输出：

Removed ✘✘✘ expired offsets in ✘✘✘ milliseconds.

这就是 Kafka 在尝试定期删除过期位移。现在你知道了，只有 Empty 状态下的组，才会执行过期位移删除的操作。

4.消费者端重平衡流程
消费者端，重平衡分为两个步骤，分别是JoinGroup请求和SyncGroup请求，当组成员加入组时，它会向协调者发送JoinGroup请求，每个成员都需要将自己订阅的主题上报给协调者，这样协调者就能收集到所有的成员的订阅信息。一旦收集完所有成员的JoinGroup后，协调者就会从这些成员中选择一个成为leader消费者。
这里的leader消费者和副本中的leader副本不是一个概念。这里的leader消费者是为了收集所有的成员订阅信息，然后分配分区的消费策略。通常第一个发送JoinGroup的消费者会成为leader消费者。
选出领导者之后，协调者会把消费者组订阅信息封装进 JoinGroup 请求的响应体中，然后发给领导者，由领导者统一做出分配方案后，进入到下一步：发送 SyncGroup 请求。

leader消费者会向协调者发送SyncGroup请求，请求体中包含了整个消费者组的消费策略，其他消费者也会向协调者发送SyncGroup请求，这不过这个请求并没有包含什么具体信息，为的是协调者给它响应，告诉它具体要消费哪些分区。这样组内的所有成员都可以知道自己该消费哪些分区了。

下面这张图是JoinGroup的过程

JoinGroup 请求的主要作用是将组成员订阅信息发送给领导者消费者，待领导者制定好分配方案后（所有成员都完成入组后，才会选择leader消费者），重平衡流程进入到 SyncGroup 请求阶段。

SyncGroup请求的主要作用就是让协调者把领导者消费者制定的分配方案下发给各个组内成员。当所有成员都成功接收到分配方案后，消费者组进入到Stable状态，开始正常的消费工作。

5.Broker 端重平衡场景剖析

·新成员加入
当有新成员加入组的时候，消费者组状态由Stable变为PreparingRebalance状态，即所有消费者都必须重新入组。当协调者收到新的JoinGroup请求后，会通过心跳请求响应的方式通知组内所有的消费者，强制它们开始新一轮的重平衡。

·组成员主动离组
指消费者实例所在线程或进程调用 close() 方法主动通知协调者它要退出。这个场景就涉及到了第三类请求：LeaveGroup 请求。协调者收到 LeaveGroup 请求后，依然会以心跳响应的方式通知其他成员。

·组成员崩溃离组
崩溃离组是指消费者实例出现严重故障，突然宕机导致的离组。它和主动离组是有区别的，因为后者是主动发起的离组，协调者能马上感知并处理。但崩溃离组是被动的，协调者通常需要等待一段时间才能感知到，这段时间一般是由消费者端参数 session.timeout.ms 控制的。也就是说，Kafka 一般不会超过 session.timeout.ms 就能感知到这个崩溃。
session.timeout.ms这个参数定义了broker端多久没有接收到心跳请求，就开始触发重平衡。

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

最后，kafka在整个重平衡期间都是停止工作的，根据JVM GC的说法就是Stop The World，所以还是尽量避免发生重平衡的情况。