1.zookeeper是什麼？
zookeeper是一個開源的分佈式數據一致性的解決方案，分佈式應用程序可以基於zookeeper實現數據發佈訂閱，負載均衡，命名服務，分佈式協調，集羣管理，分佈式鎖和分佈式隊列等一系列功能，可以保證如下分佈式一致性特性：
1)順序一致性：從同一個客戶端發起的事務請求，最終將會嚴格按照其發起順序被應用到zookeeper中去；
2）原子性：要麼整個集羣所有機器都成功應用了某一個事務，要麼都沒有應用，一定不會出現集羣中部分機器應用了該事務，而另外一部分沒有應用的情況；
3）單一視圖：無論客戶端連接的是哪個zookeeper服務器，其看到的服務器算數據模型都是一致的；
4）可靠性：一旦服務端成功得應用了一個事務，並完成對客戶端的響應，那麼該事務所引起的服務端狀態變更會一致被保留下來，除非有另外一個事務又對其進行了變更；
5)實時性：zookeeper僅僅保證在一定的時間段內，客戶端最終一定能夠從服務端上讀取到最新的數據狀態。
2.ZAB協議是什麼？
ZAB協議是一種專門爲zookeeper設計的一種支持崩潰回覆的原子廣播協議，是一種通用的分佈式一致性算法，基於該協議，zookeeper實現了一種主備模式的系統架構來保持集羣中各副本之間數據的一致性。具體來說，zookeeper使用一個單一的主進程來接收並處理客戶端的所有事務請求，並採用ZAB的原子廣播協議，將服務器數據的狀態變更爲以事務的形式廣播到所有的副本進程上去，該協議的這個主備模式架構保證了同一時刻集羣中只能夠有一個主進程來廣播服務器的狀態變更。
簡言之，該協議核心就是定義了對於那些會改變zookeeper服務器數據狀態的事務請求的處理方式，所有事務請求都必須由一個全局唯一的服務器來協調處理，即leader服務器。
3.zookeeper爲什麼能保證全局數據一致性？
（1）首先，zookeeper集羣每個節點都可以接收到客戶端請求；
（2）其次，客戶端請求分爲兩種請求，一種請求是事務性請求，另一種是非事務性請求，下邊就這兩種請求展開論述：
1）事務性請求：
當事務性請求是從節點接收到的，就會將請求轉發給主節點，然後讓主節點按照時間順序來指定各個節點完 成請求；當事務性請求是主節點接收到的，主節點將會直接自己按照客戶端請求順序來處理請求；
2）非事務性請求：任何節點收到了都可以自行處理；
4.主從集羣和主備集羣的區別？
1）主從集羣：一主多從，主從各司其職，主節點負責資源分配和任務調度，從節點負責具體的執行；
2）主備集羣：一主一備，主要是爲了解決單點故障問題，便於備份恢復
5.zookeeper的功能？
1）小文件系統；
2）watcher監控機制；
3）選舉制度
6.zookeeper都做了什麼？
1）命名服務：註冊中心，被用作提供服務地址，例如dubbo中zk就是被用作註冊中心的，專門記錄一些全局路徑，需要先在zk中註冊地址，然後當有請求需要訪問某個地址的時候，可以直接在zk中找到對應的地址去請求相應服務，就類似於一個總目錄一樣；
2）配置信息(watcher監控機制)：程序分佈式的部署在不同的機器上，將程序的配置信息放在zk的znode下，當有配置發生改變時，也就是znode發生變化時，可以通過改變zk中某個目錄節點的內容，利用watcher通知給各個客戶端，從而更改配置。
3）集羣管理：無非就是是否有新的機器加入或者機器被刪除，以及選舉主節點
4）分佈式鎖：(監控機制，這塊理解的還不是很透徹)
有了zookeeper的全局一致性文件系統，鎖的問題變得容易。鎖服務可以分爲兩類，一個是保持獨佔，另一個是控制時序。
對於獨佔鎖，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創建的distribute_lock 節點就釋放出鎖。
對於控制時序鎖， distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次執行。
7.zookeeper是怎麼選舉出來leader的？或者說選舉機制是怎樣的？
當leader崩潰或者leader失去大多數的follower時，zk就進入恢復模式，恢復模式即需要重新選舉出一個新的leader，讓所有的節點都恢復到一個正確的狀態。
Zk的選舉算法有兩種：一種是基於BasicLeaderElection實現的，另外一種是基於FastLeaderElection算法實現的。系統默認的選舉算法爲FastLeaderElection
基於BasicLeaderElection算法的選舉機制：
（1）選舉線程是一個獨立的線程，其主要功能是對投票結果進行統計，並選出推薦的Server；
（2）選舉線程首先向所有節點發起一次詢問(包括自己)；在收到回覆後，驗證是否是自己發起的詢問(驗證zxid是否一致)，然後獲取對方的id(myid)，並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息(id,zxid)，並將這些信息存儲到當次選舉的投票記錄表中；
（3）收到所有節點回復以後，就計算出zxid最大的那個節點，並將這個節點相關信息設置成下一次要投票的節點；
（5）線程將當前zxid最大的Server設置爲當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數，設置當前推薦的leader爲獲勝的Server，將根據獲勝的Server相關信息設置自己的狀態，否則，繼續這個過程，直到leader被選舉出來。 通過流程分析我們可以得出：要使Leader獲得多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1. 每個Server啓動後都會重複以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並定期進行快照，方便在恢復時進行狀態恢復
基於FastLeaderElection算法的選舉機制：
FastLeaderElection算法選舉流程是在選舉過程中，某Server首先向所有Server提議自己要成爲leader，當其它Server收到提議以後，解決epoch和 zxid的衝突，並接受對方的提議，然後向對方發送接受提議完成的消息，重複這個流程，最後一定能選舉出Leader。
基於FastLeaderElection算法的選舉機制的兩種情況下選舉：
第一種：全新選舉
假設目前有 5 臺服務器，每臺服務器均沒有數據，它們的編號分別是1,2,3,4,5,按編號依次啓動，
它們的選擇舉過程如下：
l 服務器 1 啓動，給自己投票，然後發投票信息，由於其它機器還沒有啓動所以它收不到反饋信息，服務器 1 的狀態一直屬於 Looking。
l 服務器 2 啓動，給自己投票，同時與之前啓動的服務器 1 交換結果，由於服務器 2 的編號大所以服務器 2 勝出，但此時投票數沒有大於半數，所以兩個服務器的狀態依然是 LOOKING。
l 服務器 3 啓動，給自己投票，同時與之前啓動的服務器 1,2 交換信息，由於服務器 3 的編號最大所以服務器 3 勝出，此時投票數正好大於半數，所以服務器 3 成爲領導者，服務器 1,2 成爲小弟。
l 服務器 4 啓動，給自己投票，同時與之前啓動的服務器 1,2,3 交換信息，儘管服務器 4 的編號大，但之前服務器 3 已經勝出，所以服務器 4 只能成爲小弟。
l 服務器 5 啓動，後面的邏輯同服務器 4 成爲小弟
第二種：非全新選舉
對於運行正常的 zookeeper 集羣，中途有機器 down 掉，需要重新選舉時，選舉過程就需要加入數據 ID、服務器 ID 和邏輯時鐘。
這樣選舉的標準就變成：
1、邏輯時鐘小的選舉結果被忽略，重新投票；
2、統一邏輯時鐘後，數據 id 大的勝出；
3、數據 id 相同的情況下，服務器 id 大的勝出；
根據這個規則選出 leader。