题干与适用场景
一个多租户 Kafka 集群仍运行 ZooKeeper，团队计划迁移到 KRaft 并升级到 Kafka 4.2。集群使用事务生产者、Kafka Streams 和 Connect，不能接受消息丢失、重复提交或长时间停机。请设计迁移前检查、滚动升级、元数据版本门禁、客户端兼容性、故障恢复和回滚方案。
面试官考察点
- 能否先识别 Kafka 4.2 只支持 KRaft，避免把升级当成普通 broker 替换。
- 能否区分软件版本、metadata.version 与迁移状态。
- 能否识别 4.2.0 Streams 离线迁移缺陷和事务生产者滚动升级修复，选择 4.2.1。
- 能否覆盖控制器仲裁、broker、客户端、Connect 和 Streams 的验证边界。
- 能否说明何时可回滚、何时元数据升级后只能前进。
回答前需要澄清的问题
- 当前 Kafka、ZooKeeper、客户端和 Streams 版本分别是什么？是否已经达到 KRaft 迁移要求？
- 事务生产者的幂等、事务超时和未完成事务数量如何观测？
- 集群是否有跨区域副本、MirrorMaker 或可验证的恢复集群？
- 是否使用 Streams Rebalance Protocol、Share Groups 或其他 4.2 新功能？
- 业务可以接受怎样的滚动窗口、消费者再平衡和回滚时间？
30 秒回答
我会先把 4.2 视为架构迁移：ZooKeeper 集群必须先迁到 KRaft，不能直接升级。目标版本选择 4.2.1，避免 4.2.0 已知的 Streams 离线迁移缺陷和事务生产者滚动升级问题。迁移前冻结高风险变更，盘点客户端、事务、Streams 状态和恢复副本；先滚动升级软件，观察行为和性能，再单独提升 metadata.version。每一步都设置消息端到端、事务提交、消费者滞后、控制器仲裁和 Streams 状态校验。失败时停在尚未提升元数据的阶段，或按支持的路径恢复到兼容版本，不把已发生的元数据变更当作可逆开关。
分步骤深入解答
1. 画出版本与状态矩阵
Kafka 4.2 只支持 KRaft，ZooKeeper 模式必须先迁移。软件版本、元数据版本和控制器仲裁状态是三个独立维度。先确认当前版本至少满足迁移前提，记录 broker、controller、客户端、Connect、Streams 和协议版本；将每个状态写入可审计清单。
ZooKeeper 集群 -> KRaft 迁移完成 -> 滚动升级 broker/controller -> 验证 -> 提升 metadata.version
| | | |
+-- 不满足前提 --+--------------------+--------> 停止，不进入下一阶段2. 选择修复版本与迁移顺序
使用 4.2.1 作为目标版本。官方升级说明列出 4.2.1 修复了事务生产者滚动升级可能触发的 UnsupportedVersionException，也修复了 Streams Rebalance Protocol 的离线迁移缺陷；4.2.0 不应执行受影响的 classic 到 streams group 迁移。先升级工具链和客户端兼容矩阵，再按一次一个 broker 的方式滚动升级，避免同时改变多个故障域。
3. 处理元数据与控制器门禁
滚动升级完成后先观察集群行为和性能，再运行 kafka-features.sh 提升目标 metadata.version。门禁包括 controller quorum 稳定、选主无异常、元数据传播延迟、ISR 和磁盘健康。4.2 的文档说明该版本没有元数据变更时可支持降级，但不能把所有未来版本都视为可降级；每个目标版本都要检查 metadata 兼容性。
4. 验证事务、Streams 与 Connect
事务验证覆盖生产者 epoch、提交和 abort、重启恢复、重复消息和事务超时。Streams 验证覆盖状态存储恢复、再平衡、changelog、处理语义和离线迁移路径；Connect 验证 offset、任务重启和外部系统幂等。对每类客户端做端到端生产—消费校验，不能只看 broker 健康。
5. 观测与故障演练
记录 controller 选举、元数据版本、broker 日志、请求错误、事务状态、消费者滞后、Streams 状态恢复、Connect 任务和磁盘增长。演练 broker 重启、controller 失联、事务生产者中断、Streams 迁移失败和客户端版本不兼容；每个故障都要有停止升级和恢复条件。
6. 回滚与恢复边界
在提升 metadata.version 前，保留旧版本二进制、配置、快照和恢复集群，并定义只读验证窗口。若滚动升级阶段失败，可停止在兼容版本并恢复 broker；一旦发生不支持降级的元数据变更，回滚应转为恢复到兼容快照或新集群重建，不应强行替换二进制。业务恢复优先保证事务和 offset 的一致性，再恢复吞吐。
高质量示范回答
我先确认目标不是普通版本升级：Kafka 4.2 移除了 ZooKeeper 支持，旧集群必须先完成 KRaft 迁移。我选 4.2.1，因为官方升级说明明确列出事务生产者滚动升级和 Streams 离线迁移修复。迁移前盘点 broker、controller、客户端、Connect、Streams、事务和恢复副本，建立版本与状态矩阵。
执行时一次滚动一个 broker，先验证 controller quorum、ISR、延迟和行为，再提升 metadata.version。事务验证检查 epoch、commit、abort、重启和重复；Streams 检查状态存储、changelog、再平衡和迁移；Connect 检查 offset 与任务恢复。整个过程记录元数据版本、选举、滞后和错误率。元数据升级前失败可停在兼容阶段；升级后若不支持降级，按快照或恢复集群重建，不强行回退二进制。
常见错误
- 直接把 ZooKeeper broker 替换成 Kafka 4.2，忽略 KRaft 前置迁移。
- 只看 broker 存活，不验证事务、Streams 状态、Connect offset 和端到端消息。
- 在未观察滚动升级结果前立即提升
metadata.version。 - 使用 4.2.0 执行官方已知存在风险的 Streams 离线迁移。
- 把 metadata.version 当成普通配置，认为随时可以降级。
- 没有恢复集群、快照和停止升级的明确门禁。
追问及应对
为什么不能直接升级 ZooKeeper 集群到 Kafka 4.2？
Kafka 4.2 只支持 KRaft，ZooKeeper 模式已移除。必须先完成迁移并验证控制器仲裁，再进入 4.2 的滚动升级路径。
什么时候提升 metadata.version？
所有 broker/controller 软件升级并稳定运行后，确认 quorum、ISR、客户端错误和性能指标，再单独提升；这样能把代码问题与协议启用问题分开。
元数据升级后发现 Streams 状态恢复失败怎么办？
立即停止继续提升版本，保留现场和日志，按支持的恢复快照或新集群重建路径恢复。不要直接降级二进制或删除 changelog 来掩盖状态不一致。