题干与适用场景
你负责一个有状态 Kafka Streams 应用，当前使用 classic group protocol。升级到 Kafka 4.2 后，团队希望使用 broker 驱动的 Streams Rebalance Protocol，减少实例加入、离开或故障时的全局协调停顿。面试官要求你给出迁移计划、兼容边界和失败回滚。
假设应用运行在 Kafka Streams 4.2.x，已有 changelog 与 repartition topics，不能接受无计划的全量重建。官方文档说明新协议由 broker 持续计算任务分配，使用独立 streams group；Kafka 4.2 新集群默认启用，但客户端仍需设置 group.protocol=streams。
面试官考察点
- 能否解释 broker 驱动协调如何减少客户端全局同步点，而不是只背配置名。
- 能否区分新建 streams group、classic group 在线升级和离线迁移的不同可行性。
- 是否检查 broker、client 版本及 4.2.0 的 KAFKA-20254 风险。
- 是否知道保留的是 committed offsets，其他 group metadata 会重建，不能承诺无损保留所有运行状态。
- 能否把不支持的 static membership、topology update、regex 等能力转成上线门槛。
普通回答是“改配置并滚动重启”。强回答会先判断版本和功能缺口，再选择新 group 或维护窗口迁移，记录 offset、changelog、repartition topics 与恢复时间目标。
回答前需要澄清的问题
- 当前 Kafka 和 Streams client 是否至少 4.2？否则不能直接启用完整协议。
- 现有应用是否依赖 static membership、在线 topology update、regex subscription 或 standby/ rack-aware assignment？任一依赖都可能阻止迁移。
- 能否安排所有实例停止并等待 group 为空？官方 4.2 迁移路径只支持 offline migration。
- 当前版本是 4.2.0 还是 4.2.1 及以上？4.2.0 的 offline migration 存在已知 broker bug，修复在 4.2.1。
- 是否允许创建新的 application.id？新 group 能隔离风险，但会重新建立状态并改变 offset 管理。
这些答案决定方案：无法停机时不能声称支持 classic 到 streams 的在线迁移；依赖未支持功能时应保留 classic protocol 或先重构应用。
30 秒回答框架
“我先确认 broker 和 client 都是 4.2.x，并盘点应用是否使用新协议尚不支持的功能。Streams Rebalance Protocol 把任务协调放到 broker，减少客户端全局 barrier，但迁移不是普通滚动发布：官方路径要求 group 为空后切换 group.protocol=streams，只有 committed offsets 会保留，changelog 与 repartition topics 继续存在，其余 metadata 会重建。我会避开 4.2.0，优先 4.2.1 以上；迁移前记录 offsets 和状态检查点，迁移后验证恢复、延迟和 rebalance 指标，失败就切回 classic 或用新 application.id 重建。”
分步骤深入解答
1. 说明协议改变了什么
classic Streams group 在客户端计算成员任务分配，成员变化时容易形成全局协调点。新协议把 streams group 的成员元数据和任务分配放到 broker，应用通过专用 heartbeat 与 streams group 协调。官方文档将它描述为 broker-driven，并提供独立的 streams group 状态与 Admin API。
2. 先做能力盘点
Kafka 4.2 当前协议明确有限制：static membership 不可用；显著 topology update 需要新 streams group；只提供 sticky task assignor，warmup tasks 与 rack-aware assignment 不可用；pattern subscription 不支持；classic 与 streams 之间没有在线迁移。把这些列成发布前检查表，避免迁移后才发现配置被忽略。
3. 选择迁移路径
官方 offline 路径是：停止所有实例，等待 session.timeout.ms 到期或显式 leave，使 group 为空；设置 group.protocol=streams；再启动实例。只有 committed offsets 会在 broker 侧保留，changelog 和 repartition topics 仍作为普通内部 topic 存在，其他 group metadata 会重新建立。
停止全部实例
↓
确认 streams group 为空并记录 committed offsets
↓
升级 broker/client 到兼容版本
↓
设置 group.protocol=streams
↓
启动实例，观察恢复与 rebalance 指标如果业务不能接受这段维护窗口，保留 classic protocol，或使用新的 application.id 做并行验证。不要把 classic consumer 的 rolling upgrade 经验直接套到 Streams Rebalance Protocol。
4. 处理版本风险
Kafka 官方升级指南指出，4.2.0 的 classic 到 streams offline migration 受到 KAFKA-20254 broker-side bug 影响，建议不要在 4.2.0 执行；修复已包含在 4.2.1。面试回答应把 4.2.1 作为最低迁移版本，而不是只说“Kafka 4.2 已支持”。
5. 设计状态与 offset 验证
迁移前记录每个输入 topic 的 committed offsets、changelog topic 状态和处理延迟。迁移后验证：新 group 能从预期 offset 继续；state store 能从 changelog 恢复；repartition topic 仍存在且分区数一致；重复处理与丢失记录符合既定语义。将结果与迁移前基线对比，而不是只看进程是否启动。
6. 监控与回滚
使用 streams group 的专用状态、rebalance count/rate、恢复时长、处理延迟和错误率作为观测面。若恢复超时或结果校验失败，停止新 group，保留 committed offsets 与日志，回滚配置到 classic；若 classic group 已被清空，必须依据备份或新的 application.id 重新规划，而不能假设 group metadata 自动回来。
高质量示范回答
“我不会把这次迁移当成普通滚动发布。先确认 broker、client 都是 4.2.x，并检查应用有没有 static membership、在线 topology update、regex subscription、warmup 或 rack-aware assignment 依赖。由于官方只支持 offline migration，我会选 4.2.1 以上，在维护窗口停止全部实例，确认 group 为空，记录 committed offsets 与 state store 检查点，再设置 group.protocol=streams 启动。
“迁移后我会验证 offsets 能继续消费、changelog 能恢复 state store、repartition topics 未丢失，并观察 streams group 状态、rebalance 指标、恢复时长和业务延迟。只有 committed offsets 会保留，其他 group metadata 会重建；4.2.0 还有 KAFKA-20254 风险，所以不能把 4.2.0 当作安全版本。若校验失败，就停止新 group，回到 classic 或使用新的 application.id 重建，并保留证据以便复盘。”
常见错误
- 错误表现：把
group.protocol=streams当成可滚动切换 → 失败原因：Streams protocol 不支持在线迁移 → 修正方法：安排 group 为空的维护窗口。 - 错误表现：在 4.2.0 直接迁移 → 失败原因：官方升级指南记录 KAFKA-20254 → 修正方法：使用包含修复的 4.2.1 及以上。
- 错误表现：承诺所有 group 状态自动保留 → 失败原因：只有 committed offsets 保留，其余 metadata 会重建 → 修正方法：分别记录 offset、state store 和 topic 验证项。
- 错误表现：忽略 static membership 或 topology update → 失败原因：新协议当前不支持这些能力 → 修正方法：迁移前做功能盘点，必要时保持 classic。
追问及应对
业务不能停机，能否两批实例滚动切换？
不能把官方 Streams migration 路径描述成在线滚动切换。若不能停机，先保留 classic，或创建新的 application.id 做双写/影子验证，再用业务层切流承担状态重建成本。
committed offsets 保留了，为什么还要验证 state store？
offset 只说明下一条从哪里读，不证明本地状态已完整恢复。changelog replay、版本不兼容或处理失败都可能让 state store 与 offset 不一致，必须做状态和业务结果校验。
4.2.0 已经是 GA，为什么仍要避开？
GA 表示功能发布，不等于每条迁移路径都没有已知缺陷。官方升级指南明确指出 offline migration 的 KAFKA-20254，修复在 4.2.1；迁移版本应依据修复版本而非只看 GA 标签。
现有应用依赖正则订阅怎么办？
新 streams protocol 当前不支持 pattern-based topic subscription。保持 classic，或把主题发现和订阅逻辑改成显式列表后再评估迁移，不能只改 group protocol。
如何判断是否需要新的 application.id？
如果必须并行验证、旧 group 不能安全清空，或需要隔离状态恢复风险，可以用新的 application.id 创建独立 group；代价是重新消费、重建 state store 和额外资源，应先估算恢复时间与存储成本。
参考资料
- Apache Kafka Streams Rebalance Protocol developer guide。
- Apache Kafka 4.2 Streams Upgrade Guide。
- Apache Kafka 4.2.0 Release Announcement。