为什么kafka放弃了zookeeper呢？

原来的角色

让我们快速理解 Zookeeper（ZK）在整个体系中扮演的角色

1. 元数据管理 (Metadata Management): ZooKeeper 负责存储和管理 Kafka 集群的核心元数据。这包括：
   • Topic 的配置信息
   • 每个分区的 Leader Broker 是谁
   • Broker（节点）的注册信息
2. Controller 选举 (Controller Election): Kafka 集群中有一个 Broker 会被选举为 Controller，负责执行管理任务（如分区分配、Leader 选举等）。ZooKeeper 负责进行这个 Controller 的选举过程。
3. 故障容错 (Fault Tolerance): ZooKeeper 帮助 Kafka 检测集群中 Broker 节点的故障或失效，使得集群能够更容易地处理这些变化。
4. 集群状态维护（支持扩展性） (Scalability / Cluster State Maintenance): ZooKeeper 通过独立维护集群的状态信息，在一定程度上帮助 Kafka 实现了水平扩展。

为什么放弃

kafka放弃zookeeper的主要理由有

降低运维复杂性与成本

• 同时管理 Kafka 和 ZooKeeper 两个独立的分布式系统增加了运维负担，需要额外的专业知识和监控维护工作
• ZooKeeper 中的状态变更传播到 Kafka Controller 可能存在延迟甚至丢失，有时需要重启 Controller 才能解决。
• 运行 ZooKeeper 需要独立的硬件资源（CPU, RAM, Disk I/O, Network）。即使在一个小型 Kafka 集群中，也需要至少 3 台（推荐 5 台）ZooKeeper 服务器来保证高可用。这增加了物理或虚拟资源的成本和管理开销
• 当使用 ZooKeeper 时，你需要为 Kafka 集群和 ZooKeeper 集群分别配置和管理安全机制（如认证、授权 ACLs）。这增加了安全配置的复杂性和潜在的漏洞点

提升可拓展性

随着 Kafka 集群规模的增大，某些操作（如分区重分配）会对 ZooKeeper 造成巨大负载，导致性能下降

减少延迟和提高一致性

Kafka 和 ZooKeeper 之间的通信并非无缝，可能导致元数据更新延迟甚至丢失，这对延迟敏感的应用是不利的

简化架构设计

• Kafka 和 ZooKeeper 拥有不同的部署模型、设置和工具，增加了初次部署和后续支持的复杂性。Kafka 团队希望简化架构，减少用户的初始使用门槛

• Kafka Broker 内部需要编写和维护大量与 ZooKeeper 交互的逻辑，包括：

  • 管理 ZooKeeper 连接和会话（处理超时、重连）。
  • 设置、处理和响应 ZooKeeper 的 Watches（事件通知）。
  • 将 Kafka 的内部状态（如 Leader/ISR 信息）序列化/反序列化到 ZooKeeper 的 ZNode 结构中。

  这种交互逻辑本身就很复杂，容易出错，并且难以测试和调试。用内部的 Raft 协议和日志存储替换它，虽然 Raft 本身也复杂，但将复杂性控制在了 Kafka 内部，交互逻辑更直接。

• 移除对 ZooKeeper 的依赖，为 Kafka 未来的架构创新打开了大门。例如，可以更灵活地设计 Broker 间的交互协议，或者探索更高级别的集群管理功能，而不必考虑如何将其适配到 ZooKeeper 的模型中。KRaft 是实现更云原生、更自包含 Kafka 的关键一步。

复杂的故障场景

ZooKeeper 的故障会直接影响整个 Kafka 集群的可用性和一致性。管理两个分布式系统的故障恢复更加复杂。

Ref

1. https://blog.devgenius.io/why-kafka-ditched-zookeeper-1add2f204d11