apache-kafka - 为什么 Kafka 集群已经使用 Zookeeper，还需要 Controller？

Question

Kafka 集群有一个控制器节点和一个 Zookeeper 集群，它们都有自己的一套职责。当我们已经拥有 zookeeper 时，控制器的要求是什么？ 例如：控制器选举由zookeeper执行，分区领导者选举由控制器完成。当 Kafka 已经知道哪些分区在哪些节点上以及哪些节点实际处于活动状态时，为什么不使用 Zookeeper 进行分区领导者选举。

简而言之，尽管动物园管理员在场，但我仍在努力理解控制器的要求。如果有人能解释这种设计选择的原因和优势，那将非常有帮助。

标签： apache-kafka

Answer 1

kafka 使用 zookeeper 做一些事情：

1. 集群成员 - 集群的实时代理是那些拥有临时 ZK 节点的代理
2. 领导者选举 - 选举作为控制器的 kafka 经纪人
3. 状态存储 - 一些（主要是较旧的）状态存储在 ZK 中 - 例如主题的配置。曾经在 ZK 中的一些状态已迁移到特殊主题（消费者偏移量），并且编写了一些更新的功能以将状态完全存储在 kafka 中（例如事务日志）。

总的趋势是停止在 ZK 中使用状态，而是自行托管它（尽管代码的旧部分从未被迁移出来）。

至于为什么不使用 ZK 进行分区领导者选举 - 一个原因是涉及逻辑。在选举集群领导代理时，没有偏好 - 任何代理都可以。这与基于 ZK 的领导人选举的工作方式非常吻合（第一个创建和拥有临时 znode 的成员获胜）。

但是，在选择分区领导者时，您需要更多的逻辑。例如 - 您想选择具有“最高水印”的领导者（具有最新数据，记住复制通常是异步的）。不干净的领导人选举也有逻辑。仅 ZK 无法做到这一点，因此它由控制器完成。