一、控制器是什麼東東？
控制器組件（Controller），是 Apache Kafka 的核心組件。它的主要作用是在 Apache ZooKeeper 的幫助下管理和協調整個 Kafka 集羣。集羣中任意一臺 Broker 都能充當控制器的角色，但是，在運行過程中，只能有一個 Broker 成爲控制器，行使其管理和協調的職責。
二、控制器是怎麼選出來？
Broker 在啓動時，會嘗試去 ZooKeeper 中創建 /controller 節點。Kafka 當前選舉控制器的規則是：第一個成功創建 /controller 節點的 Broker 會被指定爲控制器。
三、控制器的作用？
1.主題管理（創建、刪除、增加分區）
2.分區重分配
3.Preferred 領導者選舉
4.集羣成員管理（新增 Broker、Broker 主動關閉、Broker 宕機）
5.數據服務
四、控制器中保存了哪些數據？
具體有哪些數據看上圖，其中比較重要的數據有：
1、所有主題信息。包括具體的分區信息，比如領導者副本是誰，ISR 集合中有哪些副本等。
2、所有 Broker 信息。包括當前都有哪些運行中的 Broker，哪些正在關閉中的 Broker 等。
3、所有涉及運維任務的分區。包括當前正在進行 Preferred 領導者選舉以及分區重分配的分區列表。
這些數據其實在 ZooKeeper 中也保存了一份。每當控制器初始化時，它都會從 ZooKeeper 上讀取對應的元數據並填充到自己的緩存中。
五、控制器故障轉移（Failover）
Kafka集羣中控制器只有一個，如果控制器所在的broker掛了怎麼辦呢？
控制器一旦掛了，zookeeper就通知其它broker，第一個在zookeeper上創建/controller目錄的broker就是新的controller所在的broker。
六、控制器內部設計原理
社區於 0.11 版本重構了控制器的底層設計，最大的改進就是，把多線程的方案改成了單線程加事件隊列的方案。我直接使用社區的一張圖來說明。
從這張圖中，我們可以看到，社區引入了一個事件處理線程，統一處理各種控制器事件，然後控制器將原來執行的操作全部建模成一個個獨立的事件，發送到專屬的事件隊列中，供此線程消費。這就是所謂的單線程 + 隊列的實現方式。
針對控制器的第二個改進就是，將之前同步操作 ZooKeeper 全部改爲異步操作。ZooKeeper 本身的 API 提供了同步寫和異步寫兩種方式。之前控制器操作 ZooKeeper 使用的是同步的 API，性能很差，集中表現爲，當有大量主題分區發生變更時，ZooKeeper 容易成爲系統的瓶頸。新版本 Kafka 修改了這部分設計，完全摒棄了之前的同步 API 調用，轉而採用異步 API 寫入 ZooKeeper，性能有了很大的提升。根據社區的測試，改成異步之後，ZooKeeper 寫入提升了 10 倍！
自 2.2 開始，Kafka 正式支持這種不同優先級請求的處理。簡單來說，Kafka 將控制器發送的請求與普通數據類請求分開，實現了控制器請求單獨處理的邏輯。