版本演进与升级
逐版本差异
| 版本 | 主要变化 | 升级关注点 |
|---|---|---|
| 0.8～0.10 | 副本、Consumer 新 API、Broker 协议逐步形成 | 历史客户端和 ZooKeeper Offset |
| 0.11 | 幂等 Producer、事务、Record Batch 新格式 | 跨版本消息格式与客户端兼容 |
| 1.x～2.x | Exactly-Once、Consumer Group、Kafka Streams 和协议持续成熟 | 清理旧 API 与旧消息格式 |
| 2.8 | KRaft 早期可用，ZooKeeper 仍是生产主线 | 不把早期 KRaft 直接当成熟迁移终点 |
| 3.0～3.5 | KRaft 持续成熟，弃用旧协议和配置 | 为 ZooKeeper 到 KRaft 迁移做准备 |
| 3.6～3.9 | KRaft 迁移能力、Controller 和客户端持续增强 | 3.9 是进入 4.0 前的重要桥接线 |
| 4.0 | 移除 ZooKeeper 模式；要求 KRaft，清理旧协议/API | 必须先完成元数据迁移和兼容检查 |
| 4.1～4.2 | KRaft、Consumer Rebalance、Streams 和运维继续演进 | 检查客户端与协议默认值 |
| 4.3 | 当前正式主线，最高正式 Patch 为 4.3.1 | 使用最新 Patch，逐项读取 Release Notes |
升级原则
- 先升级客户端兼容性和 Broker，再提升协议或 Metadata Version。
- Rolling Upgrade 期间保持服务端允许的兼容版本，不能先启用新协议破坏回滚。
- ZooKeeper 集群进入 4.x 前，必须在受支持的 3.x 路径完成 KRaft Migration。
- 备份配置、ACL、SCRAM 凭据、Topic/Partition/Replica 清单和 Consumer Group Offset。
- 验证 Producer 幂等/事务、Consumer Rebalance、Kafka Streams 状态与 Connector。
- 协议或 Metadata Version 最终升级后，回滚能力可能受到限制。