3. 重平衡触发条件：消费者加入/离开、分区数变更、订阅 topic 变更、心跳超时

消费者组重平衡（Rebalance）并非随机发生，而是由一组明确的集群或客户端事件触发。理解这些触发条件是诊断重平衡频率过高、消费延迟增大以及 GC 停顿加剧的基础。根据 Kafka 协议设计，重平衡触发条件可归纳为以下四类核心场景。

3.1 触发条件分类与对比

3.2 触发条件详解

3.2.1 消费者加入（JoinGroup 请求）

当一个新的消费者实例调用 subscribe() 并尝试加入组时，会向 Group Coordinator 发送 JoinGroup 请求。Coordinator 收到请求后，若发现当前组成员列表发生变化，则立即触发新一轮重平衡。扩容场景下，新消费者加入会触发分区重新分配，目的是将分区负载均匀分布到所有成员上。

3.2.2 消费者离开（LeaveGroup 请求 / Session 超时）

消费者离开分为优雅离开和非优雅离开两种：

• 优雅离开：消费者调用 close() 时主动发送 LeaveGroup 请求，Coordinator 立即标记该成员为"离开"并触发重平衡。
• 非优雅离开：消费者进程崩溃、网络断开或 GC 停顿导致心跳超时，Coordinator 在 session.timeout.ms 内未收到心跳，将该成员从组中移除并触发重平衡。

3.2.3 分区数变更（Metadata 变更）

通过 kafka-topics.sh --alter --partitions 增加 topic 分区数时，Kafka 集群会更新该 topic 的元数据。Group Coordinator 在定期同步元数据时发现分区数变化，会向组内所有消费者发送 IllegalGeneration 或触发 Metadata 更新 事件，进而发起重平衡。分区数减少（删除分区）同样会触发重平衡，但该操作在 Kafka 中属于高风险操作，生产环境极少使用。

3.2.4 订阅 topic 变更（Pattern 或 List 变化）

消费者通过 subscribe(Pattern) 或 subscribe(List) 订阅 topic。当消费者动态修改订阅模式（例如从 topic-* 改为 topic-v2-*），或者通过正则匹配新增/删除了 topic 时，消费者会向 Coordinator 发送新的订阅元数据。Coordinator 对比前后订阅集合，若发现差异则触发重平衡。

3.2.5 心跳超时（Heartbeat 机制）

心跳超时是重平衡触发条件中与 JVM GC 停顿关联最紧密的一环。消费者使用独立的后台线程（Heartbeat Thread）以 heartbeat.interval.ms 间隔发送心跳请求。若 GC 停顿（尤其是 Full GC）导致该线程被 STW（Stop-The-World）暂停超过 session.timeout.ms，Coordinator 将判定消费者死亡。

3.3 触发条件与重平衡流程的对应关系

下图展示了四种主要触发条件如何进入重平衡的完整生命周期，以及 GC 停顿在心跳超时路径中的关键位置。

3.4 触发条件与 GC 停顿的关联分析

在四类触发条件中，心跳超时与 JVM GC 停顿存在直接因果关系，而其他三类触发条件也可能间接受到 GC 影响：

• 消费者加入/离开：若消费者在 GC 停顿期间尝试发送 JoinGroup 或 LeaveGroup，请求可能被延迟，导致 Coordinator 端超时误判。
• 分区数变更：元数据拉取请求（MetadataRequest）若因 GC 停顿延迟，消费者可能无法及时感知分区变化，导致重平衡触发滞后。
• 订阅 topic 变更：消费者端订阅逻辑通常在用户主线程执行，若主线程被 GC 停顿阻塞，订阅变更无法及时发送到 Coordinator。

3.5 触发条件检测时序

以下时序图展示了消费者加入和心跳超时两种典型触发条件在时间线上的检测过程：

3.6 触发条件与重平衡频率的量化关系

在大型集群中，重平衡频率与触发条件之间存在可量化的关系。以下公式可用于评估重平衡对系统稳定性的影响：

重平衡频率（次/小时） = 
  (消费者加入/离开次数) + 
  (分区变更次数 × 订阅该 topic 的消费者组数) + 
  (心跳超时次数 × 超时触发重平衡比例)

其中：
- 心跳超时次数 ≈ 消费者实例数 × GC 停顿概率 × (session.timeout.ms / 心跳间隔)
- GC 停顿概率 = 每分钟 Full GC 次数 × 平均 STW 时间 / 60