Kafka自维护计划：将不再依赖ZooKeeper

Apache Kafka是高吞吐的分布式式消息发布订阅系统。现在Kafka使用Apache ZooKeeper存储其元数据和集群维护。Kafka分区位置和主题配置之类的元数据都存储在ZooKeeper群集中。去年Kafka社区提出了一项提议KIP-500用以去掉该依赖，使用Kafaka本身来管理元数据的自维护计划，我们本文就来介绍KIP-500改进。

概述

Kafka是由Apache软件基金会下一个开源的高吞吐量的分布式发布订阅消息系统，由Scala和Java编写。常用于对网站日志中进行流数据。由于其高效的数据处理能力，Kafka是现代大数据处理的基础组件之一。

目前的问题

在Kafka的设计中，使用了Zookeeper来进行所有Broker的管理，每个Broker服务器启动时都会到连接到Zookeeper注册，创建/brokers/ids/[0-N]节点，写入IP，端口等信息。当Broker发生状态变化，比如下线，对应Broker节点也就被删除。因此zookeeper上Broker节点的变化就可以用来表示Broker服务器的可用性,Kafka的Topic管理也通过类似这种方式管理。

这样一来，每一个Kafka集群中，都必须部署两套系统，会导致很多重复。两套系统都有其自己的网络通信，安全性，监视和配置方式。这样使安装部署和运维操作的结果总复杂度也会翻倍。不仅会导致陡峭学习曲线，也增加了某些配置错误导的风险。

其次，在外部存储元数据不是很有效。在现有集群中至少要运行三个附加的Java进程，有时还要运行更多。经常能看到Kafka集群的ZooKeeper节点与Kafka节点一样多。而且ZooKeeper中的数据也需要反映在Kafka控制器上，会导致双重缓存。

再次，外部存储元数据限制了Kafka的可伸缩性。当Kafka集群启动或选择新的控制器时，控制器必须从ZooKeeper加载集群的完整状态。随着元数据量的增加，该加载过程的时间也随之增加。这限制了Kafka可以存储的分区数量。

最后，将元数据存储在外部会增加控制器的内存状态与外部状态不同步的可能性。控制器的活动视图也可以与ZooKeeper的视图不统一。

KIP-500

KIP-500议案提出了在Kafka中处理元数据的更好方法。基本思想是"Kafka on Kafka"，将Kafka的元数据存储在Kafka本身中，无需增加额外的外部存储比如ZooKeeper等。

在KIP-500议案中，元数据将存储在Kafka分区中，而不是存储在ZooKeeper中。控制器将是该分区的所有者。Kafka本身就不会配置和管理外部元数据系统。

元数据将被视为日志。需要最新更新的Brokers只能读取日志的末尾。类似于需要最新日志条目的使用者仅需要读取日志的最后而不是整个日志的方式。Brokers还将能够在整个流程重启期间保留其元数据缓存。

控制器架构

Kafka集群选择一个控制器节点来管理分区领导者和集群元数据。拥有的分区和元数据越多，控制器的可伸缩性就越重要。期望将需要时间与主题或分区的数量成线性比例的操作的数量减至最少。

一种这样的操作是控制器故障转移。当前，当Kafka选择新控制器时，它需要在继续之前加载整个集群状态。随着群集元数据数量的增加，此过程将花费越来越长的时间。

相比之下，在后KIP-500中，只要活动控制器消失，就会有几个备用控制器准备接管。这些备用控制器只是元数据分区的Raft仲裁中的其他节点。这种设计确保了当选择一个新的控制器时，永远不需要经过漫长的加载过程。

KIP-500将加快主题的创建和删除。现在创建或删除主题时，控制器必须从ZooKeeper重新加载集群中所有主题名称的完整列表。这是必须的，因为当集群中的主题集发生更改时，当ZooKeeper通知我们时，它并不能告诉我们确切地添加或删除了哪些主题。相反，在KIP-500中创建或删除主题将仅涉及在元数据分区中创建新条目，这是个O(1)操作。

元数据可伸缩性是将来扩展Kafka的关键部分。期望用单个Kafka集群最终将能够支持一百万个分区或更多。

路线图

从Kafka的管理工具中删除ZooKeeper

作为Kafka版本的一部分提供的一些管理工具仍然可以和ZooKeeper直接通信。除了这种直接的ZooKeeper通信之外，仍然无法完成一两个操作。

很快，对于以前需要直接ZooKeeper访问的每个操作，将都有一个公共的Kafka API。在下一个主要版本的Kafka中将禁用或删除不必要的--zookeeper的标志。

自我管理的元数据仲裁

在KIP-500中，Kafka控制器会将其元数据存储在Kafka分区中，而不是存储在ZooKeeper中。但是，由于控制器依赖于该分区，因此分区本身不能依赖控制器来进行领导者选举之类的事情。而是，管理该分区的节点必须实现自我管理的Raft仲裁

KIP-595：用于元数据仲裁的Raft议案提出了如何将Raft协议调整为适合Kafka的方式，以使其真正感觉像系统的本机部分。这将涉及将Raft中描述的基于推的模型更改为基于拉的模型，这与传统的Kafka复制是一致的。如其将数据推送到其他节点，其他节点将连接到它们。同样，将使用与Kafka一致的术语。

最初的实现将集中在支持元数据分区上。它不支持将常规分区转换为Raft所需的全部操作。

KIP-500模式

当然，该项目最激动人心的部分是在 KIP-500模式下无需ZooKeeper即可运行集群的能力。当Kafka用该模式运行时，将使用Raft仲裁存储元数据，而不是ZooKeeper。

最初，KIP-500模式将是实验性的。大多数用户将继续使用"传统模式"，而ZooKeeper仍在使用中。部分原因是因为KIP-500模式最初并不支持所有可能的功能。另一个原因是希望在将其设置为默认值之前对KIP-500模式充满信心。最后，将需要时间完善从传统模式到KIP-500模式的升级过程。

启用KIP-500模式的许多工作将在控制器中进行。必须将与ZooKeeper交互的控制器部分与实现更多通用逻辑（例如副本集管理）的部分分开。

需要定义和实现更多的控制器API，以替换当前涉及ZooKeeper的通信机制。新AlterIsrAPI 就是一个例子。该API允许副本在不使用ZooKeeper的情况下将同步副本集中的更改通知控制器。

升级版

KIP-500引入了Bridge发行版的概念，该发行版可与KIP-500之前和之后的Kafka版本共存。Bridge版本非常重要，因为它们可以实现对ZooKeeper的零停机升级。使用旧版Kafka的用户只需升级到网桥版本即可。然后，他们可以对缺少ZooKeeper的版本进行第二次升级。顾名思义，桥接发行充当了通往新架构的桥梁。考虑一个处于部分升级状态的群集，其中桥发行版上包含多个代理，而KIP-500后发行版上包含多个代理。控制器将始终是KIP-500之后的Brokers。在该群集中，Brokers不能依赖直接修改ZooKeeper来宣布他们正在进行的更改（例如配置更改或ACL更改）。KIP-500之后的Brokers不会收到此类通知，因为他们没有在ZooKeeper上进行监听。通过将其更改镜像到ZooKeeper，仅控制器仍在与ZooKeeper交互。因此，在Bridge版本中，除控制器外的所有代理都必须将ZooKeeper视为只读。

用有据可查和受支持的RPC替换临时的ZooKeeper API具有许多与删除客户端ZooKeeper访问相同的好处。保持跨版本兼容性将更加容易。对于的特殊情况AlterIsrRequest，减少普通操作所需的对ZooKeeper的写入次数也将带来好处。

结论

Kafka是最活跃的Apache项目之一。看到过去几年中其架构的发展令人惊奇。正如KIP-500之类的项目所示，这种架构尚未完成。KIP-500最吸引人的地方在于，它简化了整个体系结构，无论是对于管理员还是开发人员而言。这将使我们能使用事件日志的强大抽象来处理元数据。