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,官方提到,这些功能会在今年稍晚的版本中提供,而且因为仲裁控制器还在实验阶段,也不建议将其用于生产环境中。