消费者 Rebalance 会带来哪些问题？
简化版
Rebalance 会撤销并重新分配分区，期间可能暂停消费；若位点提交和在途处理衔接不当，还会重复或跳过消息。治理重点是减少无意义成员变化、缩短撤销时间，并在回调中停止拉取、处理或放弃在途任务、可靠提交后再交出分区。
详细版
触发包括成员加入/退出、心跳超时、订阅变化和分区扩容。Eager 协议可能一次撤销全部分区，Cooperative/Incremental 只迁移必要分区，但应用仍必须正确处理 revoke/assign。长处理阻塞 poll 会被判失联，频繁扩缩容也会形成 Rebalance 风暴。
应设置合理 session timeout、heartbeat 与 max poll interval，采用静态成员和协作式分配降低抖动；在 revoke 时停止新任务、等待有界在途处理并同步提交已完成位置。监控 Rebalance 次数/耗时、消费暂停、重复率和最老 lag，并用幂等消费兜底。
完整版教学
一、Rebalance 在做什么
消费组要保证一个分区同一时刻由组内一个成员负责。当成员集合或订阅元数据变化时，协调器重新计算 partition -> member 映射。它是恢复与扩缩容机制，但迁移边界处理不当就会影响可用性与处理语义。
记忆钩子：Rebalance 不是单纯“重新连一下”，而是分区所有权的一次交接。
二、常见触发原因
正常发布、扩容、消费者崩溃、网络抖动、心跳超时、处理时间超过 max poll interval、Topic 增加分区和订阅表达式匹配变化都会触发。若实例启动慢又被健康检查反复拉起，会形成持续成员变化。
| 触发 | 是否预期 | 优先检查 |
|---|---|---|
| 滚动发布 | 是 | 静态成员/批次 |
| 心跳超时 | 否 | GC、网络、CPU |
| poll 超时 | 否 | 单条耗时、线程模型 |
| 分区扩容 | 是 | 容量与顺序 |
三、为何会重复消费
消费者已处理到 offset 100，但持久化进度只确认“offset 90 已完成”（按 Kafka 的 next-offset 语义提交值为 91）就被撤销；新 owner 从 91 开始，会重复 91～100。若把提交值提前推进到 101、但 91～100 的业务写入尚未成功，则会跳过消息。因此位点只能推进到“连续完成”的下一位置，业务处理仍需幂等。
processed: 91 ... 100
committed: 91 # next offset semantics示意
rebalance -> new owner resumes from committed position具体提交语义要以所用客户端为准，避免把“最后完成 offset”和“下一待消费 offset”混淆。
四、Eager 与 Cooperative 的差别
Eager Rebalance 先撤销所有成员的全部分区，再统一分配，停止窗口大。Cooperative Sticky 允许成员逐步交还需要迁移的分区，未迁移分区继续消费，可降低停顿；但客户端和协议版本必须兼容，回调逻辑仍不可省略。
协作式方案减少影响范围，不会消除成员抖动、重复处理或慢消费者问题。
从 Eager 切换到 Cooperative 协议时要按客户端文档分阶段升级，确保组内成员支持兼容策略；混用不兼容分配协议会导致无法加入组或反复协商。
五、撤销回调怎样写
收到 revoke 后停止对应分区继续拉取，给在途任务一个小于协调超时的完成窗口，提交连续完成位置；未完成任务取消或让新 owner 重放。不要在回调里无限等待慢 RPC，否则整个组迁移被拖住。
若并行处理同一分区，offset 103 已完成但 102 未完成时不能提交到 104，需要维护完成水位或限制分区内并发。
六、参数与稳定性治理
处理 99.9% 在 2 秒内、偶发 20 秒时，应把长任务移出 poll 线程或暂停分区，而不是盲目把所有超时调到数分钟。静态 membership 可让短暂重启保留身份，滚动发布控制批次，扩缩容设置冷却时间。
监控 Rebalance rate/duration/reason、无消费窗口、成员数、分区分配倾斜、commit lag、重复命中和 max poll 超时。一次 30 秒迁移在每分钟发生，比单次 2 分钟计划迁移更危险。
七、常见误区与追问
- 误区：Rebalance 只会影响吞吐。 位点交接不当还会重复或漏消息。
- 误区：把 session timeout 调大就解决。 只会推迟故障发现，根因可能仍是阻塞 poll。
- 误区：Cooperative 协议不会暂停。 被迁移分区仍需安全交接。
- 误区：提交最新拉取位置最安全。 未完成消息可能被跳过。
- 追问：如何减少发布触发的抖动？ 静态成员、协作分配和小批滚动。
- 追问：长任务如何处理？ 与 poll 解耦、pause 分区并维护连续完成水位。
- 追问：为什么仍需幂等？ 崩溃窗口无法靠位点提交彻底消除重复。
八、加强记忆
Rebalance 按“触发—撤销—提交—分配—恢复”理解。稳定性靠减少成员抖动和协作式迁移，正确性靠撤销时只提交连续完成位置，最终靠幂等承受重复。参数必须匹配处理时长，不能用放大超时掩盖阻塞与故障。