这是Kafka的KIP-500提案，目前，Kafka使用ZooKeeper存储有关分区和代理的元数据，并选择其作为Kafka控制器的代理。我们想要删除对ZooKeeper的这种依赖。这将使我们能够以更具可扩展性和可靠性的方式管理元数据，从而支持更多分区。它还将简化Kafka的部署和配置。
将状态作为一系列事件进行管理由很多好处。在Kafka中，偏移量指针指示数据流中的位置。多个消费者只需重播比当前偏移量更新的所有事件即可，这样可以获得最新状态。日志已经在事件之间建立明确的顺序，并确保消费者始终沿着单个时间线移动。
然而，尽管我们的用户享受这些好处，但卡夫卡本身也被排除在外。我们将元数据的更改视为孤立的更改，彼此之间没有任何关系。当控制器将状态更改通知（例如LeaderAndIsrRequest）推送到集群中的其他节点时，节点可能会获得一些更改，但不是全部。虽然控制器重试几次，但它最终会放弃。这可能使集群中各个节点处于不同的状态。
更糟糕的是，尽管ZooKeeper是记录存储，但ZooKeeper中的状态通常与控制器内存中保存的状态不匹配。例如，当分区负责人在ZK中更改其ISR时，控制器通常在好几秒内还不了解这些更改。控制器没有通用的方法来遵循ZooKeeper事件日志。
元数据应该存储在Kafka本身，而不是存储在单独的系统中。这将避免与控制器状态和Zookeeper状态之间的差异相关的所有问题。节点之间应该只从事件日志中消费元数据事件，而不是向其他节点推送通知。这可确保元数据更改始终以相同的顺序到达。节点将能够在文件中本地存储元数据。当他们启动时，他们只需要读取控制器发生的变化，而不是完整状态。这将让我们以更少的CPU消耗支持更多分区。
评论：Zebee已经根据EventSourcing实现了全新的消息代理：如何使用Zebee构建高度可扩展的分布式工作流中间件？