KRaft：没有 ZooKeeper 的 Apache Kafka
翻译原文地址：developer.confluent.io/learn/kraft…
Apache Kafka Raft (KRaft) 是 KIP-500 中引入的共识协议，旨在消除 Apache Kafka 对 ZooKeeper 进行元数据管理的依赖。这极大地简化了 Kafka 的架构，将元数据的责任整合到 Kafka 本身，而不是将其拆分到ZooKeeper 和 Kafka。 KRaft 模式利用了 Kafka 中新的仲裁控制器服务，该服务取代了之前的控制器，并利用了 Raft 共识协议的基于事件的变体。
Kafka 新的仲裁控制器的优点
- KRaft 支持适当大小的集群，这意味着集群的大小具有适当数量的代理和计算，以满足用例的吞吐量和延迟要求，并且有可能扩展到数百万个分区
- 提高稳定性，简化程序，同时更好的监控、管理和支持 Kafka
- 允许 Kafka 为整个系统提供单一的安全模型
- 配置、网络设置和通信协议的统一管理模型
- 提供轻量级、单进程的方式来开始使用 Kafka
- 使控制器故障转移近乎瞬间完成
运行原理
仲裁控制器使用新的 KRaft 协议来确保元数据在仲裁中准确复制。仲裁控制器使用事件源存储模型来存储其状态，这确保了内部状态机始终可以准确地重新创建。用于存储此状态的事件日志（也称为元数据主题）会通过快照定期删减，以保证日志不会无限期增长。仲裁中的其他控制器通过响应活动控制器创建并存储在其日志中的事件来跟随活动控制器。因此，如果一个节点由于分区事件而暂停，例如，它可以在重新加入时通过访问日志来快速赶上它错过的任何事件。这显着减少了不可用窗口，缩短了系统在最坏情况下的恢复时间。
KRaft 协议的事件驱动性质意味着，与基于 ZooKeeper 的控制器不同，仲裁控制器在激活之前不需要从 ZooKeeper 加载状态。当领导权发生变化时，新的活动控制器已经在内存中拥有所有提交的元数据记录。此外，KRaft 协议中使用的相同事件驱动机制用于跟踪整个集群的元数据。以前使用 RPC 处理的任务现在受益于事件驱动以及使用实际日志进行通信。
尝试一下
自 Apache Kafka 3.3 起，KRaft 模式已为新集群做好生产准备。 KIP-833 中跟踪了其他功能（例如从 ZooKeeper 迁移）的开发进度。
如果您想亲自尝试，请按照 Kafka Local Quickstart (或者参考我之前整理的文章：juejin.cn/post/733010… ) 进行操作。此快速入门以 KRaft 组合模式运行，这意味着一个进程既充当代理又充当控制器。组合模式只适合本地开发和测试。请参阅此处的文档，了解有关在隔离模式下配置 KRaft 进行生产的详细信息，这意味着控制器独立于代理运行。
现在，您可以将工具从从 ZooKeeper 获取元数据改为从代理获取元数据，如为 KIP-500 准备客户端和工具：从 Apache Kafka 中删除 ZooKeeper 中所述。
操作对比
| ZOOKEEPER | KRAFT | |
|---|---|---|
| 配置客户端和服务 | zookeeper.connect=zookeeper:2181 | bootstrap.servers=broker:9092 |
| 配置架构注册表 | kafkastore.connection.url=zookeeper:2181 | kafkastore.bootstrap.servers=broker:9092 |
| 管理工具 | kafka-topics --zookeeper zookeeper:2181 | kafka-topics --bootstrap-server broker:9092 ... --command-config properties to connect to brokers |
| REST Proxy API | v1 | v2 或 v3 |
| 获取Kafka集群ID | zookeeper-shell zookeeper:2181 get/cluster/id | kafka-metadata-quorum 或查看metadata.properties 或 confluent cluster describe --url http://broker:8090 --output json |
