Apache ZooKeeper 在 Apache Kafka 的发展中发挥了至关重要的作用，尤其是在其早期版本（0.9.0.0 之前）中，Kafka的很多管理控制层面的逻辑都是依赖于ZooKeeper来实现的。在本文中主要探讨ZooKeeper 在 Kafka 架构中不同版本的角色，以及 Kafka如何在不断迭代中减少对 ZooKeeper 的依赖。
Apache Kafka 中 ZooKeeper 的演变过程
ZooKeeper 在 Kafka0.9.0 之前的角色定义：
在版本 0.9.0.0 之前，Kafka 依赖 ZooKeeper 来存储和管理关键元数据，包括：
- Topic信息：分区数量、复制因子等详细信息。
- Broker 信息：Kafka Broker 的信息，包括 IP 地址和端口号。
- 消费者组信息：关于哪些消费者订阅了特定Topic的信息。
在 Kafka 0.9.0 之前的版本中向 ZooKeeper 发出元数据请求。此外，ZooKeeper 在协调控制器Broker的选举方面发挥了重要作用，该Broker负责集群管理和分区重新平衡。
0.9.0.0 之前的 Kafka 通信过程在早期的 Kafka 版本中，旧的 Kafka 协议是为 ZooKeeper 和 Kafka Broker之间的通信而设计的。它不是为生产者和消费者以及 Kafka Broker之间的直接通信而设计的。生产者和消费者通过 ZooKeeper 进行沟通如下：
- 生产者连接到 ZooKeeper，在发送消息之前发现集群中的Broker。
- 一旦生产者拥有最新的集群元数据，它就可以开始向Broker发送消息。但是，生产者仍然需要通过 ZooKeeper 来协调控制器Broker的选择，并确保所有生产者对集群状态有相同的视图。
- 消费者还连接到 ZooKeeper 以识别Broker并收集他们订阅的主题信息，然后再轮询Brokers以获取消息。
但是，这种架构的缺点在于：
- 复杂性：生产者和消费者必须多次连接 ZooKeeper 并与之交互。
- 性能：通信必须通过 ZooKeeper 进行，这可能会影响性能。
- 可扩展性：ZooKeeper 存在单点故障。
Kafka 0.9.0.0 的转变
随着 Kafka 0.9.0.0 的发布，发生了重大转变。虽然 ZooKeeper 继续管理元数据，但生产者和消费者不再需要 通过ZooKeeper地址的方式来连接Broker了，可以直接与 Kafka Broker进行连接。
这一变化是通过引入新的 Kafka 协议实现的，Kafka 协议是一种二进制协议，用于Broker、Producer和Consumer之间的直接通信。在以前的版本中，生产者和消费者需要通过 ZooKeeper 与 Kafka Broker行交互，而新的版本流程大体如下：
在 0.9.0.0 Kafka 中向 Kafka Broker元数据请求。
0.9.0.0 之后的 Kafka 通信过程
- Kafka 0.9.0.0 及以上版本引入了简化的通信流程：
- 生产者直接连接到Brokers发送消息。
- 消费者也直接连接到Broker以订阅Topic
然后，Broker将订阅Topic的消息传递给消费者。
新架构的优势
新的 Kafka 协议带来了几个好处：
1. 简单性：生产者和消费者不再需要了解 ZooKeeper。
2. 性能：Broker、Producer和Consumer之间的直接通信提高了效率。
3. 可扩展性：删除 ZooKeeper 作为单点故障增强了可扩展性。
尽管发生了这些变化，但是ZooKeeper 在 Kafka 中还是具有一定的作用，ZooKeeper 仍然是 Kafka 的重要组成部分。建议在生产环境中将 ZooKeeper 与 Kafka 一起运行，因为它提供了以下几个核心功能：
1. 容错性：ZooKeeper 具有高可用性，可以容忍节点故障。
2. 一致性：它为所有客户端提供一致的集群视图。
3. 协调：ZooKeeper 促进了分布式应用程序之间的协调，包括 Kafka。
Kafka 0.9.0.0 中 ZooKeeper 使用示例：
- 在集群中注册新Broker。
- 注册由生产者创建的新主题。
- 监听相关Topic元数据的变化。
- 处理Broker故障并触发分区重新平衡。
- 支持控制器Broker的集群状态跟踪。
Kafka Raft 元数据模式
从 Kafka 版本 2.8.0 开始，Apache Kafka 引入了 Kafka Raft 元数据模式作为 ZooKeeper 的替代方案。Kafka Raft 元数据模式消除了对单独 ZooKeeper 集群的需求，并提供了降低复杂性、提高性能和简化操作等优势。
Kafka 的内部 Raft 仲裁是一种分布式共识算法，用于存储和管理元数据。Raft 仲裁由一组Broker组成，每个Broker维护元数据的副本。
Raft 仲裁通过选举Leader Broker来运作。Leader Broker负责将元数据复制到所有其他Broker。当Leader Broker收到更改元数据的请求时，它会将更改附加到其日志中，然后将日志复制到其他Broker。一旦大多数Broker承认了更改，Leader Broker就会将更改提交到元数据中。
如果leader broker发生故障，那么standby Brokers中的一个将成为Active。然后，新的leader broker将与其他Broker同步其元数据副本。
带有 ZooKeeper 的控制器与带有 KRaft 的控制器。下表比较了在旧版 Kafka 中使用 ZooKeeper 的优缺点与在新版本中使用 Kafka Raft 元数据模式的优点：
| 功能 | ZooKeeper (旧版 Kafka) | Kafka Raft 元数据模式 (新版 Kafka) |
|---|---|---|
| 元数据存储 | 在 ZooKeeper 中独立存储 | 在 Kafka 集群中内部存储 |
| 性能 | 较慢，因为需要通过 ZooKeeper 进行通信 | 更快，直接在Broker之间通信 |
| 复杂性 | 高，生产者和消费者需要了解 ZooKeeper | 低，生产者和消费者不需要了解 ZooKeeper |
| 可扩展性 | 有限，ZooKeeper 可能成为瓶颈 | 高，可扩展到更多Broker |
| 故障恢复 | 较慢，ZooKeeper 的单点故障 | 更快，Raft 提供更快的故障转移 |
| 向后兼容性 | 适用于旧版 Kafka | 适用于 Kafka 2.8.0 及更高版本 |
| 新部署推荐 | 不推荐 | 推荐 |
| 其他功能支持 | 全面支持 | 部分功能仍在实现中 |
Kafka 集群元数据现在存储在 Kafka 集群本身中，使元数据更新操作更快、更具可扩展性。元数据也会复制到所有Broker中，从而更快地从故障中进行故障转移。与带有 Zookeeper 的 Kafka 版本相比，受控和不受控制的故障恢复时间也非常短。Kafka有提到说，在切换到 Raft 后，可扩展性有了显著的提高。例如，Kafka 基准测试表明，Raft 可以扩展到拥有多达 1,000 个Broker的集群，而使用 Zookeeper 则只有几十个。
摘自：https://developer.confluent.io
但是，需要注意的是，Kafka Raft 元数据模式并非支持所有 Kafka 特性，并且它需要集群中最低的Brokers 数量。也不建议将现有 Kafka 部署从 ZooKeeper 迁移到 Kafka Raft 元数据模式。
虽然不用于元数据管理，但 Apache Kafka 在 2.8.0 及更高版本中仍然使用 ZooKeeper 来实现向后兼容性和其他目的。
Apache Kafka 和 ZooKeeper 版本兼容性
随着 Apache Kafka 3.5 的发布，Zookeeper 现在被标记为已弃用。计划在 Apache Kafka 的下一个主要版本（版本 4.0）中删除 ZooKeeper，在弃用阶段，Kafka 集群的元数据管理仍支持 ZooKeeper，但不建议用于新部署。在 KRaft 中仍有一小部分功能有待实现，以下为社区关于4.0版本的概述：
Kafka 4.0 将引入一个重大的架构增强：完全删除 ZooKeeper 依赖项。Kafka 4.0 将专门使用 KRaft（Kafka Raft 元数据模式）进行集群元数据管理，停止使用 ZooKeeper。这一重大变化不仅通过全面采用 KRaft 简化了 Kafka 的架构，而且增强了 Kafka 集群的可扩展性和可维护性。
主要优化点：
- 简化集群管理，无需依赖 zookeeper
- 增强的可靠性和容错能力
- 通过简化的架构提高运营效率
综上所述，Kafka 的架构从严重依赖 ZooKeeper 演变到 Kafka Raft 元数据模式的引入，代表了向前迈出的重要一步。它简化了 Kafka 部署，增强了性能并简化了操作，使 Kafka 在各种用例中更加通用。
详细可以参考：
https://cwiki.apache.org/confluence/display/KAFKA/KIP-833%3A+Mark+KRaft+as+Production+Ready
本文仅供学习！所有权归属原作者。侵删！文章来源： 云原生大数据技术荟 -丁点大数据 :http://mp.weixin.qq.com/s/VT7cAxyo4UYPn14oauLB-w
