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选举的呢？
- 首先，在创建Topic时，Kafka就会往Zookeeper中注册Topic的元数据：包括分区数，每个分区有几个副本，每个副本的状态等等，分区副本的状态初始时都是
NonExistentReplica； - Kafka Controller会监听Zookeeper的数据变更，当监听到Topic变动时，会从Zookeeper加载该Topic所有分区的副本到内存里，然后把这些副本的状态变更为
NewReplica； - 最后，从中选择第一个副本作为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。
