- 朱小厮 深入理解kafka 核心设计与实践原理作者，RabbitMQ实战指南作者
- 博客地址：https://blog.csdn.net/u013256816/article/category/6695565/1
- 第一篇博文：直击Kafka的心脏——控制器 源地址
重点：有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态
Kafka中的控制器选举的工作依赖于Zookeeper，成功竞选为控制器的broker会在Zookeeper中创建/controller这个临时（EPHEMERAL）节点 {“version”:1,“brokerid”:0,“timestamp”:“1529210278988”}（version在目前版本中固定为1，brokerid表示称为控制器的broker的id编号，timestamp表示竞选称为控制器时的时间戳）
在任意时刻，集群中有且仅有一个控制器
Zookeeper中还有一个与控制器有关的/controller_epoch节点，这个节点是持久（PERSISTENT）节点，节点中存放的是一个整型的controller_epoch值
每个和控制器交互的请求都会携带上controller_epoch这个字段，如果请求的controller_epoch值小于内存中的controller_epoch值，则认为这个请求是向已经过期的控制器所发送的请求，那么这个请求会被认定为无效的请求。如果请求的controller_epoch值大于内存中的controller_epoch值，那么则说明已经有新的控制器当选了
Kafka通过controller_epoch来保证控制器的唯一性，进而保证相关操作的一致性。
具备控制器身份的broker需要比其他普通的broker多一份职责，具体细节如下：
1.监听partition相关的变化。
2.监听topic相关的变化
3.监听broker相关的变化
4.从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理
5.启动并管理分区状态机和副本状态机。
6.更新集群的元数据信息。
7.如果参数auto.leader.rebalance.enable设置为true，则还会开启一个名为“auto-leader-rebalance-task”的定时任务来负责维护分区的优先副本的均衡。
Kafka的控制器使用单线程基于事件队列的模型，将每个事件都做一层封装，然后按照事件发生的先后顺序暂存到LinkedBlockingQueue中，然后使用一个专用的线程（ControllerEventThread）按照FIFO（First Input First Output, 先入先出）的原则顺序处理各个事件，这样可以不需要锁机制就可以在多线程间维护线程安全。
- 触发新一轮的选举
- 当/controller节点被删除时（如果broker在节点被删除前是控制器的话，在选举前还需要有一个“退位”的动作）
- 可以手动删除/controller节点来触发新一轮的选举
- 关闭控制器所对应的broker
- 手动向/controller节点写入新的brokerid的所对应的数据
