一、重平衡流程介绍
消费者组重平衡的作用就是让消费者组达成一致，完成消费者与哪些主题分区达成一致。重平衡需要借助Kafka broker端的协调者组件，在coordinator的帮助下完成整个消费者分组的分区重分配。
触发与通知
重平衡触发的3个条件
- 消费者组的成员数量变化
- 消费者组的主题数量发生变化
- 消费者组的主题分区数发生变化
其中第一个引起的消费者组重平衡的问题最为常见，即每次有消费者加入或离开消费者组时都会引起重平衡的问题。那么重平衡过程是如何通知到其他消费者实例的呢？答案就是重平衡的心跳机制就是靠消费者端的心跳线程来完成的。
当协调者准备开始新一轮的重平衡时，它会将RELANCE_IN_PROGRESS分装进心跳请求当中，发送给消费者实例，当消费者实例发现心跳响应中有REBLANCE_IN_PROGRESS时就立马知道重平衡要开始了。
二、消费者组状态机
重平衡一旦开始，broker端的协调者组件就要开始帮忙了，主要涉及到控制消费者组的状态流转，当前kafka设计了一个状态机的机制，来协助完成整个重平衡的流程。
1、kafka消费者组的5中状态
kafka为消费者组定义了5中状态，他们分别是，Empty，Dead，PrepareingRebalce，CompletingRebance，Stable，这5种状态的含义：
了解了这些状态图后，再看一下状态的流转图：
这里详细记录一下消费者组启动时的状态流转过程，当一个应用的消费者组未启动时，此时的状态时Empty。当应用启动后，消费者组会通过协调者去确认它订阅的主题信息，协调者告诉所有的消费者加入rebanlace过程，此时消费者组的所有消费者都会加入，最先响应加入的消费者为领导者消费者(leader consumer)，它会自己分配一套分区绑定消费方案然后告诉协调者，协调者在分发给所有的消费者，此时处于Preparing状态，当所有消费者完成信息统一分配后为Completing状态，所有消费者绑定主题分区，开始消费后为Stable状态。
当有新成员加入或已有成员退出时，消费者组的状态从 Stable 直接跳到 PreparingRebalance 状态，此时，所有现存成员就必须重新申请加入组。当所有成员都退出组后，消费者组状态变更为 Empty。Kafka 定期自动删除过期位移的条件就是，组要处于 Empty 状态。只有 Empty 状态下的组，才会执行过期位移删除的操作。
消费者端重平衡流程
有了上面的内容作铺垫，我们就可以开始介绍重平衡流程了。重平衡的完整流程需要消费者端和协调者组件共同参与才能完成。我们先从消费者的视角来审视一下重平衡的流程。
在消费者端，重平衡分为2个步骤，分别是加入组和等待领导者组消费者分配分区方案，这2个步骤对应的请求分别是joingroup和syncgroup请求。
当组内成员加入组时，他会向协调者发送JoinGroup请求。在该请求中，每个成员都要将自己订阅的主题上报，这样协调者就可以收集到所有组员的订阅信息。一旦收集了全部成员的JoinGroup请求后，协调者会从这些成员中选择一个担任这个消费者组的领导者。
通常情况下，第一个发送JoinGroup请求的成员自动成为领导者。这里的消费者领导者和领导者副本不是一个概念。这里的领导者是具体的消费者实例，它既不是副本也不是协调者。领导者消费者的任务是收集所有成员的订阅信息，然后根据这些信息，指定具体的分区消费分配方案。
选出领导者后，协调者会把消费者组的订阅信息分装进JoinGroup请求的的响应体中，然后发给领导者，由领导者统一做出分配方案后，进入下一步：发送SyncGroup请求。
在这一步中，领导者向协调者发送SyncGroup请求，将刚刚分配出的分区方案发给协调者，同时其他的消费者也会向SyncGroup请求，只不过请求体中并没有什么具体的内容，这一步的目的是让协调者接收分配方案，然后统一以SyncGroup响应的方式分发给所有成员，这样组内的所有成员就知道自己该消费分区了
就像之前说的，JoinGroup请求就是为了让所有的消费者将其所订阅的主题等消息发给领导者，待领导者制定好分区方案后，重平衡流程进入到SyncGroup阶段。
SyncGroup 请求的处理流程
SyncGroup 请求的主要目的，就是让协调者把领导者制定的分配方案下发给各个组内成员。当所有成员都成功接收到分配方案后，消费者组进入到 Stable 状态，即开始正常的消费工作。到这里，消费者端的重平衡流程已经结束了。接下来，我们从协调者端来看一下重平衡是怎么执行的。