KafKa - 控制器作用 及 选举策略

一、KafKa控制器作用

在 kafka 中分为 broker 和 partition 分区，其中分区副本在前几篇文章中都进行了讲解，本篇文章针对 broker 进行分析，其中在 kafka 集群中，一个broker一般就表示一台物理机器，那机器之间的协作是怎样的呢？

其实会有一个broker选举成为Kafka Controller 控制器 角色，它主要负责维护集群中所有分区和副本的状态，当某个分区的 Leader 节点发生宕机（一个分区中存在多个不同的副本，只有Leader副本提供对外服务），该控制器将负责该分区选举Leader副本，当检测到某个分区的ISR分区副本数据中发生变化的时候该控制器负责通知给所有的broker，当某个topic增加分区数量时，由控制器负责分区重新分配。

下面是控制器的作用：

• 主题管理（创建、删除、增加分区）

  这里的主题管理，就是指控制器帮助我们完成对 Kafka 主题的创建、删除以及分区增加的操作。换句话说，当我们执行kafka-topics 脚本时，大部分的后台工作都是控制器来完成的。

• 分区重分配

  分区重分配主要是指，kafka-reassign-partitions 脚本提供的对已有主题分区进行细粒度的分配功能。这部分功能也是控制器实现的。

• 集群成员管理

  自动检测新增 Broker、Broker 主动关闭及被动宕机。这种自动检测是依赖于ZooKeeper 的 Watch 功能和 ZooKeeper 的临时节点组合实现的。比如，控制器组件会利用Watch 机制检查 ZooKeeper 的 /brokers/ids 节点下的子节点变化情况。

  当有新 Broker 启动后，它会在 /brokers 下创建专属的 znode 节点。一旦创建完毕，ZooKeeper 会通过 Watch 机制将消息通知推送给 Broker 控制器，这样，控制器就能自动地感知到这个变化，进而开启后续的新增 Broker 作业。

  侦测 Broker 存活性还是依赖于 ZooKeeper的临时节点。每个 Broker 启动后，会在 /brokers/ids 下创建一个临时 znode。当 Broker 宕机或主动关闭后，该 Broker 与 ZooKeeper 的会话结束，这个 znode 会被自动删除。同理，ZooKeeper 的 Watch 机制将这一变更推送给Broker 控制器，这样控制器就能知道有 Broker 关闭或宕机了，从而进行后续处理。

• 数据服务

  控制器的最后一大类工作，就是向其他 Broker 提供数据服务，控制器上保存了最全的集群元数据信息，其他所有 Broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

  当控制器发现一个 broker 离开集群，便会检测该broker 下是否有leader 分区，如果存在，控制器会依次遍历每个分区，根据 ISR 确定新的 leader，然后向所有 broker 发送消息，该请求消息包含谁是新的 leader 以及谁是 follower 。随后，新的 Leader 开始处理来自生产者和消费者的请求，Follower 用于从新的 Leader 那里进行复制。

二、控制器的故障选举策略

从上面就可以看出，控制器十分依赖于 ZooKeeper的临时节点。当Broker 控制器宕机之后，该对应的临时节点会被删除，其他的Broker 会自动感知，从新进入竞选Broker控制器。

其实现原理类似给予 ZooKeeper 的分布式锁的实现，利用临时节点的唯一性，以及 ZooKeeper 的事件通知机制进行选举出控制节点。

剩下存活的 Broker 会创建相同的临时节点，谁能够创建成功 谁就是为Broker控制器如果没有创建该临时节点成功的Broker，订阅该临时节点，如果当它宕机之后，会发送事件通知给没有创建成功Broker从新开始竞争控制器管理者。

文章来源: blog.csdn.net，作者：小毕超，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/qq_43692950/article/details/125100270