Apache Kafka使用Apache ZooKeeper存储其元数据，ZooKeeper有什么问题呢？实际上，问题不在于ZooKeeper本身，而在于外部元数据管理的概念。
有两个系统会导致很多重复。毕竟，Kafka是复制的分布式日志，其顶部是pub / sub API。ZooKeeper是一个复制的分布式日志，顶部是文件系统API。每个都有其自己的网络通信，安全性，监视和配置方式。使用两个系统会使维护人员的结果总复杂度大约翻倍。这导致不必要的陡峭学习曲线，并增加了某些配置错误导致安全漏洞的风险。
在外部存储元数据不是很有效。我们至少运行三个附加的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本身就不会配置和管理外部元数据系统。
我们将元数据视为日志。需要最新更新的代理只能读取日志的末尾。这类似于需要最新日志条目的使用者仅需要读取日志的最后而不是整个日志的方式。经纪人还将能够在整个流程重启期间保留其元数据缓存。