K8s 缩容时 broker 看到的是 LeaveGroup 还是 timeout：两条超时线判定成员离组，优雅下线把整组停摆压到 0

作者：江墨白-195｜15 年技术团队负责人｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、K8s 1.28、消费组 24 实例、topic order-settle 64 分区、峰值 4.8 万 msg/s

一句话结论：K8s 缩容 / 发布时，broker 判定"这个成员该走了"有三条路径——主动 LeaveGroup、心跳线超时（session.timeout.ms）、主线程线超时（max.poll.interval.ms）。前一条是你"自己举手"，后两条是 broker"默认你死了"。缩容该走哪条、整组抖不抖，取决于你的优雅下线有没有真的走到 LeaveGroup。

一、现象与背景：发布窗口里整组 P99 从 200ms 飙到 3.2s

去年我们做消费端滚动发布，每次下线 4 个实例，监控上整组 P99 处理耗时从 180ms 飙到 3.2s，持续约 40s，单次发布伴随 6 万条处理时延超 1s 的消息；一次同时扩 8 实例还叠出 12 万条重复投递（下游幂等表兜住了）。

诡异的是 broker 端日志里 Member ... has failed, removing it from the group（心跳线驱逐）的次数很少，而 Rebalance started 密集出现在每次上下线时刻。这说明我们撞上的主要是主动 rebalance（成员正常离组触发的重排），而不是被动 rebalance（超时被踢）。这两件事的治理手段完全不同——但 90% 的团队把它们混在一起调参，结果既没治好抖动、又把故障发现时间拖长了。

二、根因：broker 判定成员离组的三条路径，冲击量级差一个数量级

Kafka 的 GroupCoordinator 在三种事件下会重排分区，判定依据不同：

1. 主动 LeaveGroup（成员自己发）：消费者进程正常退出、consumer.close() 走到 LeaveGroup 请求。broker 明确知道"谁走了"，只针对这一个成员的分区做重排。这是最干净的。
2. 心跳线超时（session.timeout.ms）：broker 用墙钟判 now - lastHeartbeat > session.timeout.ms 即驱逐。触发它的是"进程还活着但心跳发不出去"——典型是 STW GC 冻结了整个 JVM（心跳线程和主线程一起停）。这条线触发后 broker 只知道"有人超时了"，重排范围取决于分配器。
3. 主线程线超时（max.poll.interval.ms）：两次 poll() 间隔超过该值，成员自我标记失效并触发 rebalance。触发它的是"单批处理太慢"。

三条线的关键差异不在"要不要 rebalance"，而在 rebalance 时分配器怎么动分区：

• eager 分配器（默认 RangeAssignor）：rebalance 时所有成员先放弃自己持有的全部分区，等 leader 重算完整分配再 seek 回来。哪怕这次只是缩容 1 个实例，其余 23 个老实例也得"全吐出来再重新拿"，协调期整组零吞吐——这就是那 40s 的来历。
• cooperative 分配器（CooperativeStickyAssignor，KIP-429）：增量式，只迁移必须迁移的分区，其余分区原地继续消费。缩容 4 个实例时，只有被匀走的那几十分区 unassign，其余消费不受影响。

所以真正的因果链是：缩容 →（主动 LeaveGroup 或超时）→ rebalance → 分配器决定"全停"还是"局部停"。 你无法消灭缩容时的 rebalance（成员走了分区总要重分），但你能决定它是"全组 eager 停摆"还是"只动被匀走的分区"。

还有一条被忽视的线：static membership（group.instance.id）让"下线再上线"的实例在 session.timeout.ms 窗口内被 broker 认作"还是它"，直接沿用旧分配、跳过这次 rebalance。这条对 K8s 缩容尤其关键——Pod 缩容后新 Pod 很快起来，如果身份稳定，broker 就不必等它"死透"再重排。

三、具体做法（可复现）

3.1 优雅下线：让缩容走主动 LeaveGroup，而不是等超时

K8s 的 terminationGracePeriodSeconds 计时器从 Kubelet 开始执行停机（含 preStop）那一刻就启动，preStop 不是"额外加"的缓冲，而是从总窗口里"扣"掉的。所以预算必须显式拆开：

terminationGracePeriodSeconds: 90   # = preStop(15s) + close 留足(30s) + 余量(45s)
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh","-c","echo drain >> /tmp/draining && sleep 15"]

Java 侧，停机钩子里必须走到 consumer.close()（它内部发 LeaveGroup），而不是直接 System.exit / 让进程被 SIGKILL 杀掉：

@Bean(destroyMethod = "close")
public KafkaConsumer<String, OrderEvent> consumer(ConsumerFactory<String, OrderEvent> cf) {
    Consumer<String, OrderEvent> c = cf.createConsumer();
    c.subscribe(List.of("order-settle"));
    return c;   // Spring 的 destroyMethod="close" 保证关闭时调 close() → LeaveGroup
}

关键：别在 preStop 里只 wakeup() 就退出。consumer.wakeup() 只能让当前阻塞的 poll() 抛一次 WakeupException，它不打断"已经 poll 出来、还在内存里"的 in-flight 批次，更不会替你发 LeaveGroup。要的是 close()，它先停 poll、处理完在途批次、提交 offset、最后发 LeaveGroup——这才是"自己举手"。

3.2 分配器切 cooperative + static membership

group.id=order-settle
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor
group.instance.id=${POD_ORDINAL}     # 见 3.3，身份必须稳定
max.poll.records=500
max.poll.interval.ms=120000
session.timeout.ms=45000
heartbeat.interval.ms=15000          # 经验值 ≈ session.timeout / 3

3.3 static 身份：Deployment 上形同虚设，必须 StatefulSet 或固定序号

static membership 要求实例身份在重启后不变。K8s Deployment 里 Pod 重建后 POD_NAME 变了，broker 认为来了个"新成员"，static 完全没起作用，rebalance 照旧。我们改成 StatefulSet（Pod 名/序号稳定）后 group.instance.id 才真正生效。这是最容易踩的坑——参数加了，但因为身份不稳定，等于没加。

3.4 验证：用 broker 日志区分三条路径 + 用 Revoked 分区数验证

# 区分"主动离组"还是"超时被踢"
grep -E "Member .* has left the group|has failed, removing it from the group" server.log
#   has left      → 主动 LeaveGroup（优雅下线成功，最干净）
#   has failed    → 心跳线超时（被动，说明进程僵死或 GC 冻结，要查 GC 日志）
#   若伴随 "max.poll.interval" → 主线程线超时（单批处理太慢）

# 验证 cooperative 是否真的只动局部分区
grep -E "Revoked: \[|Assigned: \[" app.log
#   cooperative 缩容特征：Revoked: [] 或仅少量分区
#   eager          特征：Revoked: [大量分区]（全组吐分区）

用 Revoked 的分区数验证，比看 P99 更直接——它直接告诉你这次 rebalance 动的是"全组"还是"局部"。

四、踩过的坑 / 反直觉之处

1. session.timeout.ms 调大到 90s"治好了"抖动，但代价是真·进程僵死时故障发现时间翻倍，且被踢后分区在 90s 内无人接管、lag 堆积。调大超时是用"不可用时间"换"重复投递"，两个都是钱。
2. static membership 保的是"席位"不是"分区"：实例暂停回来，broker 认它还在，但它暂停那段时间分区没人消费，lag 照常堆。static 适合"重启快（<30s）"的 K8s 缩容场景，不适合"JVM 长暂停"场景——后者会把"重复投递"换成"延迟消费"。
3. cooperative 不是"零 rebalance"，是"零全停"。缩容仍会触发一次增量 rebalance，只是老分区不停。别指望它消灭 rebalance。
4. max.poll.records 在 cooperative 下更敏感：它要求被 revoke 的分区能"干净让出"，单批处理若逼近 max.poll.interval，会先触发主线程线超时被动 rebalance，反而抵消 cooperative 的好处。500 是我们的上限，慢逻辑必须异步化。
5. 重复消息不会因为换了分配器就消失：cooperative 降的是"eager 全停导致的 offset 抖动"，幂等去重永远要自己做，rebalance 治理替代不了幂等。
6. 反直觉：缩容触发的"全组停摆"，根子往往不是 Kafka 参数，而是 K8s 侧——preStop 没走到 close()（没发 LeaveGroup）、或身份不稳定（static 失效）。这两件事在 Kafka 日志里都表现为"rebalance 变多了"，但治理手段在部署清单上。

五、结论与可复用清单

结论：缩容时的 rebalance 分"谁触发"和"怎么重排"两层。"谁触发"由优雅下线决定（主动 LeaveGroup vs 超时被踢），"怎么重排"由分配器决定（eager 全停 vs cooperative 局部）。把这两层都治理到位，滚动发布期间整组 P99 从 3.2s 回落到 210ms、发布窗口内零全停、重复投递降到幂等表可忽略的量级。

可复用清单：

• [ ] 先用 broker 日志分清触发路径：has left（主动 LeaveGroup）/ has failed（心跳线超时）/ max.poll.interval（主线程线超时），三条线治理手段不同，别混着调参。
• [ ] 优雅下线必须走到 consumer.close()（发 LeaveGroup），preStop 里只 wakeup() 不够；terminationGracePeriodSeconds 要显式覆盖 preStop + close 的完整预算。
• [ ] 分配器切 CooperativeStickyAssignor，用日志里 Revoked 分区数验证是"局部停"还是"全组停"。
• [ ] 上 group.instance.id，且身份必须稳定（StatefulSet / 固定序号），否则 static 形同虚设。
• [ ] 起点参数：session.timeout=45s / heartbeat=15s / max.poll.interval=120s / max.poll.records=500，再按你的单批处理耗时收。
• [ ] 幂等去重永远自己做；慢逻辑异步化，别让单批逼近 max.poll.interval。

参考：本文的 cooperative + static 基线与"cooperative 是零全停不是零 rebalance"的判定，承接了 江知远-915 的扩缩容 rebalance 治理；心跳线"broker 用墙钟判定、GC 冻结会连带触发被动 rebalance"的机制，对齐 江景行-945 的 GC 与级联 rebalance 复盘。本文补的是"缩容时该走主动 LeaveGroup 而非超时、以及三条离组路径如何判定"这条此前没人单独立论的线。