小程序版
微信扫码，随时查命令
一次消费端处理超时触发的重平衡循环，以及为什么“加分区、扩 Broker”反而让情况更糟。
某业务集群的订单事件消费组在半小时内出现消费延迟飙升。lag 曲线呈锯齿状：短暂下降后迅速抬高，消费者组状态在 PreparingRebalance 和 Stable 之间反复切换，消费者日志持续刷出：
Revoking previously assigned partitions
Attempt to heartbeat failed since group is rebalancing
This member will leave the group because consumer poll timeout has expired
消费实例并没有全部掉线，但每隔几十秒就有成员被踢出组，随后重新加入。期间 Broker CPU 出现尖峰，磁盘和网络没有饱和，也没有 Broker 下线或分区不可用。下游订单状态更新延迟，运营看板数据停止刷新，部分消息被重复处理。
值得注意的是，团队在故障初期给 topic 增加了分区，本意是“提高并行度”，结果重平衡间隔更短、单次恢复更慢，消费延迟反而进一步恶化。
| 时间 | 事件 |
|---|---|
| T+0 | 消费 lag 超过阈值告警，值班开始查看消费者组 |
| T+5m | --describe --state 显示组状态在 PreparingRebalance 与 Stable 间抖动 |
| T+10m | 看到 Broker CPU 偏高、个别分区 lag 最大，误判为分区倾斜或 Broker 热点 |
| T+16m | 给 topic 增加分区并滚动重启消费者，重平衡更频繁，lag 继续上涨 |
| T+24m | 拉取消费者日志，发现 consumer poll timeout has expired |
| T+30m | 对比单批处理耗时与 max.poll.interval.ms，确认一批消息的处理时间已经超过会话允许的上限 |
| T+36m | 回滚消费者版本，关闭新增的同步下游调用 |
| T+44m | 消费者组恢复稳定，重平衡停止 |
| T+60m | lag 开始持续下降，下游积压逐步消化 |
| T+90m | lag 回到基线，重复消费完成对账 |
| T+2h | 完成参数预算、监控和发布流程改进 |
消费延迟持续约九十分钟，订单状态更新和运营看板受到影响。由于重平衡会回收未提交的 offset，部分消息被重复消费；消费逻辑具备幂等键，没有造成重复下单，但下游写入压力短时上升。消息没有丢失，积压最终被消化。
增加分区的操作带来了额外副作用：分区数变化本身会触发重平衡，keyed 消息的顺序保证也被破坏；恢复后还需要评估分区布局和 consumer 数量是否匹配。Broker CPU 尖峰主要是重平衡和重复拉取造成的，不是容量不足，但监控上很容易被误读为 Broker 过载。
最初的方向是“Broker 或分区不均”，依据看起来也很充分：Broker CPU 高、某些分区 lag 特别大、消费者实例数量不少。于是团队先加分区，再滚动重启消费者，结果重平衡更频繁。
推翻这个判断的证据有四条：
consumer poll timeout has expired 表示两次 poll() 之间的时间超过了 max.poll.interval.ms，消费者被主动踢出组。这条日志比所有 Broker 指标都更接近根因。还有一个放大器容易被忽略：消费者 Pod 的存活探针在长时间 poll 期间超时，重启 Pod 又触发新的重平衡；重启看起来像“实例不稳定”，实际上也是处理超时的后果。
直接原因是新版本在 poll 循环内同步调用下游 HTTP 接口。单批最多拉取 500 条消息，每条消息最坏情况下要经历 30 秒超时并重试三次；只要一批里有几条慢消息，整批处理时间就会超过默认的 5 分钟 max.poll.interval.ms。消费者来不及在期限内再次调用 poll()，被协调器踢出组，触发重平衡。
重平衡后未提交的 offset 需要重新消费，慢消息再次进入同一批，形成“处理慢 → 被踢出 → 重平衡 → 重放 → 更慢”的循环。这是本次故障的核心正反馈。
促成条件包括：
max.poll.records 保持默认的 500，没有按单条处理耗时做预算。max.poll.interval.ms 不匹配；单条消息的最坏耗时已经接近甚至超过整个批次允许的时间。止血阶段先停止新增的重平衡来源，再恢复消费：
# 1. 看组状态、成员和 lag
kafka-consumer-groups.sh --bootstrap-server <broker>:9092 \
--describe --group order-events
kafka-consumer-groups.sh --bootstrap-server <broker>:9092 \
--describe --group order-events --state
kafka-consumer-groups.sh --bootstrap-server <broker>:9092 \
--describe --group order-events --members --verbose
# 2. 看消费者日志中的掉组原因
kubectl -n order logs deploy/order-consumer --since=30m \
| grep -iE 'rebalance|poll timeout|heartbeat|revok'
# 3. 看 topic 分区与 Broker 状态，排除真正的 Broker 故障
kafka-topics.sh --bootstrap-server <broker>:9092 \
--describe --topic order-events
如果确认是处理超时，短期可以把 max.poll.records 降到 100 左右，或临时提高 max.poll.interval.ms，给单批处理留出余量；但这只是买时间，不能替代异步化。不要用 --reset-offsets 把 lag “抹平”，那会掩盖问题并可能造成消息跳过。
代码层的修复是把慢操作移出 poll 循环：
pause/resume），而不是无限堆积。onPartitionsRevoked 中提交已完成的位置，减少重放。max.poll.interval.ms；慢消息进入重试 topic 或死信队列，不能长期阻塞一个分区。参数要作为一组来调，而不是只改一个：
单批最坏处理时间 ≈ max.poll.records × 单条 p99（含重试）
目标：单批最坏处理时间 < max.poll.interval.ms 的 50%
同时调整 session.timeout.ms 与 heartbeat.interval.ms，避免 GC 或短暂网络抖动误判；在集群支持的前提下使用 cooperative-sticky 分配器和静态成员（group.instance.id），减少全量回收和滚动发布带来的重平衡。把消费者 Pod 的 terminationGracePeriodSeconds 调大，并在收到终止信号时调用 wakeup()、提交已完成 offset 后退出。
验证标准不是“lag 开始下降”，而是组状态连续十分钟保持 Stable、没有新的 Revoking 日志、lag 单调下降。确认稳定后再移除临时参数，避免把临时阈值永久化。
max.poll.records、下游超时、重试次数和 max.poll.interval.ms 必须一起评审，任何一项变更都要重新计算最坏耗时。合上页面，先回答，再展开对照。
max.poll.records、单条处理耗时和 max.poll.interval.ms 之间应该满足什么关系？consumer poll timeout has expired 这类日志能直接说明成员为什么被踢出组；Broker CPU 高往往只是重平衡和重复拉取的结果，先看 Broker 容易误判为容量问题。max.poll.records 乘以单条 p99（含重试），应控制在 max.poll.interval.ms 的一半以内，给 GC、网络抖动和重平衡留出余量。
小程序版
微信扫码，随时查命令