题干与适用场景
这道题考察分布式所有权迁移，而不是记忆某个 Kafka 配置。eager 再平衡会先撤销全部分区，cooperative 再平衡允许成员保留不必迁移的分区，只撤销需要移动的部分。回答需要说明成员版本、assignor 协议、offset 提交、故障窗口和观测指标。
面试官考察什么
- 能否解释 eager 与 cooperative 的撤销和交接差异。
- 能否设计兼容的滚动升级顺序，避免新旧成员协商失败。
- 能否把分区所有权、offset、处理中的消息和提交时机对应起来。
- 能否处理崩溃、超时、重复消费、回滚和容量不足。
回答前需要澄清的问题
确认 Kafka 客户端版本、当前 assignor 列表、是否启用静态成员、单条消息处理时长、允许的重复消费窗口和 rebalance 延迟预算。还要问清楚消息是否可幂等处理、下游是否支持去重，以及发布系统能否分阶段回滚。最后确定扩缩容峰值、分区数和监控告警阈值。
30 秒回答框架
先让所有成员升级到支持 cooperative 协议的版本，但保留兼容的 assignor 列表；确认组内协议一致后，再通过滚动发布把 CooperativeStickyAssignor 设为首选并移除旧策略。每次 rebalance 只撤销需要移动的分区，消费者在 revoke 回调中停止拉取并提交已完成 offset，接收者从已提交 offset 继续。监控 rebalance 次数、撤销分区数、处理延迟和重复率；崩溃时依靠 session timeout 和 offset 恢复，回滚则恢复旧配置并再次滚动。
分步骤深入解答
1. 定义协议与兼容矩阵
Kafka 的 assignor 是组级协商结果，不能只改一台实例。先把客户端升级到支持 cooperative 的版本，确保所有实例都能解析同一协议；旧成员仍在组内时，不能让新成员单方面假设 cooperative。配置示意如下：
partition.assignment.strategy=\
org.apache.kafka.clients.consumer.CooperativeStickyAssignor,\
org.apache.kafka.clients.consumer.RangeAssignor第一阶段保留兼容项完成滚动升级，第二阶段在全组支持后把 cooperative 设为首选并移除旧项。每一阶段都要验证组的实际协议和 assignment 结果，而不是只检查配置文件。
2. 设计分区撤销与交接
cooperative rebalance 的 revoke 集合只包含必须迁移的分区。消费者收到 revoke 后停止拉取这些分区，完成或放弃当前批次，再同步提交已处理 offset；未被撤销的分区继续消费。新持有者从提交 offset 开始，重复消息由业务幂等键或下游去重处理。
3. 处理 offset 与处理中的消息
提交 offset 必须晚于业务副作用，避免先提交后处理造成丢失。批处理过程中收到 revoke 时，设置停止标志，让处理器在安全点结束；超时则停止继续拉取并记录未完成批次。若采用异步处理，需维护分区内序号，只有连续完成的前缀才能提交。
4. 规划滚动发布步骤
发布控制器按小批次重启成员，每批等待组稳定和 lag 恢复。步骤包括：记录基线、升级客户端、观察协议、切换首选 assignor、逐步扩缩容演练、再扩大批次。任何阶段出现 rebalance 风暴或延迟超阈值，都暂停推进，不要同时修改 session timeout、max poll interval 等多个变量。
5. 设计故障与回滚
成员崩溃时，协调器在 session timeout 后重新分配其分区；新成员从最后提交 offset 恢复，可能重复处理崩溃前已产生副作用的消息。回滚时把旧 assignor 放回兼容列表，按同样的滚动顺序恢复，不要强行删除仍在运行的新成员。记录 generation、成员 ID、分区撤销和提交失败，便于定位交接竞态。
6. 建立容量与观测护栏
核心指标包括 rebalance 频率与持续时间、每次撤销分区数、consumer lag、poll 间隔、提交延迟、重复消费率和未分配成员数。压测至少覆盖成员同时重启、热点分区、处理时间超过 max.poll.interval、网络抖动和分区数接近成员数。容量不足时先降低发布批次或增加消费者，再继续迁移。
高质量示范回答
我会先确认所有客户端都支持 cooperative 协议，再采用两阶段滚动配置：第一阶段保留兼容 assignor 完成版本升级，第二阶段把 CooperativeStickyAssignor 设为首选并移除旧策略。revoke 回调只停止即将迁移的分区，先完成安全点并提交连续 offset；未撤销分区继续工作。新持有者从已提交 offset 读取，重复消费由幂等键处理。发布控制器按小批次推进，观察 rebalance、lag、poll 间隔、提交失败和重复率。崩溃依靠 session timeout 重新分配，回滚使用兼容列表和同样的滚动顺序，避免强制清理正在运行的成员。
常见错误
- 只改一台消费者配置，忽略 assignor 是组级协商。
- 把 cooperative 当成完全没有暂停，忽略被撤销分区仍需交接。
- 在业务副作用前提交 offset，造成消息丢失。
- revoke 时继续拉取或提交不连续的异步结果。
- 同时调整多个超时参数，无法判断延迟变化来源。
- 只看 lag，不观察 rebalance 频率、撤销集合和重复消费。
追问及应对
cooperative 能保证零重复吗？
不能。崩溃、提交重试和 revoke 边界都可能造成重复，目标是减少全组暂停并把重复窗口控制在可接受范围。下游仍需幂等或去重。
为什么必须全组支持 cooperative？
assignor 协议需要成员共同协商。旧成员不能解析或执行 cooperative 语义时，混用会导致协商失败或回到 eager 行为，因此要先完成兼容版本升级。
处理时间超过 max.poll.interval 怎么办？
拆小批次、把处理移到可控的异步池或调整参数，并确保每次 poll 仍按时调用。不能只增大超时而忽略失败检测变慢和分区占用时间变长。
如何验证回滚安全？
在预发布组注入成员崩溃、网络抖动和提交失败，记录 generation、offset、撤销集合与副作用去重结果；验证旧 assignor 能在兼容矩阵内重新稳定，且没有跳过未提交 offset。