Kafka学习笔记:控制器Controller

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

控制器选举

Broker 在启动时&＃xff0c;会尝试去 ZooKeeper 中创建 /controller 节点。

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

控制器作用

1.主题管理&＃xff08;创建、删除、增加分区&＃xff09;

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

2.分区重分配

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

3.Preferred 领导者选举

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

4.集群成员管理&＃xff08;新增 Broker、Broker 主动关闭、Broker 宕机&＃xff09;

自动检测新增 Broker、Broker 主动关闭及被动宕机。这种自动检测是依赖于 Watch 功能和 ZooKeeper 临时节点组合实现的。

控制器组件会利用 Watch 机制检查 ZooKeeper 的 /brokers/ids 节点下的子节点数量变更。当有新 Broker 启动后&＃xff0c;它会在 /brokers 下创建专属的 znode 节点。一旦创建完毕&＃xff0c;ZooKeeper 会通过 Watch 机制将消息通知推送给控制器&＃xff0c;这样&＃xff0c;控制器就能自动地感知到这个变化&＃xff0c;进而开启后续的新增 Broker 作业。

每个 Broker 启动后&＃xff0c;会在 /brokers/ids 下创建一个临时 znode。当 Broker 宕机或主动关闭后&＃xff0c;该 Broker 与 ZooKeeper 的会话结束&＃xff0c;这个 znode 会被自动删除。同理&＃xff0c;ZooKeeper 的 Watch 机制将这一变更推送给控制器&＃xff0c;这样控制器就能知道有 Broker 关闭或宕机了&＃xff0c;从而进行“善后”。

5.数据服务

向其他 Broker 提供数据服务。控制器上保存了最全的集群元数据信息&＃xff0c;其他所有 Broker 会定期接收控制器发来的元数据更新请求&＃xff0c;从而更新其内存中的缓存数据。

所有主题信息。包括具体的分区信息&＃xff0c;比如领导者副本是谁&＃xff0c;ISR 集合中有哪些副本等。

所有 Broker 信息。包括当前都有哪些运行中的 Broker&＃xff0c;哪些正在关闭中的 Broker 等。

所有涉及运维任务的分区。包括当前正在进行 Preferred 领导者选举以及分区重分配的分区列表。

这些数据其实在 ZooKeeper 中也保存了一份。每当控制器初始化时&＃xff0c;它都会从 ZooKeeper 上读取对应的元数据并填充到自己的缓存中。有了这些数据&＃xff0c;控制器就能对外提供数据服务了。这里的对外主要是指对其他 Broker 而言&＃xff0c;控制器通过向这些 Broker 发送请求的方式将这些数据同步到其他 Broker 上。

控制器故障转移&＃xff08;Failover&＃xff09;

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

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

控制器内部设计原理

事件处理线程统一处理各种控制器事件&＃xff0c;然后控制器将原来执行的操作全部建模成一个个独立的事件&＃xff0c;发送到专属的事件队列中&＃xff0c;供此线程消费。这就是所谓的单线程 &＃43; 队列的实现方式。

同步操作 ZooKeeper 改为异步操作.采用同步操作,当有大量主题分区发生变更时&＃xff0c;ZooKeeper 容易成为系统的瓶颈. 异步操作比同步操作提升 10 倍性能.

自 2.2 开始&＃xff0c;Kafka 正式支持这种不同优先级请求的处理。

附加

控制器组件出现问题时&＃xff0c;比如主题无法删除了&＃xff0c;或者重分区 hang 住了&＃xff0c;你不用重启 Kafka Broker 或控制器。有一个简单快速的方式是&＃xff0c;去 ZooKeeper 中手动删除 /controller 节点。具体命令是 rmr /controller。这样做的好处是&＃xff0c;既可以引发控制器的重选举&＃xff0c;又可以避免重启 Broker 导致的消息处理中断。

引用:

Kafka核心技术与实战 - 胡夕