Linux Kafka版本选择建议

Linux 上 Kafka 版本选择建议

一 选择原则

• 明确运行模式与 Java 版本：若希望摆脱 ZooKeeper 依赖、简化部署，优先选择 KRaft 模式（Kafka 4.0+ 默认启用）；若受限于存量环境或工具链，可在 3.x 上继续使用 ZooKeeper 模式。Java 方面，Kafka 4.0+ 不再支持 Java 8，建议 Java 11+；Kafka 2.0+ 起已不再支持 Java 7。
• 聚焦关键业务特性：需要 Exactly-once（EOS） 语义（幂等 Producer、事务）应选 0.11.x 及以上；需要 Kafka Streams 应选 0.10.0.0 及以上；需要 ZStandard 压缩 应选 2.1.0 及以上。
• 重视安全与维护：旧版本存在较多 安全漏洞 且难以修复，生产环境应尽量选择 较新的稳定大版本 并持续打补丁。
• 版本命名与 Scala 发行包：自 1.0.0 起采用 Major.Minor.Patch；下载包名形如 kafka_2.13-3.8.0.tgz，其中 2.13 是 Scala 版本，跨 Scala 版本一般可互通，优先选较新的 Scala 发行包（如 2.13）。

二 推荐版本矩阵

三 兼容性与升级要点

• 服务端/客户端版本：尽量保持 服务端与客户端的 Kafka 版本一致；跨大版本混用时，可能出现协议或特性不兼容（如 EOS、KRaft 等要求对应的客户端能力）。
• 协议与消息格式：升级可遵循“先滚动升级 Broker → 再逐步升级客户端”的路径；必要时通过参数控制协议与消息格式版本，例如设置 inter.broker.protocol.version 与 log.message.format.version，实现与旧客户端/特性的兼容过渡。
• KRaft 与 ZooKeeper：KRaft 是 4.0 默认 的元数据管理方案；若从 ZooKeeper 模式迁移，需按官方步骤完成元数据迁移与验证，再切换生产流量。

四 快速决策清单

• 运行环境为 Java 8 且短期无法升级 → 选 3.8.x（ZooKeeper 或 KRaft）。
• 可升级 Java 11+、希望架构简化 → 选 4.0.x（KRaft 默认）。
• 需要 EOS/事务 或 Kafka Streams → 选 0.11.x+ / 0.10.0.0+，并结合上表的 Java 与模式约束。
• 存量依赖重、升级窗口长 → 选 3.3.2（2.13） 作为过渡，并制定向 3.8.x/4.0.x 的升级计划。