Kafka 抛弃 Zookeeper（引入 KRaft 模式）是为了解决长期依赖 Zookeeper 带来的性能瓶颈、架构复杂度、可扩展性限制等核心问题。这一变革并非否定 Zookeeper 的价值，而是 Kafka 作为高吞吐消息系统，在规模和性能需求爆发式增长后，对自身架构的一次“去耦合”与“性能重构”。

在 Kafka 早期架构中，Zookeeper 承担着元数据存储、集群协调、控制器选举等关键角色：

• 存储元数据：如主题（Topic）的分区信息、副本分布、 broker 列表等；
• 集群协调：管理 broker 上线/下线、分区副本再平衡（Rebalance）；
• 控制器选举：当集群中“控制器”（Controller，负责分区leader选举的核心节点）故障时，通过 Zookeeper 重新选举新控制器。

但随着 Kafka 集群规模扩大（如十万级分区、数百个 broker），Zookeeper 的局限性逐渐成为瓶颈：

1. 性能瓶颈：元数据操作效率低下

Zookeeper 本质是一个分布式协调服务，而非为高吞吐元数据管理设计的存储系统，其核心问题在于：

• 写入性能有限：Zookeeper 采用“主从复制”和“强一致性”设计，所有写入需经过 Leader 节点并同步至 Follower，单集群每秒写入能力通常在 1000-2000 次 级别。而 Kafka 集群在大规模场景下（如频繁创建主题、调整分区、broker 上下线），元数据更新频率可能远超 Zookeeper 承载能力，导致操作延迟飙升（从毫秒级增至秒级）。
• 元数据膨胀：Kafka 的每个分区都需在 Zookeeper 中存储大量节点（如 /brokers/topics/[topic]/partitions/[p]/state），当分区数达到十万甚至百万级时，Zookeeper 的内存和磁盘压力剧增，甚至出现“节点数超限”（Zookeeper 单节点默认最多存储约 10 万个节点）的问题。
• 额外网络开销：Kafka broker 需频繁与 Zookeeper 通信（如定期心跳、元数据同步），当集群规模扩大时，这种跨进程通信的网络延迟和带宽消耗不可忽视。

2. 架构复杂度：多系统协同成本高

依赖 Zookeeper 意味着 Kafka 集群的部署、维护、故障排查需同时兼顾两个独立系统：

• 部署成本：需单独规划 Zookeeper 集群（至少 3 节点），且需保证其与 Kafka broker 的网络连通性和性能匹配；
• 故障排查难度：当 Kafka 出现“分区不可用”“控制器选举失败”等问题时，需同时排查 Kafka 自身日志和 Zookeeper 日志，定位问题链路长（例如：控制器选举失败可能是 Zookeeper 超时，也可能是 Kafka 与 Zookeeper 通信故障）；
• 版本兼容性：Zookeeper 版本升级需同步验证与 Kafka 的兼容性，增加了系统维护的复杂度。

3. 可扩展性限制：无法适配超大规模集群

Kafka 的核心优势是“高吞吐、高扩展”，但 Zookeeper 的设计限制了其向更大规模演进：

• 分区数量上限：如前所述，Zookeeper 对节点数量的限制（单集群约 10 万节点）直接限制了 Kafka 的分区总数（每个分区至少对应 1 个 Zookeeper 节点），而现代大数据场景（如实时数仓、日志中台）常需要百万级分区支持；
• 控制器选举效率低：当控制器故障时，Kafka 需通过 Zookeeper 的“临时节点竞争”机制重新选举控制器，这一过程涉及多次 Zookeeper 读写，在大规模集群下可能耗时 10-30 秒，期间分区 leader 无法选举，影响服务可用性；
• 再平衡（Rebalance）性能差：当 broker 下线或新增时，Kafka 需通过 Zookeeper 同步分区副本信息并触发再平衡，这一过程在分区数众多时会因 Zookeeper 读写延迟变得极其缓慢（甚至数分钟）。

二、KRaft 模式：Kafka 自研的元数据管理方案

为解决上述问题，Kafka 从 2.8 版本开始引入 KRaft（Kafka Raft Metadata Quorum） 模式，核心是用 Kafka 自身的 Raft 协议替代 Zookeeper，实现元数据的自主管理。

KRaft 模式的核心设计是将集群节点分为两类：

• 控制器节点（Controller Nodes）：组成 Raft 集群（通常 3-5 节点），负责元数据存储、一致性维护、控制器选举；
• broker 节点（Broker Nodes）：负责处理消息读写，通过与控制器节点同步元数据（无需再依赖 Zookeeper）。

KRaft 解决了 Zookeeper 的哪些问题？

1. 元数据管理效率提升 10 倍以上
   KRaft 直接将元数据存储在控制器节点的本地日志中（类似 Kafka 的消息日志），并通过 Raft 协议保证一致性。相比 Zookeeper：

   • 元数据写入不再受限于 Zookeeper 的性能瓶颈，支持每秒 10 万+ 次元数据操作（如创建分区、更新副本状态）；
   • 元数据以“日志流”形式存储，天然支持高吞吐和水平扩展（可通过增加控制器节点提升容量）；
   • broker 仅需与控制器节点同步元数据，减少了跨系统通信的网络开销。

2. 架构简化：单一系统运维
   移除 Zookeeper 后，Kafka 集群仅需部署 Kafka 节点（控制器 + broker），无需维护独立的 Zookeeper 集群：

   • 部署步骤减少 50%（无需单独配置 Zookeeper 的 quorum、端口、数据目录等）；
   • 故障排查链路缩短（元数据问题仅需分析 Kafka 自身日志）；
   • 版本升级仅需关注 Kafka 自身，避免跨系统兼容性问题。

3. 可扩展性突破：支持百万级分区
   KRaft 取消了 Zookeeper 对节点数量的限制，理论上支持百万级分区：

   • 元数据存储不再依赖 Zookeeper 的节点结构，而是采用更紧凑的二进制格式，大幅降低内存占用；
   • 控制器选举基于 Raft 协议，无需 Zookeeper 参与，故障恢复时间从“秒级”缩短至“毫秒级”（通常 < 1 秒）；
   • 再平衡过程通过控制器节点直接协调，避免了 Zookeeper 的中间环节，大规模集群下再平衡时间从“分钟级”降至“秒级”。

4. 更优的一致性模型
   Zookeeper 采用“最终一致性”模型（部分操作如 watch 机制存在延迟），而 KRaft 基于 Raft 协议实现强一致性，元数据更新的可见性更可靠，减少了因元数据不一致导致的“分区不可用”“数据丢失”等问题。

三、从 Zookeeper 到 KRaft：并非一蹴而就的替代

Kafka 团队并未激进地直接删除 Zookeeper 支持，而是采用渐进式迁移策略：

• 兼容期：Kafka 2.8+ 版本同时支持“Zookeeper 模式”和“KRaft 模式”，用户可根据需求选择；
• 功能补齐：KRaft 模式在早期版本（2.8-3.0）存在部分功能缺失（如不支持某些安全特性），但在 3.3+ 版本已基本补齐，可覆盖绝大多数生产场景；
• 迁移工具：提供 kafka-metadata-migrate 工具，支持从 Zookeeper 模式平滑迁移至 KRaft 模式（元数据无缝同步）。

总结：抛弃 Zookeeper 是 Kafka 规模化的必然

Kafka 依赖 Zookeeper 的设计在早期简化了开发，但随着其在大数据场景的普及（从“消息队列”进化为“流处理平台”），Zookeeper 的性能和扩展性限制逐渐成为瓶颈。

KRaft 模式的核心价值在于：让 Kafka 摆脱对外部协调服务的依赖，通过自研的元数据管理方案，实现更高的性能、更强的扩展性和更简单的架构。这一变革不是否定 Zookeeper，而是 Kafka 为适配超大规模、高吞吐场景做出的“自我进化”——就像成年后的系统，不再需要“外部拐杖”，而是依靠自身力量支撑更大的业务规模。

除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接

本文链接：https://www.lifengdi.com/article/tool/4517