kafka Controller 作用

原创：石头哥 @大数据架构师  2021 年 8 月 2 日   微信：nevian668899

概念和作用

1、Kafka Controller 是 Kakfa 服务端 Broker 的概念，Broker 集群有多台，但只有一台 Broker 可以扮演控制器的角色;

2、某台 Broker 一旦成为 Controller，它用于以下权力：完成对集群成员管理、主题维护和分区的管理，如集群 broker 信息、Topic 维护、Partition 维护、分区选举 ISR、同步元信息给其他 Broker 等。

为何要引入 Controller 角色？

我们暂且不深入分析他的作用，先思考下为何要引入控制器角色。前面也简单提到，它是控制器，完成对集群 Broker、主题和分区等管理工作，而且只有一个 leader 对外提供服务，是否我们可以猜测元数据的管理工作集中化管理和维护，再分布式同步给所有控制器，这样有利于维护元数据的一致性和稳定性。进一步，我们回溯 Kafka 的历史版本，以前版本的架构是严重依赖 zk 的 watch 机制，这里不再赘述 watch 监听的原理，不清楚可以自行查找资料熟悉下。先看下 Kafka 旧版本的元数据维护架构图：

图 1：老版本的 Kafka 元数据同步机制

历史版本的实现架构如上图所示，对于分区和副本的状态的管理依赖于 zookeeper 的 Watcher 和队列：每一个 broker 都会在 zookeeper 注册 Watcher，所以 zookeeper 就会出现大量的 Watcher, 如果宕机的 broker 上的 partition 比较多，会造成多个 Watcher 触发，造成集群内大规模调整；每一个 replica 都要去再次 zookeeper 上注册监视器，当集群规模很大的时候，zookeeper 负担很重。所以严重依赖 zk 实现元数据的协调同步，这样做的弊端有以下几点：

1. 当 Kafka 集群规模很大的时候，zookeeper 负担很重。因为所有 Broker 的所有主题分区都要与 zk 建立连接，分区上下线和 Broker 的宕机或重新启动，会触发多个 watch，给 zk 带来大量的写压力；

2. zk 压力大，容易引起网络风暴，不利于 Kafka 元数据的稳定性；

3. 这种设计容易出现脑裂（zk 集群的 brain-split 原理，请自行补充知识）和羊群效应。

架构优化

Kafka 官方团队也意识到严重依赖 zk 带来的弊端，于是对架构做了优化和调整。核心思想：

• 降低对 zk 的依赖程度，减少 zk 压力

• 元数据的控制和管理由中心化节点维护；

• 异步化同步元数据给集群所有节点，并做好同步的容错处理。

基于控制器概念的新版架构如下图所示：

图 2：基于控制器的元数据维护架构图

​

Kafka 集群中多个 broker，每个 broker 启动时都会创建 KafkaController 对象，但只有一个会被选举为 Controller leader，其他节点为 Controller Follower。

控制器的启动初始化

1、当 broker 启动的时候，都会创建 KafkaController 对象；

2、每个节点上的 KafkaController 会在指定的 zookeeper 路径下创建临时节点，只有第一个成功创建的节点的 KafkaController 才可以成为 leader，其余的都是 follower;

3、集群中只能有一个 leader 对外提供服务;

控制器运行时对元信息的处理流程

只有 Controller leader 向 zk 注册 watch 并监听元数据的变化，其他 broker 不用监听 zookeeper 的状态变化。大概流程：

1. 用户通过命令或控制台执行集群的管理操作，比如：扩锁容 Broker 集群、创建/删除 Topic、扩/缩容 Partition；

2. 第一步会触发集群在 zk 对应路径上变更节点信息，比如/brokers/topics；

3. Controller leader 收到 watch 的监听推送消息，通过监听接口收到对应的变更信息，比如主题信息、分区信息、集群 Broker 信息等；

4. Controller leader 根据推送的事件类型，做不同的逻辑处理。比如：Broker 加入或删除的相关流程、Topic 新增或删除的相关流程、 分区重分配引起的重分配相关流程 、Partition 扩展的相关流程（即分区 leader 选举和 ISR 同步）；

5. Controller leader 同步元信息至集群的 Controller Follower 节点。

控制器 Leader 如何 Failover

如果控制器 Leader 所在 broker 退出、崩溃或与 ZK 会话失效则 ZK 会删除/controller 内该子节点，各个 broker 的监视器收到这种变化后，每个 broker 开始竞争直到有一个竞争成为新的控制器 Leader，并向/controller 注册子节点，以及向/controller_EPOCH 注册子节点。此时，新一轮的 controller 周期开始运行，新的 leader 节点继续肩负起监听元数据变化、处理元信息并同步给集群的任务。