消费积压，按标准剧本加机器：从 3 个消费者加到 6 个。lag 没降，反而在扩容后的十分钟里涨得更快。日志里每 30 秒出现一次 Revoking previously assigned partitions，业务方看到的是"每隔半分钟，所有消费者一起停 40 多秒"。

两个独立的问题叠在一起：加机器不一定增加并行度（分区数是硬上限），而加机器本身会触发一次全组暂停（再均衡期间组内所有成员停止消费）。第一个问题让扩容白花钱，第二个问题让扩容当场造成二次事故。

这篇把再均衡拆成四件：并行的上限在哪、暂停为什么是全组、三种触发源怎么区分、以及哪两个配置项会让它反复发生。

1. 并行的上限是分区数，不是消费者数

一个分区同一时刻只能被一个消费者消费，这是顺序性的代价。所以：

实际并行度 = min(消费者数, 分区数)

第二行就是"加了机器 lag 不降"的最常见解释：三个新消费者拿不到分区，只是多参加了三次再均衡。而扩容前如果不看分区数，这个错误会稳定复现。

// 扩容前的两行核对，能省掉一整次无效扩容
分区数: 6   消费者数: 3   → 可扩到 6，多一个都白加
分区数: 6   消费者数: 6   → 已到上限，要提并行只能扩分区（会打乱 key 顺序）
// 判据：消费者数 == 分区数 时，加机器无效，加分区才有效

2. 为什么暂停的是"整个组"

传统协议（eager）的流程是：任何成员变化 → 全组撤销所有分区 → 重新分配 → 各自恢复。中间那段没有任何消费者在消费。

所以"加一个消费者"的代价不是"那一个消费者启动时间"，而是整个组的一次停机。3 个消费者时，一次再均衡可能是 5 秒；30 个消费者时，可能就是 40 秒——组越大，代价越高，这与直觉相反。

// cooperative（增量协作）与 eager 的差别：只撤需要迁移的分区
// 配置一行即可切换，但要求客户端与服务端版本都支持
props.put("partition.assignment.strategy",
    "org.apache.kafka.clients.consumer.CooperativeStickyAssignor");
// eager:   revoke ALL  → 全组暂停
// cooperative: revoke PART → 只有迁移中的分区短暂停

3. 三种触发源，怎么区分

日志里都是 Revoking，但原因不同，修法完全不同。

第三、四行是"反复 rebalance"的两大来源，而它们在日志里长得几乎一样：都是"某个成员被踢出，然后全组重来"。区分方法只有一个：看被踢的时间点与处理耗时/GC 时间是否对得上。

// 区分 poll 超期与心跳超时：前者一定有"处理耗时 > 阈值"
$ grep -E "Member .* has left|rebalance" consumer.log | tail -20
// 若被踢的成员正在处理一批大消息 → max.poll.interval 太小
// 若被踢时 GC 日志有长停顿 → session.timeout 太小，或堆太小
$ grep -E "Full GC|Pause" gc.log | awk '{print $NF}' | sort -rn | head -3

4. 那个恶性循环：处理慢 → 被踢 → 再均衡 → 更慢

这是积压场景里最典型的自我放大：

1. 积压变多 → 每批拉更多消息；
2. 处理一批的耗时超过 max.poll.interval.ms（默认 5 分钟）；
3. 协调器认为该成员死了，踢出组；
4. 触发全组再均衡，暂停期间积压继续增长；
5. 恢复后每批更大，处理更慢 → 回到 1。

正确顺序是先降 max.poll.records，再考虑调大 max.poll.interval.ms。前者让单批处理时间落在阈值内（治因），后者只是放宽宽容度（治标）——而放宽阈值会让"真卡死"的成员更久才被发现。

// 一个稳的起点：单批处理时间目标 << max.poll.interval
consumer:
  max.poll.records: 100              // 处理 100 条 ≈ 10s，远小于 300s
  max.poll.interval.ms: 300000       // 保持默认，不因积压而放宽
  session.timeout.ms: 45000
  heartbeat.interval.ms: 15000
  // 若单条处理就要 5s，那就该改架构（异步化/批处理下沉），不是调参

5. static membership：把"滚动重启"的代价降到零

滚动发布时，每个实例重启都会触发一次再均衡。10 个实例就是 10 次全组暂停——发布期间的积压有一半是发布自己造成的。

group.instance.id（Kafka 2.3+）让协调器"记住"成员：同一 id 在 session.timeout 内重连，直接拿回原来的分区，不触发再均衡。

// 一次 10 实例滚动发布的两种结果
eager + 无 static id:     10 次 rebalance，累计暂停约 7 分钟
cooperative + static id:   0 次 rebalance，单实例重启约 8 秒
// 差别不在客户端性能，而在"协调器是否记得你"

组合使用的效果可以量化：一次 10 实例滚动发布，从"10 次再均衡、累计暂停 6–8 分钟"降到"0 次再均衡"。

6. 排错：五种"扩容反而更糟"

第五行是硬边界：扩分区会改变 hash(key) % partitions 的结果，同一业务 key 的历史消息在新旧分区之间失去顺序。所以"顺序敏感"的 topic 只能扩消费者到分区数为止，再往上要走别的路。

7. 边界：什么情况不该靠扩容解决

判断口径一句话：先看"并行度上限"（分区数）再看"单条处理成本"，两者都没到顶才轮到扩容；而扩容这个动作本身要付出一次全组暂停，所以它必须排在生产突增之外的时间窗里做。顺序反了，就是本文开头那个场景：lag 没降，还多了一次事故。

8. 自测

1. 并行度的实际上限由什么决定？消费者数超过它会发生什么？
2. 为什么"加一个消费者"的代价是整个组暂停，而不是那一个的启动时间？
3. max.poll.interval.ms 太小会怎样？它和 session.timeout.ms 的区别是什么？
4. 积压场景下"处理慢 → 被踢 → 再均衡 → 更慢"的循环怎么打断？应该先调哪个参数？
5. static membership 解决的是哪类再均衡？为什么它能让滚动发布期间零暂停？
6. 什么情况下不能通过扩分区来提升并行度？

9. 一句话总结

扩容消费者的两个约束是分开的：并行度上限由分区数决定（超过就白加），而扩容动作本身要付一次全组暂停（eager 再均衡）。反复再均衡几乎总是 max.poll.records 与处理耗时错配，修法是降批大小而不是放宽超时；滚动发布的暂停用 static membership 消掉。判据：先看分区数，再看单条成本，两者都没到顶才谈扩容，且扩容要避开流量高峰。