Kafka 消费组 47 次 rebalance：3200 万积压的 58 分钟拆解

凌晨两点十七分，告警群里跳出一条：订单事件 topic 的消费 lag 突破 3000 万，并且还在以每分钟 40 万条的速度上涨。打开监控，lag 曲线几乎是垂直的，同时消费组的 rebalance 次数在半小时里跳了 47 次。这不是“消费慢”，这是消费组在反复自我重启——每重启一次，吞吐就掉一截，然后积压更严重，再触发下一次重启。

从介入到把 lag 拉回 0，总共 58 分钟。下面是把这场雪崩拆开的过程，包括那个坑了无数人的 max.poll.interval.ms。

一、先看清楚：不是消费慢，是组在抖

第一件事不是加消费者，是看消费组的状态变化。用命令行把组描述出来，重点看两列：成员数和 rebalance 次数。

kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 \
  --describe --group order-event-consumer --state

输出里的 state 在 Stable 和 PreparingRebalance 之间来回跳，COORDINATOR 节点上能找到大量这样的日志：

[ConsumerGroupCoordinator] Member consumer-order-event-consumer-3-8f2c
  has left group order-event-consumer due to consumer poll timeout
  has expired.

这行日志是判词：消费者**没有在约定时间内完成 poll**，协调者认为它死了，把它踢出组，于是整组 rebalance。剩下的消费者接手它的分区，每个消费者的负载翻倍，处理时间更长，又超时，再被踢——正反馈。

二、算一笔账：为什么会超时

两个参数决定生死：

• max.poll.interval.ms：两次 poll 之间的最大间隔，默认 300000（5 分钟）。超了就被踢。
• max.poll.records：一次 poll 拉多少条，默认 500。

这个服务的处理逻辑是：poll 到 500 条 → 逐条调下游 HTTP 接口落库 → 每批提交 offset。单条处理平均 90ms，500 条就是 45 秒——看起来远低于 5 分钟。但这是平均值，压测环境里没有尾部延迟。

生产环境的真实分布是：90% 的请求 20ms，9% 在 200~800ms，1% 会卡到 15 秒以上（下游偶发慢查询 + 连接池耗尽）。500 条里只要命中 20 条 15 秒的，整批就超过 5 分钟，于是被踢。这个概率在正常流量下大概每小时一次，在凌晨的批处理流量峰值下变成每 40 秒一次。

结论：不是吞吐不够，是**单批处理时间超过了会话存活窗口**。加消费者只会让 rebalance 更频繁——因为组越大，一次 rebalance 需要协调的成员越多，抖动更久。

三、改法：三步，按顺序做

第一步：把批拉小、把超时放宽（止血）

max.poll.records=50
max.poll.interval.ms=900000
session.timeout.ms=45000
heartbeat.interval.ms=3000
fetch.min.bytes=1048576
fetch.max.wait.ms=500

关键不是把 max.poll.interval.ms 调到 15 分钟就够了——那只是放宽了界限，单批还是 50 条 × 90ms，尾部延迟依然可能踩过线。拉小批次让单批耗时的方差变小，才是真正的止血。50 条 × 90ms 平均 4.5 秒，即使 20% 命中慢请求，也只到 2 分钟，远在 15 分钟之内。

第二步：把“逐条 HTTP”改成批量 + 异步

原来每条消息都要调一次下游接口，这是吞吐瓶颈的根源。改成批量落库：一份 poll 到的 50 条消息先聚合，按业务主键分组，一次 INSERT ... ON DUPLICATE KEY UPDATE 提交，最多 5 次数据库往返，把 45 秒压到 3 秒以内。

public void onBatch(List<ConsumerRecord<String, String>> records) {
    Map<Long, OrderEvent> dedup = new LinkedHashMap<>();
    for (ConsumerRecord<String, String> r : records) {
        OrderEvent e = parse(r.value());
        dedup.put(e.getOrderId(), e);          // 同 key 取最新，天然幂等
    }
    repository.upsertBatch(new ArrayList<>(dedup.values()));
}

幂等这件事必须在代码里做，不能靠“反正 Kafka 会保证不重复”。rebalance 发生时，已完成但未提交 offset 的那一批会被重新投递，重复消费是必然而非意外。上面的 LinkedHashMap 按主键去重 + ON DUPLICATE KEY UPDATE，两层兜住。

第三步：分区扩容要配消费者数量

topic 原来是 6 分区 / 6 消费者。扩到 12 分区 / 12 消费者，理论吞吐翻倍。但这里有个容易被忽略的点：消费者数超过分区数的那部分线程是白养的，Kafka 不会把同一个分区分给两个消费者。所以扩容要成对做，先扩分区再扩实例，且扩分区后 key 的哈希分布会变，做顺序性要求高的业务要提前评估。

四、还有一层：GC 停顿放大了超时

改完批次大小之后，rebalance 从 47 次降到 6 次，但没归零。翻 GC 日志发现消费者在积压高峰时每 90 秒一次 Young GC，单次 260ms，另外每小时一次 1.2 秒的 Full GC。这不是主要原因，但它把“边缘可过”变成了“边缘必挂”：本来就逼近 5 分钟的单批处理，被几次长停顿推过线。

处理方式不复杂：堆从 4G 提到 6G、G1 的 MaxGCPauseMillis=200、InitiatingHeapOccupancyPercent=35，然后把消费线程的本地缓存（每批都会 new ArrayList<>(records.size())）改成复用实例字段。停顿降到 80ms 以内，这一步贡献了剩余 6 次 rebalance 里的 4 次。

五、结果

注意最后那行“重复消费 0.3%”不是零。rebalance 与分区迁移期间的重复投递是 Kafka 的语义本身，任何声称“重复为零”的方案都是在掩盖问题。干净的解法是消费端幂等，不是想办法让 Kafka 不重投。

六、可复用的排查顺序

1. 先 describe 组状态，看 rebalance 次数与 coordinator 日志里的 poll timeout。看到这行就不用怀疑网络和 broker 了，问题在消费端节奏。
2. 算单批处理时间：max.poll.records × 单条 P99，不是 × 平均值。这个数字必须远小于 max.poll.interval.ms，留 3 倍以上余量。
3. 先把批拉小（500 → 50），比分批优化代码更快止血，且降低方差。
4. 再把逐条 RPC 改成批量，这一步才是真正的吞吐提升。
5. 幂等必须在代码里做：按业务主键去重 + upsert，别指望 exactly-once。
6. 扩分区要配对扩消费者，且扩分区会改哈希分布，有顺序性要求要评估。
7. 顺手看 GC：长停顿会把“勉强能过”变成“必然超时”。

七、写在最后

这场事故里最容易走偏的决策是“加机器”。当时组里 6 个消费者，第一反应是扩到 12 个——结果第一次试就发现 rebalance 更慢了：成员越多，一次重平衡要协调的参与者越多，抖动窗口从 20 秒拉长到 90 秒，积压反而涨得更快。

Kafka 的消费积压从来不是“机器不够”的问题，是**单批处理时间与组存活窗口的赛跑**。把批次拉小、把处理批量化、把幂等做扎实，这三件事做完，6 个消费者就能吃掉原来 12 个吃不动的流量。