事件溯源概念深入人心:Kafka将抛弃ZooKeeper,替换为自我管理的元数据仲裁

19-08-05 banq
                   

这是Kafka的KIP-500提案,目前,Kafka使用ZooKeeper存储有关分区和代理的元数据,并选择其作为Kafka控制器的代理。我们想要删除对ZooKeeper的这种依赖。这将使我们能够以更具可扩展性和可靠性的方式管理元数据,从而支持更多分区。它还将简化Kafka的部署和配置。

将状态作为一系列事件进行管理由很多好处。在Kafka中,偏移量指针指示数据流中的位置。多个消费者只需重播比当前偏移量更新的所有事件即可,这样可以获得最新状态。日志已经在事件之间建立明确的顺序,并确保消费者始终沿着单个时间线移动。

然而,尽管我们的用户享受这些好处,但卡夫卡本身也被排除在外。我们将元数据的更改视为孤立的更改,彼此之间没有任何关系。当控制器将状态更改通知(例如LeaderAndIsrRequest)推送到集群中的其他节点时,节点可能会获得一些更改,但不是全部。虽然控制器重试几次,但它最终会放弃。这可能使集群中各个节点处于不同的状态。

更糟糕的是,尽管ZooKeeper是记录存储,但ZooKeeper中的状态通常与控制器内存中保存的状态不匹配。例如,当分区负责人在ZK中更改其ISR时,控制器通常在好几秒内还不了解这些更改。控制器没有通用的方法来遵循ZooKeeper事件日志。

元数据应该存储在Kafka本身,而不是存储在单独的系统中。这将避免与控制器状态和Zookeeper状态之间的差异相关的所有问题。节点之间应该只从事件日志中消费元数据事件,而不是向其他节点推送通知。这可确保元数据更改始终以相同的顺序到达。节点将能够在文件中本地存储元数据。当他们启动时,他们只需要读取控制器发生的变化,而不是完整状态。这将让我们以更少的CPU消耗支持更多分区。

评论:Zebee已经根据EventSourcing实现了全新的消息代理:如何使用Zebee构建高度可扩展的分布式工作流中间件?

 

                   

2