这是我参与11月更文挑战的第22天，活动详情查看：2021最后一次更文挑战
相关：Kafka 中的消费者组 ｜ Kafka 之如何避免 Rebalance
Rebalance 的触发
之前的文章介绍了 Rebalance 触发的三大类情况，即主题发生变化、主题分区发生变化、消费者组成员发生变化。其中，实际生产中消费者组成员变化导致的 Rebalance 是最常见的，消费者组成员的依次启动也属于这种情况。
本文主要讨论消费者组成员发生变化时，Rebalance 的详细过程。
协调者
在 Rebalance 的过程，不仅需要消费者组内成员的相互协调，还需要一个叫做「协调者」的角色参与。
协调者，也叫做 Coordinator，它是一个专门为消费者群提供服务的角色，主要负责 Rebalance 的执行、位移管理、组成员管理等。
协调者存在于 Broker 中，每个消费者实例都有其对应的协调者，消费者实例在启动、提交位移等操作时，其实都是在向它对应的协调者所在的 Broker 发送请求。
消费者实例如果找到自己的协调者对应的 Broker 呢？前面我们说过，消费者实例的位移信息保存在 Kafka 内部创建的位移主题中，先找到当前消费者组的数据保存在位移主题的那个分区中，该分区的 Leader Replica 副本所在的 Broker 就是对应的协调者所在的 Broker。
消费者组的几种状态
了解了协调者这个角色，接下来介绍，协调者在管理消费者组成员的时候，会对消费者组标定状态。在协调者的视角，消费者组一共有 5 种状态：
Empty：表示组内没有任何成员，但可能存在已经提交的位移数据，而且这些数据还没有过期。Dead：表示组内没有任何成员，而且元信息已经被移除。PreparingRebalance：表示准备开始 Rebalance，所有消费成员都需要重新向协调者请求加入消费者组。CompletingRebalance：表示所有的成员已经重新加入消费者组，正在等待分配方案。Stable：表示稳定状态，也就是完成 Rebalance 后可以正常消费数据的状态。
他们的关系如下图：
Rebalance 的过程
当消费者组处于 Stable 状态时，消费者实例会定期向协调者发送心跳通知，起作用就是告诉协调者实例在正常运行，当有新成员计入、成员主动离开、成员失联被动离开的场景下，协调者会通过响应心跳请求的方式，告诉所有实例，要进行 Rebalance 了。
我们分别梳理一下协调者发起新一轮 Rebalance 前，这三种情况的流程。
- 第一种，当有新的实例加入的时候，新加入的实例会向协调者发送 JoinGroup 请求，协调者收到后，会向所有实例响应新一轮 Rebalance 开始的信息。
- 第二种，当有成员主动离开消费者组，离组的成语啊你会向协调者发送 LeaveGroup 的请求，协调者收到后，会向所有实例响应新一轮 Rebalance 开始的信息。
- 第三种，协调者没有在规定时间内接收到某个成员的心跳通知，那么这个成员会被踢出消费者组，测试，协调者会向所有实例响应新一轮 Rebalance 开始的信息。
以上所说的开始新一轮 Rebalance 的信息，其实就是在心跳请求的响应中，告诉成员：Rebalance 要开始了，请重新申请加入消费者组。成员收到后，会重新发送 JoinGroup 请求。
当协调者收到所有成员的 JoinGroup 请求后，会在所有成员中选定一个 Leader，通常是第一个发起 JoinGroup 请求的成员。协调者会把所有成员及其订阅的主题，发给这个 Leader，由它来为每一个成员分配消费的主题分区。
在此过程中，组内的成员会向协调者发送 SyncGroup 请求，等待接收 Leader 分配好的方案。当所有的成员都接收到新的分配方案后，Rebalance 就完成了。
还有一个需要了解的地方是，当 Rebalance 开启的时候，协调者会给成员一定的时间，来提交自己当前的位移信息，然后在开始 JoinGroup 和 SyncGroup 请求。
