集群中有多少个Kafka控制器,控制器的用途是什么？

Question

Kafka集群中的Kafka控制器负责管理分区负责人和复制.

如果Kafka集群中有100个经纪人,那么控制器只是一个Kafka经纪人吗？那么在100个经纪人中,控制者是领导者吗？

你怎么知道哪个经纪人是控制人？

Kafka控制器的管理对Kafka系统管理至关重要吗？

Answer 1

在Kafka集群中,单个代理充当活动控制器,负责分区和副本的状态管理.因此,在您的情况下,如果您有一个包含100个代理的集群,其中一个将充当控制器.

有关集群控制器职责的更多详细信息,请参见此处.

为了找到哪个代理是集群的控制器,首先需要通过ZK CLI连接到Zookeeper:

./bin/zkCli.sh -server localhost:2181 

然后get是控制器

[zk: localhost:2181(CONNECTED) 0] get /controller

输出应如下所示:

{"version":1,"brokerid":100,"timestamp":"1506423376977"}
cZxid = 0x191
ctime = Tue Sep 26 12:56:16 CEST 2017
mZxid = 0x191
mtime = Tue Sep 26 12:56:16 CEST 2017
pZxid = 0x191
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x15ebdd241840002
dataLength = 56
numChildren = 0

此外,您可以通过删除当前控制器来丢弃控制器并强制控制器选择

[zk: localhost:2181(CONNECTED) 2] delete /controller

它应该给出类似于下面的输出:

DEBUG [Controller id=100] Resigning (kafka.controller.KafkaController)
DEBUG [Controller id=100] De-registering IsrChangeNotificationListener (kafka.controller.KafkaController)
DEBUG [Controller id=100] De-registering logDirEventNotificationListener (kafka.controller.KafkaController)
INFO [Controller id=100] Resigned (kafka.controller.KafkaController)
DEBUG [Controller id=100] Broker 200 has been elected as the controller, so stopping the election process. (kafka.controller.KafkaController)

Zookeeper是Kafka集群状态的存储.它在最开始或当前控制器崩溃时用于控制器选举.当主题的分区前导代理失败/崩溃时,控制器还负责告知其他副本成为分区领导者.

Answer 2

该控制器是Kafka代理之一，它还负责选举分区领导者（除了通常的代理功能）。

控权人只是一名经纪人吗？

一次只有1个控制器。

在内部，每个代理都尝试在Zookeeper（/控制器）中创建一个临时节点。第一个成功，成为控制器。其他节点仅获得适当的异常（“节点已存在”），并监视控制器节点。当控制器死亡时，临时节点将被删除，并通知监视代理。再次，其中第一个成功注册临时节点的节点成为新的控制器，其他节点将再次获得“节点已存在”异常并继续等待。

您怎么知道谁是Kafka的控制者？

当选出新的控制器时，动物园管理员会获得一个“控制器时代”编号。代理知道当前的控制器纪元，并且如果他们从编号较旧的控制器收到消息，则他们会忽略它。

控制器是领导者吗？

不是。每个分区都有自己的领导者。当代理死亡时，控制器将遍历需要新领导者的所有分区，确定该新领导者应为谁（仅仅是同步副本列表中的随机副本，也就是该分区的ISR），然后向所有包含这些分区的新领导者或现有关注者的中间人。

现在，新领导者知道他们需要开始满足来自客户的生产者和消费者的请求，而关注者现在知道他们需要开始从新领导者进行复制。

Answer 3

Kafka 控制器是 Kafka 集群的大脑。它监控经纪人的活跃度并对经纪人失败采取行动。

集群中将只有一个 Kafka 控制器。控制器是集群中的 Kafka 代理之一，除了通常的代理功能外，还负责在现有代理离开集群或代理加入集群时选举分区领导。

通过在 Zookeeper 中创建一个名为“/controller”的临时节点，集群中启动的第一个代理将成为 Kafka 控制器。当其他broker启动时，他们也尝试在Zookeeper中创建这个节点，但是会收到一个“节点已经存在”的异常，通过这个异常他们知道集群中已经有一个Controller被选举出来了。

当 Zookeeper 没有收到来自 Controller 的心跳消息时，Zookeeper 中的临时节点将被删除。然后它通过 Zookeeper 观察器通知集群中的所有其他代理控制器已经消失，这再次开始新控制器的新选举。所有其他经纪人将再次尝试创建一个临时节点“/controller”，第一个成功的将被选为新的 Controller。

集群中可能有多个控制器。考虑在当前 Kafka 控制器（“Controller_1”）上发生长时间 GC（垃圾收集）的情况，由于 Zookeeper 在配置的时间内没有收到来自控制器的心跳消息。这会导致“/controller”节点从 Zookeeper 中删除，并且集群中的另一个代理被选为新的控制器（“Controller_2”）。

在这种情况下，集群中有 2 个控制器“Controller_1”和“Controller_2”。“Controller_1”GC 已完成，它可能会尝试在 Zookeeper 中写入/更新状态。“Controller_2”还会尝试在 Zookeeper 中写入/更新状态，这可能导致 Kafka 集群与来自旧控制器和新控制器的写入不一致。

为了避免这种情况，每次进行 Controller 选举时都会生成一个新的“纪元”。每次选举控制器时，它都会通过 Zookeeper 条件增量操作接收一个新的更高 epoch。

这样，当旧控制器（“Controller_1”）尝试更新某些内容时，Zookeeper 会将当前纪元与旧控制器在其写入/更新请求中发送的旧纪元进行比较，并且它会简单地忽略它。集群中的所有其他代理也知道当前的控制器纪元，如果他们收到来自旧纪元的旧控制器的消息，他们也会忽略它。