Kafka学习笔记（九）—Kafka控制器

Kafka控制器

在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态

Kafka控制器内部组件

可以看出控制制器内部还是有些复杂的，后续需要仔细研究下

Kafka控制器职责

• 监听partition相关的变化。为Zookeeper中的/admin/reassign_partitions节点注册PartitionReassignmentListener，用来处理分区重分配的动作

• 监听topic相关的变化。Zookeeper中的/brokers/topics节点添加TopicChangeListener，用来处理topic增减的变化

• 监听broker相关的变化。为Zookeeper中的/brokers/ids/节点添加BrokerChangeListener，用来处理broker增减的变化。当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本

• 从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理

• 启动并管理分区状态机和副本状态机

• 更新集群的元数据信息

• 参数auto.leader.rebalance.enable设置为true，则还会开启一个名为“auto-leader-rebalance-task”的定时任务来负责维护分区的优先副本的均衡

Kafka控制器选举

kafka每个broker启动的时候，都会实例化一个KafkaController，并将broker的id注册到zookeeper，集群在启动过程中，通过选举机制选举出其中一个broker作为leader

三种情况触发控制器选举：

• 集群启动
• 控制器所在代理发生故障
• zookeeper心跳感知，控制器与自己的session过期

选举过程：

1. 每个broker都从zookeeper获取/controller临时节点信息，查询是否存在leader
2. 不存在leader节点信息，返回-1
3. 每个broker均会触发向临时节点/controller写入自己的信息，最先写入的就会成为leader
4. 后来的broker发现已经存在leader节点信息，会抛出会抛出ZkNodeExistsException异常，写入失败
5. controller_epoch节点，存储了leader的变更次数，初始值为1，每次选举leader都会将该值+1

控制器在选举成功之后会读取Zookeeper中各个节点的数据来初始化上下文信息ControllerContext，此对象存储了控制器工作需要的所有上下文信息，包括存活的代理、所有主题及分区分配方案、每个分区的AR、leader、ISR等信息。

比如为某个topic增加了若干个分区，控制器在负责创建这些分区的同时也要更新上下文信息，并且也需要将这些变更信息同步到其他普通的broker节点中

监听器触发的事件，还是定时任务触发的事件，亦或者是其他事件（比如ControlledShutdown）都会读取或者更新控制器中的上下文信息，这样就会涉及到多线程间的同步，如果单纯的使用锁机制来实现，那么整体的性能也会大打折扣。针对这一现象，Kafka的控制器使用单线程基于事件队列的模型，将每个事件都做一层封装，然后按照事件发生的先后顺序暂存到LinkedBlockingQueue中，然后使用一个专用的线程（ControllerEventThread）按照FIFO（First Input First Output, 先入先出）的原则顺序处理各个事件，这样可以不需要锁机制就可以在多线程间维护线程安全