KRaft 协议的事件驱动特性意味着，与基于 ZooKeeper 的控制器不同，仲裁控制器在成为活动状态之前不需要从 ZooKeeper 加载状态。当领导权发生变化时，新的活动控制器已经在内存中拥有所有提交的元数据记录。此外，KRaft 协议中使用的事件驱动机制也用于跨集群跟踪元数据。以前使用 RPC 处理的任务现在得益于事件驱动以及使用实际日志进行通信。这些改变带来的一个令人愉快的结果是，Kafka 现在可以比以前支持更多的分区，下面小结将介绍这个。
Kafka 集群可以支持的分区数由两个属性决定：每个节点的分区数限制和集群级别的分区限制。两者都很有趣，但是到目前为止，元数据管理一直是集群级别限制的主要瓶颈。以前的 Kafka 改进建议（KIP）已经改进了每个节点的限制，尽管总有更多的事情可以做。但是 Kafka 的可伸缩性主要依赖于增加节点来获得更多的容量。这就是集群级别限制变得重要的原因，因为它定义了系统内可伸缩性的上限。
新的仲裁控制器旨在处理每个集群中更多的分区。为了对此进行评估，社区进行了专门的测试，这些测试测量关闭和恢复 Controller 所花费的时间。下面是社区在运行200万个分区的集群进行的。
可以看出，基于 ZooKeeper 的 Controller 在关闭和恢复时都花费了很多时间，而基于 Quorum 的 Controller 则表现良好。原因是，基于 ZooKeeper 的 Controller 需要 Kafka 和 ZooKeeper 进行数据同步，这个直接消耗了大量的时间，也正是这个导致了 基于 ZooKeeper 的 Controller 不可能支持太多的分区。而基于 Quorum 的 Controller 数据是由同一个组件提供，所以数据同步时间会小很多。
新的仲裁控制器在 trunk 中以实验模式提供，预计将包含在即将发布的 Apache Kafka 2.8 版本中。那么我们能用它做什么呢？如上所述，一个简单但非常酷的新特性是创建单个进程 Kafka 集群的能力，如下面的简短演示所示。
当然，如果要扩展以支持更高的吞吐量并添加复制以实现容错功能，则只需添加新的 broker 进程。 最后，需要注意的是，这是基于 KRaft 的仲裁控制器的早期实验版本，请不要将其用于重要的工作负载中。
本文参考自：Apache Kafka Made Simple: A First Glimpse of a Kafka Without ZooKeeper
本博客文章除特别声明，全部都是原创！
