(七)Kafka的心脏——控制器

Natasha_
872 阅读8分钟

1. 什么是控制器

控制器组件（Controller），是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一台 Broker 都能充当控制器的角色，但是，在运行过程中，只能有一个 Broker 成为控制器，行使其管理和协调的职责。换句话说，每个正常运转的 Kafka 集群，在任意时刻都有且只有一个控制器，它负责管理和协调整个Kafka集群。

2. Zookeeper在Kafka中的作用

在开始之前，先简单介绍一下 ZooKeeper ，要知道，zookeeper 是 kafka 不可分割的一部分，可见其重要程度，所以我们有必要了解一下 zookeeper 在 kafka 中的具体工作内容。

ZooKeeper 是一个提供高可靠性的分布式协调服务框架。它使用的数据模型类似于文件系统的树形结构，根目录也是以“/”开始。该结构上的每个节点被称为 znode，用来保存一些元数据协调信息。如果以 znode 持久性来划分，znode 可分为持久性 znode 和临时 znode。持久性 znode 不会因为 ZooKeeper 集群重启而消失，而临时 znode 则与创建该 znode 的 ZooKeeper 会话绑定，一旦会话结束，该节点会被自动删除。

在Kafka中，Zookeeper主要有下面几个作用：

  1. zookeeper 记录了所有 broker 的存活状态，broker 会向 zookeeper 发送心跳请求来上报自己的状态。zookeeper 维护了一个正在运行并且属于集群的 broker 列表。
  2. kafka 集群中有多个 broker，其中有一个会被选举为控制器，从多个 broker 中选出控制器，这个工作就是 zookeeper 负责的。
  3. zookeeper 记录着 ISR 的信息，而且是实时更新的，只要发现其中有成员不正常，马上移除。
  4. zookeeper 保存了所有 node 和 topic 的注册信息，node 和 topic 在 zookeeper 中是以临时节点的形式存在的，只要与 zookeeper 的 session 一关闭，他们的信息就没有了。
  5. zookeeper 保存了 topic 相关配置，例如 topic 列表、每个 topic 的 partition 数量、副本的位置等等。
  6. 当集群变化时通知Kafka，这些变化包括新建Topic、Broker上线/下线、删除Topic img

3. 控制器的作用

  1. 主题管理：控制器会帮助我们完成Topic 的创建、删除以及增加分区。也就是当执行 kafka-topics.sh 脚本时，大部分的后台工作是由Kafka控制器完成的。

  2. 分区重分配：为Zookeeper中的/admin/reassign_partitions节点注册PartitionReassignmentListener，用来处理分区重分配的动作。为Zookeeper中的/isr_change_notification节点注册IsrChangeNotificetionListener，用来处理ISR集合变更的动作。为Zookeeper中的/admin/preferred-replica-election节点添加PreferredReplicaElectionListener，用来处理优先副本的选举动作。

  3. Preferred 领导者选举：主要是Kafka为了避免因部分 Broker 的负载过重，而提供的一种换 Leader 的方案。

  4. 集群成员管理：为Zookeeper中的/brokers/ids/节点添加BrokerChangeListener，用来处理broker增减的变化。/brokers/ids/ 下面会存放 Broker 实例的id 临时节点，当我们看到 /brokers/ids 下面有几个节点，就表示有多少个存活的 Broker 实例。当Broker 宕机时，临时节点就会被删除，此时控制器对应的监听器就会感知到Broker 下线，进而完成对应的下线工作。

  5. 数据服务：控制器存放了最全的集群元数据信息，其他 Broker 会定期接收控制器发来的更新请求，从而定期的刷新来更新元数据信息。

  6. 启动并管理分区状态机和副本状态机。

    img

4. 控制器选举

每个代理节点都会作为ZooKeeper的客户端，向ZooKeeper 服务端尝试创建 /controller 临时节点，但是最终只有 1 个Broker 可以成功创建临时节点。因为 /controller 节点是临时节点，当主控制器出现故障或者会话失效时，临时节点会被删除。此时所有的Broker 都会重新竞选 Leader，也就是尝试创建 /controller 临时节点。

img

Kafka 控制器将Broker 节点信息存放在 ZooKeeper 的 /controller 节点上。除此之外，集群相关的元数据信息也会存储到 ZooKeeper 中，主控制器会读取 ZooKeeper 中的集群元数据信息，构造出控制器上下文（ControllerContext）。

5. 控制器故障转移（Failover）

我们在前面强调过，在 Kafka 集群运行过程中，只能有一台 Broker 充当控制器的角色，那么这就存在单点失效（Single Point of Failure）的风险，Kafka 是如何应对单点失效的呢？答案就是，为控制器提供故障转移功能，也就是说所谓的 Failover。

故障转移指的是，当运行中的控制器突然宕机或意外终止时，Kafka 能够快速地感知到，并立即启用备用控制器来代替之前失败的控制器。这个过程就被称为 Failover，该过程是自动完成的，无需你手动干预。

img

最开始时，Broker 0 是控制器。当 Broker 0 宕机后，ZooKeeper 通过 Watch 机制感知到并删除了 /controller 临时节点。之后，所有存活的 Broker 开始竞选新的控制器身份。Broker 3 最终赢得了选举，成功地在 ZooKeeper 上重建了 /controller 节点。之后，Broker 3 会从 ZooKeeper 中读取集群元数据信息，并初始化到自己的缓存中。至此，控制器的 Failover 完成，可以行使正常的工作职责了。

Zookeeper中还有一个与控制器有关的/controller_epoch节点，这个节点是持久（Persistent）节点，节点中存放的是一个整型的controller_epoch值。controller_epoch值用于记录控制器发生变更的次数，即记录当前的控制器是第几代控制器，我们也可以称之为“控制器纪元”。

controller_epoch的初始值为1，即集群中的第一个控制器的纪元为1，当控制器发生变更时，每选出一个新的控制器就将该字段值加1。每个和控制器交互的请求都会携带controller_epoch这个字段。Kafka通过controller_epoch来保证控制器的唯一性，进而保证相关操作的一致性。

6. 控制器内部设计原理

控制器在选举成功之后会读取Zookeeper中各个节点的数据来初始化上下文信息（ControllerContext），并且也需要管理这些上下文信息，比如为某个topic增加了若干个分区，控制器在负责创建这些分区的同时也要更新上下文信息，并且也需要将这些变更信息同步到其他普通的broker节点中。

这些信息变更可能是监听器触发，也可能是定时任务触发，但最终都会转换为一个个事件，按照事件发生的先后顺序压到LinkedBlockingQueue队列中，然后由事件处理线程 ControllerEventThread按照FIFO的原则去处理各个事件，这样就可以避开通过锁机制去维护多线程间的线程安全。

img

在 Kafka 0.11 版本之前，控制器的设计是相当繁琐的，代码更是有些混乱，导致社区中很多控制器方面的 Bug 都无法修复。

控制器是多线程的设计，会在内部创建很多个线程。比如，控制器需要为每个 Broker 都创建一个对应的 Socket 连接，然后再创建一个专属的线程，用于向这些 Broker 发送特定请求。如果集群中的 Broker 数量多，那么对应控制器端就需要创建更多的线程。

另外，控制器连接 ZooKeeper 的会话，也会创建单独的线程来处理 Watch 机制的通知回调。除了以上这些线程，控制器还会为主题删除创建额外的 I/O 线程。

比起多线程的设计，更糟糕的是，这些线程还会访问共享的控制器缓存数据。我们都知道，多线程访问共享可变数据是维持线程安全最大的难题。为了保护数据安全性，控制器不得不在代码中大量使用ReentrantLock 同步机制，这就进一步拖慢了整个控制器的处理速度。

鉴于这些原因，社区于 0.11 版本重构了控制器的底层设计，最大的改进就是，把多线程的方案改成了单线程+队列的方式，来去处理这些公共的资源（Topic的操作等等）

这个方案的最大好处在于，控制器缓存中保存的状态只被一个线程处理，因此不再需要重量级的线程同步机制来维护线程安全，Kafka 不用再担心多线程并发访问的问题，非常利于社区定位和诊断控制器的各种问题。

avatar
文章
阅读
粉丝