4、重平衡协议详解：Eager Rebalance 与 Cooperative Rebalance（增量协同）的原理与对比

Kafka 消费者组重平衡（Rebalance）是分布式消费模型的核心机制，也是引发消费中断、尾延迟飙升的常见根源。Kafka 先后引入了两代重平衡协议：Eager Rebalance（全量停止-分配） 与 Cooperative Rebalance（增量协同）。理解两者的原理与差异，是诊断重平衡相关慢查询的基础。

4.1 Eager Rebalance：全量停止-再分配

Eager Rebalance 是 Kafka 0.11.0 之前及默认使用的旧协议，其核心思想是“先停再分”。

4.1.1 执行步骤

1. 触发重平衡： 消费者心跳超时、新消费者加入、分区数变更等事件触发 Coordinator 决定重平衡。
2. 全量撤销（Revoke）： Coordinator 向所有消费者发送 RevokePartitions 请求，消费者立即停止消费并释放所有分区。
3. 重新加入（JoinGroup）： 消费者发送 JoinGroup 请求，选举出 Group Leader。
4. 同步分配（SyncGroup）： Leader 根据分区分配策略（如 RangeAssignor、RoundRobinAssignor）计算新分配方案，Coordinator 将方案广播给所有消费者。
5. 恢复消费： 消费者根据新分配结果开始消费。

4.1.2 关键特征

4.2 Cooperative Rebalance：增量协同

Cooperative Rebalance（KIP-429，自 Kafka 2.4.0 引入）旨在解决 Eager Rebalance 的全量中断问题。其核心思想是“分阶段、增量式”地重新分配分区，只撤销需要迁移的分区，保留大部分分区的消费连续性。

4.2.1 执行步骤

1. 触发重平衡： 与 Eager 相同，由 Coordinator 检测到变更事件。
2. 增量撤销（Incremental Revoke）： Coordinator 根据当前分配与目标分配，计算出需要迁移的分区集合，仅向相关消费者发送 RevokePartitions 请求，要求撤销这些分区。
3. 重新加入（JoinGroup）： 消费者发送 JoinGroup 请求，携带当前持有的分区列表。
4. 增量分配（Incremental Assignment）： Leader 基于消费者当前持有分区，计算增量调整方案，仅分配需要迁移的分区。
5. 同步分配（SyncGroup）： Coordinator 将增量分配结果下发。
6. 检查收敛： 如果仍有未分配或需要进一步调整的分区，Coordinator 会触发下一轮重平衡，重复步骤 2-5，直到所有分区分配稳定。

4.2.2 关键特征

4.3 协议对比：Eager vs. Cooperative

4.4 协议流程对比图

下图展示了两种协议在消费者组发生成员变更时的核心流程差异。左侧为 Eager Rebalance 的全量停止-分配流程，右侧为 Cooperative Rebalance 的增量协同流程。

4.5 增量协同的多轮收敛机制

Cooperative Rebalance 的核心优势在于其多轮收敛机制。以下是一个典型的两轮收敛示例：

在第一轮中，C1 和 C2 仅撤销了需要迁移的 P2 和 P5，其余分区继续消费。C3 加入后获得这两个分区。第二轮检查发现分配已稳定，无需进一步调整，重平衡结束。整个过程 C1 和 C2 的消费未中断，仅 C3 在加入时有短暂延迟。

4.6 配置与启用

要启用 Cooperative Rebalance，需要在消费者客户端配置分区分配策略为 CooperativeStickyAssignor：

// Java 消费者配置示例
Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092");
props.put("group.id", "my-consumer-group");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

// 启用增量协同重平衡
props.put("partition.assignment.strategy",
          "org.apache.kafka.clients.consumer.CooperativeStickyAssignor");

// 可选：设置心跳超时和重平衡超时
props.put("heartbeat.interval.ms", 3000);
props.put("session.timeout.ms", 45000);
props.put("max.poll.interval.ms", 300000);

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

4.7 协议选择对尾延迟的影响

在诊断慢查询尾延迟时，重平衡协议的选择直接影响延迟抖动的幅度：

• Eager Rebalance： 全局中断导致所有消费者同时停止消费，消息堆积在短时间内急剧增加。恢复消费后，消费者需要追赶大量积压消息，导致 P99.9 延迟从正常值（如 10ms）飙升至秒级（如 5-10s）。
• Cooperative Rebalance： 仅迁移分区的消费者有短暂中断，大部分消费者持续消费。整体消息堆积增长缓慢，尾延迟抖动通常控制在 100ms 以内，对业务影响极小。