Kafka为什么要抛弃 Zookeeper？

【核心定义】
Kafka 从 2.8 版本开始引入 KRaft 模式（Kafka Raft），逐步替代 ZooKeeper 作为其元数据管理组件，以实现更简单、更稳定、更高性能的架构。

【关键要点】

1. 架构简化：移除 ZooKeeper 后，Kafka 从“外部依赖架构”变为“自包含系统”，减少了外部组件的部署、运维和故障排查成本。
2. 性能提升：KRaft 协议直接内置于 Kafka 控制器节点，元数据操作延迟降低，集群启动和故障恢复速度更快。
3. 可扩展性增强：ZooKeeper 的写入吞吐存在瓶颈，KRaft 通过 Kafka 自身分区机制水平扩展元数据管理能力。
4. 运维统一：监控、安全、备份等运维体系可完全基于 Kafka 生态工具，无需跨组件协调。
5. 版本演进：这是 Kafka 长期架构演进的必然方向，从 2.8（实验支持）到 3.0+（生产就绪）逐步成熟。

【深度推导/细节】
核心矛盾：ZooKeeper 作为独立 CP 系统，与 Kafka 的 AP 设计哲学存在架构冲突。

• 元数据同步路径：
  • 旧架构：Producer/Consumer → Kafka Broker → ZooKeeper → Kafka Controller → 同步至 Brokers。
  • KRaft 架构：Producer/Consumer → Kafka Broker → Kafka Controller（基于 Raft 共识） → 同步至 Brokers。
• 关键数字解析：
  • 3节点 ZooKeeper 集群：旧架构最小高可用部署需至少 3 节点 ZooKeeper + 3 节点 Kafka，KRaft 仅需 3 节点 Kafka（同时承载数据与元数据）。
  • 元数据延迟：ZooKeeper 模式下，控制器选举依赖 ZooKeeper 会话超时（默认 6-18秒），KRaft 基于 Raft 心跳（毫秒级）实现更快控制器故障切换。
• 扩容瓶颈：ZooKeeper 写性能随节点数增加而下降，而 KRaft 可将元数据分区（未来支持），突破单命名空间限制。

【关联/对比】

• ZooKeeper vs KRaft 共识协议：
  • ZooKeeper 使用 ZAB 协议，强一致但写入需全局序列化；KRaft 使用 Raft 协议，日志复制更简单，易于理解和实现。
• 与类似系统对比：
  • 类似 Elasticsearch 移除 ZooKeeper（自研 Zen2），Kafka 通过 KRaft 实现“去中心化元数据管理”趋势。
• 版本差异：
  • 2.8 前：强依赖 ZooKeeper。
  • 2.8-3.0：支持 KRaft 实验模式，可并行运行。
  • 3.0+：KRaft 生产就绪，官方推荐新集群使用 KRaft。
  • 4.0（规划）：完全移除 ZooKeeper 依赖。

『面试官追问』

1. KRaft 模式下控制器选举与 ZooKeeper 有何不同？
   • KRaft 控制器通过 Raft 协议选举，所有 Broker 节点可参与投票；ZooKeeper 模式下控制器由 ZooKeeper 临时节点触发选举，存在二次选举延迟。
2. 迁移到 KRaft 有哪些风险？
   • 旧客户端兼容性、监控工具适配、运维经验缺失，且 KRaft 在超大规模集群（如 >10万分区）的稳定性仍需验证。
3. 为什么 Kafka 不直接用 ZooKeeper 而自研 KRaft？
   • 深度耦合 Kafka 语义（如分区状态机）、避免跨系统网络开销、掌握核心技术控制权。

【线程安全】

• KRaft 将元数据操作封装为线程安全的日志追加过程，通过 Raft 日志序列化保证并发安全，避免 ZooKeeper 客户端会话的并发管理复杂度。

【总结】
Kafka 抛弃 ZooKeeper 是向更简洁、高性能、自包含架构演进的关键决策，通过内置 KRaft 共识协议解决元数据管理的扩展性与运维痛点，标志着 Kafka 进入“完全自管理”时代。