kafka23-Rebalance触发场景和流程详解

目录

Kafka 中, Rebalance触发场景

1. 消费者宕机触发 Rebalance

2. 新增消费者触发 Rebalance

3. 消费者离开消费者组时触发Rebalance

---

Kafka 中, Rebalance触发场景

1. 消费者组中的消费者数量发生变化：

   • 情况描述：当有消费者主动加入或离开消费者组时，例如新消费者加入或现有消费者退出。
   • 触发原因：消费者数量变化导致消费者组的负载需要重新平衡。
   • 执行过程：Group Coordinator 收到 JoinGroup 或 LeaveGroup 请求后，会触发 Rebalance 过程。

2. 消费者在 session.timeout.ms 超时前未发送心跳：

   • 情况描述：消费者需要定期发送心跳以表明自己的活跃状态。如果某个消费者在 session.timeout.ms 时间内未发送心跳，则被视为失效。
   • 触发原因：消费者失效可能是由于网络故障、消费者程序崩溃等原因。
   • 执行过程：Group Coordinator 在检测到消费者失效后，会将其分区重新分配给其他健康的消费者，触发 Rebalance。

3. 消费者在 max.poll.interval.ms 超时前未调用 poll() 方法拉取数据：

   • 情况描述：max.poll.interval.ms 是消费者在未响应 Rebalance 指令时的最大时间间隔。如果消费者超过此时间未调用 poll() 方法，则被认为失效。
   • 触发原因：消费者程序可能在长时间内未处理数据，导致无法及时响应分区重新分配。
   • 执行过程：类似于第二种情况，Group Coordinator 将超时的消费者认定为失效，并重新分配其分区。

4. 某个消费者在 Rebalance 过程中未响应 Coordinator 的指令，在 rebalance.timeout.ms 超时前：

   • 情况描述：rebalance.timeout.ms 是 Rebalance 过程的最大时间间隔。如果某个消费者在此时间内未响应 Coordinator 的指令，被认定为失效。
   • 触发原因：消费者可能由于网络延迟、消费者程序逻辑问题等原因未能及时响应 Coordinator 的分配指令。
   • 执行过程：Coordinator 将超时的消费者视为失效，重新分配其分区给其他消费者，启动 Rebalance 过程。

5. 消费者组的订阅主题或者分区数量发生变化：

   • 情况描述：当消费者组订阅的主题或者分区数量发生变化，例如新增或减少主题分区。
   • 触发原因：主题分区的变化需要重新分配消费者的负载，以适应新的分区分配。
   • 执行过程：类似于消费者数量变化的情况，变化会触发消费者组的 Rebalance 过程，以重新分配分区。

6. 配置的消费策略发生变化，例如 RangeAssignor -> RoundRobinAssignor：

   • 情况描述：消费者组的消费策略（Partition Assignment Strategy）发生变化，例如从范围分配（RangeAssignor）切换到轮询分配（RoundRobinAssignor）。
   • 触发原因：不同的分配策略可能会导致消费者组成员的分区分配方式不同，需要进行 Rebalance。
   • 执行过程：变更消费策略会被视为消费者组结构的重大变更，会触发 Rebalance 以确保所有消费者按照新的策略进行分区分配。

1. 消费者宕机触发Rebalance详解

当消费者宕机后，Coordinator 会采取以下方式通知消费者组需要进行 Rebalance：

通知方式一：HeartbeatResponse中附加信息

1. 心跳超时检测： 每个消费者定期（默认为 heartbeat.interval.ms，通常为3秒）向 Coordinator 发送 HeartbeatRequest，以表示它仍然活跃。Coordinator 在 session.timeout.ms（默认为45秒）内没有收到某个消费者的心跳请求后，会将该消费者标记为宕机状态。

2. HeartbeatResponse 中触发 Rebalance： 当 Coordinator 发现某个消费者宕机（即未能在合理时间内收到心跳），它会将这一信息包含在向消费者组中其他活跃消费者发送的 HeartbeatResponse 中。同时，Coordinator 会请求消费者组执行一次 Rebalance 操作，以重新分配分区，确保消费者组的平衡性和可靠性。

通知方式二：OffsetFetchResponse中附加信息

1. 心跳超时检测： 同样是在 session.timeout.ms 内没有收到某个消费者的心跳请求后，Coordinator 将该消费者标记为宕机状态。

2. OffsetFetchResponse 中触发 Rebalance： 在向消费者组中的其他消费者反馈 OffsetFetchResponse 时，Coordinator 可能会一并触发 Rebalance 操作。这通常发生在 Coordinator 发现宕机消费者后，确认宕机状态，并与其他活跃消费者通信之后的步骤。

2. 新增消费者触发Rebalance详解

1. 增加新消费者

   当消费者组需要增加新的消费者时（例如Consumer-3），以下是执行的步骤：

   • JoinGroup 请求发送： Consumer-3 向 Group Coordinator 发送 JoinGroup 请求，请求加入消费者组，并指定要订阅的主题（这里是 'msjx_stock'）。

   • 撤销订阅命令： Group Coordinator 收到 Consumer-3 的 JoinGroup 请求后，将撤销所有消费者（Consumer-1 和 Consumer-2）的当前订阅主题的命令附加在 HeartBeatResponse 中，并返回给它们。

   • Stop The World： Consumer-1 和 Consumer-2 在收到撤销订阅命令后，停止消费数据。这是因为它们必须等待 Rebalance 完成后才能重新分配分区。

2. Rebalance 过程

   • 重新加入消费者组： 所有消费者（Consumer-1、Consumer-2 和 Consumer-3）收到撤销订阅命令后，重新向 Group Coordinator 发送 JoinGroup 请求。

   • 等待时间窗口： Group Coordinator 收到第一个 JoinGroup 请求后，开始等待 max.poll.interval.ms 的时间窗口（默认为 5 分钟）。在这个时间内，其他消费者也会发送 JoinGroup 请求，或者直到时间窗口到期。

   • Leader 选举： Group Coordinator 选择第一个发送 JoinGroup 请求的消费者作为 Leader（例如，Consumer-1）。Leader 负责为每个消费者制定分区分配方案。

   • 分区分配方案： Leader 使用本地配置的分区策略，为每个消费者制定具体的分区分配方案，并将分区方案反馈给 Group Coordinator。

   • SyncGroupRequest 发送： 每个消费者（包括 Leader）向 Group Coordinator 发送 SyncGroupRequest，确认其分配方案。

   • 分区分配广播： Group Coordinator 收到所有 SyncGroupRequest 后，广播 Leader 制定的分区分配方案给所有消费者。

3. 完成 Rebalance

   • Rebalance 完成后： 所有消费者收到 JoinGroupResponse 的响应后，完成了 Rebalance 过程。

   • Stop The World 停止： 现在所有消费者可以开始消费数据，也就是说，之前发生的 Stop The World 现在停止。

3. 消费者离开消费者组时触发Rebalance详解

1. 停止消费者程序

   当需要停止消费者程序时（例如，Consumer-3），以下是执行的步骤：

   • LeaveGroup 请求发送： Consumer-3 被停止后，会向 Group Coordinator 发送 LeaveGroup 请求。这个请求通知 Coordinator 它要退出消费者组。

   • 撤销订阅命令： Group Coordinator 在接收到 Consumer-3 的 LeaveGroup 请求后，会将撤销 Consumer-3 订阅的 TopicPartition 的命令附加在 HeartBeatResponse 中。

2. Stop The World

   • 等待心跳信息： Group Coordinator 在 session.timeout.ms （例如 Kafka 3.0+ 默认为 45 秒）范围内收到其他健康消费者（Consumer-1 和 Consumer-2）的心跳信息后，才会继续执行 Rebalance 过程。

   • 撤销订阅命令广播： 在 Coordinator 收到其他消费者的心跳信息后，会将撤销 Consumer-1 和 Consumer-2 订阅的 TopicPartition 的命令附加在 HeartBeatResponse 中，并广播给它们。

   • Stop The World 发生： Consumer-1 和 Consumer-2 在收到撤销订阅命令后，停止消费数据。这是为了确保在 Rebalance 过程中没有消费者处理数据，从而保证数据一致性和分区重新分配的有效性。

3. Rebalance 过程

   • 重新加入消费者组： Consumer-1 和 Consumer-2 收到撤销订阅命令后，会重新向 Group Coordinator 发送 JoinGroup 请求。

   • 等待时间窗口： Coordinator 收到第一个 JoinGroup 请求后，开始等待 max.poll.interval.ms 的时间窗口（默认为 5 分钟），以便其他消费者也可以发送 JoinGroup 请求。

   • Leader 选举： Group Coordinator 选择第一个发送 JoinGroup 请求的消费者作为 Leader，例如 Consumer-1。

   • 分区分配方案： Leader 使用本地配置的分区策略为每个消费者制定分区分配方案，并将其反馈给 Group Coordinator。

   • SyncGroupRequest 发送： 每个消费者（包括 Leader）向 Group Coordinator 发送 SyncGroupRequest，确认其分配方案。

   • 分区分配广播： Group Coordinator 在收到所有 SyncGroupRequest 后，广播 Leader 制定的分区分配方案给所有消费者。

4. 完成 Rebalance

   • Rebalance 完成后： 所有消费者收到 JoinGroupResponse 的响应后，完成了 Rebalance 过程。

   • Stop The World 停止： 现在所有消费者可以开始消费数据，即之前发生的 Stop The World 现在停止。