Kafka Controller 是 Kafka 的焦点组件，在前面的文章中，已经具体报告过 Controller 部门的内容。在已往的几年按照各人在出产情况中应用的反馈，昆山软件开发，Controller 也积聚了一些较量大的问题，而针对这些问题的修复，代码的窜改量都长短常大的，无疑是一次重构，因此，社区筹备在新版的系统里对 Controller 做一些相应的优化（0.11.0及今后的版本），相应的设计方案见：Kafka Controller Redesign，本文的内容就是团结这篇文章做一个简朴的总结。

Controller 成果

在一个 Kafka 中，Controller 要处理惩罚的工作总结如下表所示：

劳务调派打点系统 equentially； The TopicDeletionManager kafka.controller.DeleteTopicsThread； Per-broker RequestSendThread within ControllerChannelManager. 所有这些线程都需要会见或修改状态信息（ControllerContext）" class="aligncenter size-full wp-image-30250" title="Snipaste_2018-10-13_08-47-24" src="/uploads/allimg/c181014/1539460912R450-1U42.png" />

Controller 今朝存在的问题

之所以要从头设计 Controller，是因为此刻的 Controller 积聚了一些较量难办理的问题，这些问题办理起来，代码窜改量都是庞大的，甚至需要改变 controller 部分的设计，根基就跟重构差不多了，下面我们先来了看一下 controller 之前（主要是 0.11.0 之前的版本）存在的一些问题。

今朝碰着的较量大的问题有以下几个：

1. Partition 级别同步 zk 写；
2. sequential per-partition controller-to-broker requests；
3. Controller 巨大的并发语义；
4. 代码组织杂乱；
5. 节制类请求与数据类请求未疏散；
6. Controller 给 broker 的请求中没有 broker 的 generation信息；
7. ZkClient 阻碍 Client 的状态打点。

Partition 级别同步 zk 写

zookeeper 的同步写意味着在下次写之前需要期待前面整个进程的竣事，并且由于它们都是 partition 粒度的（一个 Partition 一个 Partition 的去执行写操纵），对付 Partition 很是多的集群来说，需要期待的时间会更长，Controller 凡是会在下面这两个处所做 Partition 级别 zookeeper 同步写操纵：

1. PartitionStateMachine 在举办触发 leader 选举（partition 目标状态是 OnlinePartition），将会触发上面的操纵；
2. ReplicaStateMachine 更新 LeaderAndIsr 信息到 zk（replica 状态转变为 OfflineReplica），这种环境也触发这种环境，它既阻碍了 Controller 历程，也有大概会 zk 造成压力。

sequential per-partition controller-to-broker requests

Controller 在向 Broker 发送请求，有些环境下也是 Partition 粒度去发送的，效率很是低，好比在 Controller 处理惩罚 broker shutdown 请求时，这里是按 Partition 级别处理惩罚，每处理惩罚一个 Partition 城市执行 Partition、Replica 状态变革以及 Metadata 更新，而且挪用 sendRequestsToBrokers() 向 broker 发送请求，这样的话，效率将变得很是低。

Controller 巨大的并发语义

Controller 需要在多个线程之间共享状态信息，这些线程有：

1. IO threads handling controlled shutdown requests
2. The ZkClient org.I0Itec.zkclient.ZkEventThread processing zookeeper callbacks sequentially；
3. The TopicDeletionManager kafka.controller.DeleteTopicsThread；
4. Per-broker RequestSendThread within ControllerChannelManager.

所有这些线程都需要会见或修改状态信息（ControllerContext），此刻它们是通过 ControllerContext 的 controllerLock（排它锁）实现的，Controller 的并发变得虚弱无力。

代码组织杂乱

KafkaController 部门的代码组织（KafkaController、PartitionStateMachine 和 ReplicaStateMachine）不是很清晰，好比，下面的问题就很难答复：

1. where and when does zookeeper get updated?
2. where and when does a controller-to-broker request get formed?
3. what impact does a failing zookeeper update or controller-to-broker request have on the cluster state?

这也导致了这部门许多开拓者不敢等闲去窜改。

节制类请求与数据类请求未疏散

此刻 broker 收到的请求，有来自 client、broker 和 controller 的请求，这些请求城市被放到同一个 requestQueue 中，昆山软件开发，它们有着同样的优先级，所以来自 client 的请求很大概会影响来自 controller 请求的处理惩罚（假如是 leader 变换的请求，ack 配置的不是 all，这种环境有大概会导致数据丢失）。

Controller 给 broker 的请求中没有 broker 的 generation信息

这里的 Broker generation 代表着一个标识，每当它从头插手集群时，这个标识城市变革。假如 Controller 的请求没有这个信息的话，大概会导致一个重启的 Broker 收到之前的请求，让 Broker 进入到一个错误的状态。

好比，Broker 收到之前的 StopReplica 请求，大概会导致副本同步线程退出。

ZkClient 阻碍 Client 的状态打点