1. 首先zookeeper是什么
zookeeper是一個開放源代碼的分布式應用程序協調服務，可以把它看成是整個集群的管理者，監視者。
2. zookeeper能做什么
它可以實現諸如分布式應用配置管理、統一命名服務、狀態同步服務、集群管理等功能。
3. zookeeper服務與kafka集群的聯系
這里首先說一下broker的概念：Kafka 集群包含一個或多個服務器，這種服務器被稱為 broker，每個broker服務器都要連接到zk服務。
- 一個典型的kafka集群中包含若干個producer（生產者），若干broker（一般broker越多，集群吞吐率越高），若干consumer group（消費組），以及一個zookeeper服務。
- kafka通過zookeeper管理集群配置，選舉leader，以及在消費組發生變化時進行rebalance。
- producer使用push模式將消息發布到broker，consumer使用pull模式從broker訂閱並消費消息。
4. Leader選舉流程。
選舉流程主要出現在以下兩種情況發生時：
（1）服務器初始化啟動時；
（2）服務器在運行期間leader出現故障。
由於涉及到算法和流程較復雜，這里就以個人理解淺顯的描述以下選舉過程，如有不當的地方歡迎指正。
當服務器在初始化時啟動：
假設集群中共有3台機器，分別使用server1、server2、server3等來表示，按編號以此啟動起來。
第一步：每個server發起一個投票，推薦自己作為leader服務器，投票內容為（Serverid，Zxid），分別表示服務器ID、數據ID（服務器中存放定的最大數據ID）。由於server1先啟動，它的投票為（1，0），然后進入Looking狀態；
第二步：server2啟動，發起投票為（2,0），並與已啟動的server1交換結果，由於server2的編號2大於1，因此勝出，並告知server1。
第三步：server1將自己的投票改為（2,0），並重新投票。而server繼續維持之前投票（2,0）。這個時候統計第二輪投票，server2以兩票勝出，同時判斷當前投票人數為2，已經超過3台服務器的50%，因此結果生效，server2當選為Leader，狀態變為LEADING；server1狀態變為FOLLOWING。
第四部：此時server3啟動，發現Leader已經存在，則直接將自己的狀態調整為FOLLOWING。
注意：如果集群中有5台機器，那么由於投票人數不足50%，則需要保持Looking狀態，繼續等待新的投票者加入，直到超過50%為止。
當服務器在運行期間leader出現故障：
第一步：假設server2作為leader掛了之后，剩下所有機器都會將自己的狀態改為LOOKING，然后開始Leader選舉過程。
第二步：server1發出投票為（1，233），server3發出投票為（3,222）。
第三步：兩台機器互相接收來自別的服務器的投票，判斷投票的有效性（是否來自LOOKING狀態的服務器），然后進行將別人的投票與自己的投票進行PK，PK規則如下：1.優先檢查Zxid，Zxid較大的優先作為leader；2.如果Zxid相同，那么Serverid較大的勝出。對於當前情況來看，server1勝出。
第四步：發起第二輪投票，server3將自己投票改為（1,233），server1保持不變（1,233），此時判斷投票人數超過半數，server1勝出，當選為新leader。server1狀態改為LEADING，server3狀態改為FOLLOWING。
參考文章：《zookeeper的leader選舉過程》
https://blog.csdn.net/virtil33/article/details/94343215