透彻理解Kafka（六）——集群控制：Controller

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

Kafka集群启动时，会自动选举出一个Broker，承担Controller的责任。所谓Controller，就是Kafka集群的一个总控组件，负责管理整个集群，包括Leader Partition选举、分区负载均衡、管理集群元数据等等。

那么，本章我们就来看看，Controller的核心工作机制。

一、Controller选举

首先，我们来看下，Kafka是如何进行Controller选举的。

在Kafka集群启动的时候，每一个Broker都会尝试去Zookeeper创建一个/controller临时节点，Zookeeper会保证只有一个Client可以创建成功，创建成功的那个Broker就成为了Controller，集群中的其它Broker会监听这个节点。

根据Zookeeper的会话保持机制，一旦Controller所在的Broker宕机了，那么临时节点就会消失，由于集群的其它Broker会一直监听这个临时节点，所以一旦发现临时节点消失了，就会再次争抢创建临时节点，从而保证有一个新的Broker会成为Controller角色。

二、Partition Leader选举

Kafka在创建Topic时，一般都会指定Partition分区，每个分区都有一个Leader，N个Follower，那么Kafka是如何实现Partition Leader选举的呢？

1. 首先，在创建Topic时，Kafka就会往Zookeeper中注册Topic的元数据：包括分区数，每个分区有几个副本，每个副本的状态等等，分区副本的状态初始时都是NonExistentReplica；
2. Kafka Controller会监听Zookeeper的数据变更，当监听到Topic变动时，会从Zookeeper加载该Topic所有分区的副本到内存里，然后把这些副本的状态变更为NewReplica；
3. 最后，从中选择第一个副本作为Leader，其他都是Follower，并且把它们都加入到分区的ISR列表中，同时设置整个Partition的状态为OnlinePartition。

举个例子来理解下：

比如创建了一个order_topic，一共3个分区，每个分区共2个副本（一个Leader，一个Follower）。Kafka会将order_topic的元数据信息写入Zookeeper中：

    /topics/order_topic
    
    partitions = 3, replica_factor = 2
    
    [partition0_1, partition0_2]
    [partition1_1, partition1_2]
    [partition2_1, partition2_2]

Kafka Controller监听到变化后，会从每个Partition的副本列表中取第一个作为Leader，其它的就是follower，然后全部加入到该Partition对应的ISR列表中。

接着，Controller会根据一些算法让Partition的每个副本都均匀分布到不同机器，同时还会设置整个Partition的状态为OnlinePartition。

最后，Controller还会把这个Partition和副本所有的信息（包括谁是Leader，谁是Follower，ISR列表），都发送给所有Broker让他们知晓。所以，在Kafka集群中，每个Broker都有一份各个Partition的元数据。

三、Topic删除

当我们删除一个Topic时，Kafka Controller会发送请求给这个Topic的所有Partition所在的Broker机器，通知它们设置所有Partition副本的状态为OfflineReplica，也就是让这个Topic的所有分区副本下线。

接着，Controller会将全部副本状态变为ReplicaDeletionStarted，然后发送请求给Broker，把Partition副本的数据删除，也就是删除磁盘上的日志文件，删除成功后副本状态会变为ReplicaDeletionSuccessful。

最后，副本状态会变为NonExistentReplica，同时设置分区状态为Offline。