为什么卡夫卡集群需要一个控制器，而它已经使用了动物园管理员？

Question

一个Kafka集群有一个控制器节点和一个动物园管理员集群，它们都有自己的职责集。当我们已经拥有动物园管理员时，控制器的要求是什么?例如:控制器选择由动物园管理员执行，分区领导人选举由控制器完成。为什么Kafka在已经掌握了哪些分区位于哪些节点上以及哪些节点实际处于活动状态的信息时，也不使用进行分区领袖选举。

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

Answer 1

卡夫卡用动物园管理员做了几件事：

controller

• state

1. 集群成员--集群的动态代理是那些拥有短暂的ZK节点
2. 领导人选举的人--作为一个
3. 存储的卡夫卡代理的选举--例如，一些(主要是旧的)状态存储在ZK中--主题的配置。过去在ZK中的一些状态已经迁移到特殊主题(消费者抵消)，一些更新的功能被完全用kafka存储状态(例如，事务日志)。

总的趋势是停止使用ZK中的状态，而改用自宿主状态(尽管代码的旧部分从未被迁移出去)。

至于为什么不使用ZK进行分区领导人选举，原因之一是涉及到逻辑。在选举集群领袖经纪人时，没有任何偏好--任何经纪人都可以。这很符合ZK领导选举的运作方式(创建和拥有一个短暂的znode获胜的第一个备忘录)。

然而，在选择分区领导时，您需要更多的逻辑。例如，您希望选择具有“最高水印”的领导者(使用最新的数据，记住复制通常是异步的)。不洁的领袖选举也有其逻辑。单靠ZK无法做到这一点，因此它是由控制器完成的。

Answer 2

动物园管理员的工作是协调服务，卡夫卡也是为了同样的目的而使用动物园管理员。

动物园管理员是卡夫卡设计的。因为动物园管理员有责任管理卡夫卡集群。它有所有卡夫卡经纪人的名单与它和控制器的集群是由动物园管理员选择并存储在那里。

卡夫卡在动物园管理员上存储最低限度的信息。

https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum

Answer 3

为了保护动物园管理员。如果没有控制器，动物园管理员需要触发太多的侦听器(等于代理计数)，而这些侦听器大多是无用的，这对动物园管理员来说是一个潜在的风险，通过控制器只与动物园管理员交互。