leader對於消息的寫入以及讀取是非常關鍵的，此時有兩個疑問：
1. Kafka如何確定某個partition是leader、哪個partition是follower呢?
2. 某個leader崩潰了，如何快速確定另外一個leader呢?因為Kafka的吞吐量很高、延遲很低，所以選舉leader必須非常快。
如果leader崩潰，Kafka會如何?
使用Kafka Eagle找到某個partition的leader，再找到leader所在的Broker。在Linux中強制殺掉該Kafka的進程，然後觀察leader的情況。
通過觀察，我們發現，leader在崩潰後，Kafka又從其他的follower中快速選舉出來了leader。
controller介紹
l Kafka啟動時，會在所有的broker中選擇一個controller
l 前面leader和follower是針對partition，而controller是針對broker的
l 創建topic、或者添加分區、修改副本數量之類的管理任務都是由controller完成的
l Kafka分區leader的選舉，也是由controller決定的
Controller的選舉
l 在Kafka集群啟動的時候，每個broker都會嘗試去ZooKeeper上註冊成為Controller(ZK臨時節點)
l 但只有一個競爭成功，其他的broker會註冊該節點的監視器
l 一點該臨時節點狀態發生變化，就可以進行相應的處理
l Controller也是高可用的，一旦某個broker崩潰，其他的broker會重新註冊為Controller
找到當前Kafka集群的controller
1. 點擊Kafka Tools的「Tools」菜單，找到「ZooKeeper Brower...」
2. 點擊左側樹形結構的controller節點，就可以查看到哪個broker是controller了。
測試controller選舉
通過kafka tools找到controller所在的broker對應的kafka進程，殺掉該進程，重新打開ZooKeeper brower，觀察kafka是否能夠選舉出來新的Controller。
Controller選舉partition leader
l 所有Partition的leader選舉都由controller決定
l controller會將leader的改變直接通過RPC的方式通知需為此作出響應的Broker
l controller讀取到當前分區的ISR，只要有一個Replica還倖存，就選擇其中一個作為leader否則，則任意選這個一個Replica作為leader
l 如果該partition的所有Replica都已經宕機，則新的leader為-1
為什麼不能通過ZK的方式來選舉partition的leader?
l Kafka集群如果業務很多的情況下，會有很多的partition
l 假設某個broker宕機，就會出現很多的partiton都需要重新選舉leader
l 如果使用zookeeper選舉leader，會給zookeeper帶來巨大的壓力。所以，kafka中leader的選舉不能使用ZK來實現。