Kafka控制器
1.Zookeeper
Zookeeper对Kafka集群的管理操作主要是用了它的两个功能
- 节点（临时节点【zookeeper重启删除】持久节点）
- watch机制
老版本的劣势（完全使用Zookeeper进行管理）：
Zookeeper进行完全进行kafka集群管理的劣势：
- 完全依赖于Zookeeper进行管理，每个Broker会在Zookeeper上为分区和副本注册大量的Watcher。当分区和副本发生变化的时候，会唤醒很多不必要的Watcher。会造成脑裂、羊群的效应。
- 会造成Zookeeper过载的隐患。
新版本的kafka使用了Controller只有Controller在zk上注册Watcher，其他的Broker极少需要在Zk上注册监听器，仅仅需要注册/controller监听器，去确定为一的activeControler即可。
2. Kafka Controller
首先即使是新版版的Kafka集群是比较依赖于Zookeeper的管理的，Kafka实现了Controller仅仅是对（kafka 控制器）Zookeeper的劣势进行了优化。
连接Zookeeper集群
./zkClient.sh server 127.0.0.1:2181
可以查看到当前Zookeeper下管控的节点。
2.1.Kafka Controller 和Zookeeper 的点点滴滴
**Controller依赖Zookeeper来对Kafka集群进行管理和协调。**一个集群下只能有一个控制器对整个集群起管控功能，控制器是严重依赖于Zookeeper的。下边是一张kakfa的整体架构图：
下边是一张kakfa的整体架构图，解释了Controller如何通过Zookeeper来进行对集群的管控，如下图所示，需要注意一下几点：
- **1.一个Kafka集群只能有一个Controller。**就是第一个连接入Zookeeper集群，并在Zookeeper下注册了controller信息。
- 2.Controller 其实是不存在的一个组件，它是在Broker上的。
- **3.Controller 依赖Zookeeper 来对集群进行管理和协调，是严重依赖于Zookeeper的。**Controller通过Zookeeper的Watch机制，对Kafka集群它关心的节点进行监控，一旦这些节点发生变化，Zookeeper通过ChangeHandler通知Controller，Controller去做相应的处理。
- 4.控制器初始化需要去Zookeeper上拉取集群元数据信息。
2.2Kafka控制器的职责
控制器有很多的职责，比较重要的就是一下的五个功能：
2.3 控制器选举与故障转移
如下图所示，
1.当Kafka集群重启时，第一个连接到Zk集群并且在Zk集群下成功创建/Controller节点的Broker为Controller所在机器。/controller的格式为{“version”:xx,“brokerid”:xx,“timestamp”:“xx”}
2.当Broker1宕机，zk感知到后，通知Broker重新开始Leader选举，此时假设，Broker4，选举成功，更新/controller节点的brokerid为4.同时增加/controller_epoch的值，这个值可以理解为当前Leader的版本号。用来判断是不是最新的请求。
2.4控制器优化
1.处理请求
Kafka 0.11版本之前对于公共信息的修改采用的是多线程加锁的方式，其实这样做大大降低了系统的性能。在之后的版本kafka使用了单线程+队列的方式，来去处理这些公共的资源（Topic的操作等等。）。
如图所示，具体做法就是对于公共资源的Watcher操作按照时间发生的先后顺序放到LinkedBlockingQueue中，使用一个专属的线程（ControllerEventThread）按照队列的特性处理各个事件。这样就不需要大量的ReentranLock来保证数据的安全了。事实证明这样做大大的减少了kafka的bug，而且也提升了效率。
2.Zookeeper异步操作
极客时间《kafka核心技术与实战》：
将之前同步操作 ZooKeeper 全部改为异步操作。ZooKeeper 本身的 API 提供了同步写和异步写两种方式。之前控制器操作 ZooKeeper 使用的是同步的 API，性能很差，集中表现为，当有大量主题分区发生变更时，ZooKeeper 容易成为系统的瓶颈。新版本 Kafka 修改了这部分设计，完全摒弃了之前的同步 API 调用，转而采用异步 API 写入 ZooKeeper，性能有了很大的提升。根据社区的测试，改成异步之后，ZooKeeper 写入提升了 10 倍！