Apache Kafka 2.8不再需要ZooKeeper就能运作

分散式发布与订阅系统Apache Kafka在即将发布的2.8版本，使用Kafka内部的仲裁（Quorum）控制器来取代ZooKeeper，因此用户第一次可在完全不需要ZooKeeper的情况下执行Kafka，这不只节省运算资源，并且也使得Kafka效能更好，还可支援规模更大的丛集。

过去Apache ZooKeeper是Kafka这类分散式系统的关键，因为ZooKeeper管理元资料，储存着资料分割的位置，以及主要副本等资讯，ZooKeeper扮演协调代理的角色，所有代理服务器启动时，都会连接到Zookeeper进行注册，当代理状态发生变化时，Zookeeper也会储存这些资料，在过去，ZooKeeper是一个强大的工具，但是毕竟ZooKeeper是一个独立的软件，使得Kafka整个系统变得复杂，因此官方决定使用内部仲裁控制器来取代ZooKeeper。

这项工作从去年4月开始，而现在这项工作取得部分成果，用户将可以在2.8版本，在没有ZooKeeper的情况下执行Kafka，官方称这项功能为Kafka Raft元资料模式（KRaft）。在KRaft模式，过去由Kafka控制器和ZooKeeper所操作的元资料，将合并到这个新的Quorum控制器，并且在Kafka丛集内部执行，当然，如果使用者有特殊使用情境，Quorum控制器也可以在专用的硬件上执行。

在Kafka内部执行的Quorum控制器，会使用新的KRaft协定来确保仲裁间能精确地复制元资料副本，并使用事件来源储存模型来储存状态，以确保内部状态机可以精确地被重新创建，官方提到，KRaft协定具有的事件驱动特性，和基于ZooKeeper控制器不同，不会在启动之前从ZooKeeper载入装态，当领导节点变更的时候，新启用的控制器内存早已纪录所有提交的元资料。

另外，KRaft协定使用事件驱动机制来追踪整个丛集的元资料，过去必须仰赖RPC来处理的任务，现在受益于事件驱动以及实际的日志传输，这些改变所带来的好处，便是让Kafka仍够支援更多的分割。

新的仲裁控制器是专门设计在单个丛集中，处理大量的分割，在过去的实作中，受限于重要的元资料，必须要在外部共识机制ZooKeeper，以及内部领导控制器Kafka间移动，Kafka仅能达到20万个分割，而在新的仲裁控制器中，过去外部共识与领导管理的角色，都由同一个元件扮演，因此现在于单个丛集中，分割数可以达到过去10倍，约是2百万个分割。

过去Kafka因为带着ZooKeeper，因此被认为拥有沉重的基础设施，而在移除ZooKeeper之后，Kafka更轻巧更适用于小规模工作负载，轻量级单体程式适合用于边缘以及轻量级硬件解决方案。

值得注意的是，在抢先体验版中，有部分像是ACL、安全以及交易等功能都尚未支援，而且在KRaft模式下，也还不支援重新分配分割和JBOD，官方提到，这些功能会在今年稍晚的版本中提供，而且因为仲裁控制器还在实验阶段，也不建议将其用于生产环境中。