Kafka 3.3 使用 KRaft 共识协议替代 ZooKeeper

Apache 软件基金会发布了包含许多新特性和改进的 Kafka 3.3.1。这是第一个标志着可以在生产环境中使用KRaft（Kafka Raft）共识协议的版本。在几年的开发过程中，它先是在 Kafka 2.8 早期访问版本中发布，然后又在 Kafka 3.0 预览版本中发布。

KRaft 是一种共识协议，可以直接在 Kafka 中管理元数据。元数据的管理被整合到了Kafka当中，而不需要使用像ZooKeeper这样的第三方工具，这大大简化了 Kafka 的架构。这种新的 KRaft 模式提高了分区的可伸缩性和弹性，同时简化了 Kafka 的部署，现在可以不依赖 ZooKeeper 单独部署 Kafka 了。

KRaft 使用了Raft共识算法的一种基于事件的变体，因此得名。

随 KRaft 引入的新的仲裁控制器确保元数据在整个仲裁中可以被准确复制。活动控制器将元数据存储在事件源日志主题中，仲裁中的其他控制器对活动控制器创建的事件做出响应。事件日志定期进行快照，确保日志不会无限增长。与基于 ZooKeeper 的控制器不同，如果出现了问题，仲裁控制器不需要从 ZooKeeper 加载状态，因为集群的内部状态已经分布在元数据主题中。这大大减少了不可用时间窗口，缩短了系统最坏情况恢复时间。

下图显示了使用新的仲裁控制器比使用 ZooKeeper 更快地关闭具有 200 万个分区的 Kafka 集群。

新的 KRaft 共识算法和仲裁控制器使得 Kafka 集群可以扩展到数百万个分区，不仅提升了稳定性，让 Kafka 变得更容易监控、管理和支持，而且让整个系统可以有一个单一的安全模型，使控制器故障转移接近瞬时。

Kafka 社区计划在下一个版本（3.4）中弃用 ZooKeeper，然后在 4.0 版本中完全删除它。

KRaft 模式的优势

• 去除外部依赖：传统的 Kafka 集群依赖于 ZooKeeper 来存储集群元数据和进行领导选举等，引入 KRaft 后，Kafka 将自行管理这些功能，从而去除了对 ZooKeeper 的依赖。

• 简化架构：不再需要运维一个单独的 ZooKeeper 集群，简化了 Kafka 的部署和管理。

• 提高性能：直接在 Kafka 中实现共识机制，可以优化元数据操作的性能，减少延迟。

• 改善可扩展性：KRaft 模式下，Kafka 能够更好地支持大规模集群，提高元数据操作的效率。

迁移到 KRaft

迁移到 KRaft 需要谨慎规划，尤其是对于已经在生产中运行的 Kafka 集群。Apache Kafka 提供了一套迁移工具和步骤，但是整个过程需要谨慎处理，以避免数据丢失或服务中断。当前，对于新的 Kafka 集群，推荐直接采用 KRaft 模式部署。

注意事项

• 版本兼容性：在考虑迁移至 KRaft 模式之前，需要确保你的 Kafka 客户端和周边工具与 Kafka 3.3 或更高版本兼容。

• 迁移测试：在生产环境迁移之前，在测试环境中彻底测试迁移过程，确保数据一致性和应用兼容性。

• 监控和回滚计划：在迁移过程中，应加强监控，及时发现可能的问题，并准备好回滚计划。

- END -