当Kafka集群已经使用Zookeeper时，为什么需要一个Controller？

Question

Kafka集群具有一个控制器节点和一个Zookeeper集群，它们都有各自的职责集。 已经有动物园管理员的控制器对控制器有什么要求？ 例如：控制器选举由动物园管理员执行，分区负责人选举由控制器执行。 当卡夫卡已经掌握了有关哪些分区位于哪些节点上以及哪些节点实际上处于活动状态的信息时，为什么卡夫卡也不将Zookeeper用作分区领导者选举。

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

Answer 1

kafka使用Zookeeper做一些事情：

1. 集群成员身份-集群的实时代理是具有临时ZK节点的成员
2. 领导人选举-选举担任控制人的kafka经纪人
3. 状态存储-例如，某些（大多数是较旧的）状态存储在ZK中-主题的配置。以前在ZK中的某些状态已迁移到特殊主题（用户偏移量），并且编写了一些较新的功能以将状态完全存储在kafka中（例如，事务日志）。

总体趋势是停止在ZK中使用状态，而是对其进行自我托管（尽管代码的较早部分从未迁移出）。

为什么不使用ZK进行分区领导者选举-原因之一是涉及逻辑。当选择集群领导者经纪人时，没有任何偏好-任何经纪人都会这样做。这非常适合基于ZK的领导者选举的工作方式（第一个创建并拥有临时znode的成员将获胜）。

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

Answer 2

Zookeeper充当协调服务，而Kafka出于同一目的使用Zookeeper。

Zookeeper必须是Kafka设计的。因为Zookeeper负责管理Kafka集群。它具有所有Kafka代理的列表，并且Zookeeper选择并存储了该集群的控制器。

Kafka在Zookeeper上存储最少的信息。

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

Answer 3

为了保护zookeeper。没有控制器，zookeeper需要触发太多的监听器（等于broker数），而这些监听器大部分都没用，这对zookeeper来说是一个潜在的风险，通过控制器只有控制器与zookeeper交互