【Kafka】控制器（一）

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第5天，点击查看活动详情

一、前言

控制器组件（Controller）：是 Apache Kafka 的核心组件

• 主要作用是：在 Apache Zookeeper 的帮助下管理和协调整个 Kafka 集群。
• 集群中任意一台 Broker 都能充当控制器的角色，但在运行过程中，只能有一个 Broker 成为控制器。

控制器 Controller 5大职责：

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

执行 kafka-topics 脚本时，大部分的后台工作都是控制器来完成的。

2. 分区重分配

利用 kafka-reassign-partitions 脚本，对已有主题分区进行细粒度的分配功能。

3. Preferred 领导者选举

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

4. 集群成员管理（新增 Broker、Broker 主动关闭、Broker 宕机）

控制器组件会利用 Watch 机制检查 ZooKeeper 的 /brokers/ids 节点下的子节点数量变更。 当有新 Broker 启动后，它会在 /brokers 下创建专属的 znode 节点。

5. 数据服务：就是向其他 Broker 提供数据服务

控制器上保存了最全的集群元数据信息，其他所有 Broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

Tips：ZK 的数据模型类似文件系统的树形结构，根目录以 “/” 开始，该结构上的每个节点称为 znode。

znode 可分为：

• 持久性 znode：不会因为 ZK 集群重启而消失。
• 临时 znode：生命周期与创建该 znode 的 ZK 会话绑定，一旦会话结束，节点就会自动删除。

问题

1. 如何实现 Controller 选举以及故障转移？

（1）如何实现 Controller 选举？

• Broker 在启动时，会尝试去 ZooKeeper 中创建 /controller 节点。

• Kafka 当前选举控制器的规则是：第一个成功创建 /controller 节点的 Broker 会被指定为控制器。

  Zk 会保证只有一个会创建成功。

• 没有创建节点成功的 Broker，都会在 /controller 节点上加个监听器。

  ZooKeeper 赋予客户端监控 znode 变更的能力，即所谓的 Watch 通知功能。 一旦 znode 节点被创建、删除，子节点数量发生变化，抑或是 znode 所存的数据本身变更，ZooKeeper 会通过节点变更监听器 (ChangeHandler) 的方式显式通知客户端。

（2）如何实现 Controller 故障转移？

故障转移指的是，当运行中的控制器突然宕机或意外终止时，Kafka 能够快速地感知到，并立即启用备用控制器来代替之前失败的控制器。

控制器故障转移的过程如下：

0. Broker 0 一开始是控制器
1. 现在 Broker 0 宕机了，Zk 通过 Watch 机制感知到并删除了 /controller 临时节点
2. Broker 1 2 3 监听到 Zk 的消息，都开始竞选成为新的控制器
3. 最终，Broker 3 赢得了选举，成功地在 Zk 上重建了 /controller 节点
4. Broker 3 从 Zk 中读取集群元数据信息，并初始化到自己的缓存中。
5. Broker 3 开始行使正常的工作职责。

\