Kafka 消费者组 Rebalance 详细过程

语言: CN / TW / HK

这是我参与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 后可以正常消费数据的状态。

他们的关系如下图:

流程图.jpg

Rebalance 的过程

当消费者组处于 Stable 状态时,消费者实例会定期向协调者发送心跳通知,起作用就是告诉协调者实例在正常运行,当有新成员计入、成员主动离开、成员失联被动离开的场景下,协调者会通过响应心跳请求的方式,告诉所有实例,要进行 Rebalance 了。

我们分别梳理一下协调者发起新一轮 Rebalance 前,这三种情况的流程。

  • 第一种,当有新的实例加入的时候,新加入的实例会向协调者发送 JoinGroup 请求,协调者收到后,会向所有实例响应新一轮 Rebalance 开始的信息。
  • 第二种,当有成员主动离开消费者组,离组的成语啊你会向协调者发送 LeaveGroup 的请求,协调者收到后,会向所有实例响应新一轮 Rebalance 开始的信息。
  • 第三种,协调者没有在规定时间内接收到某个成员的心跳通知,那么这个成员会被踢出消费者组,测试,协调者会向所有实例响应新一轮 Rebalance 开始的信息。

以上所说的开始新一轮 Rebalance 的信息,其实就是在心跳请求的响应中,告诉成员:Rebalance 要开始了,请重新申请加入消费者组。成员收到后,会重新发送 JoinGroup 请求。

当协调者收到所有成员的 JoinGroup 请求后,会在所有成员中选定一个 Leader,通常是第一个发起 JoinGroup 请求的成员。协调者会把所有成员及其订阅的主题,发给这个 Leader,由它来为每一个成员分配消费的主题分区。

在此过程中,组内的成员会向协调者发送 SyncGroup 请求,等待接收 Leader 分配好的方案。当所有的成员都接收到新的分配方案后,Rebalance 就完成了。

还有一个需要了解的地方是,当 Rebalance 开启的时候,协调者会给成员一定的时间,来提交自己当前的位移信息,然后在开始 JoinGroup 和 SyncGroup 请求。