前言
在瞭解了zk的基本概念以後，我們來介紹一下ZK的核心原理。 沒有了解過zk的同學，請先去了解zk的基本概念---->>>ZooKeeper入門指南
zk的角色
ZooKeeper的zab協議
zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。 zab協議有兩種模式，分別是恢復模式和廣播模式。當服務啓動或者leader崩潰後，Zab就進入了恢復模式。當leader被選舉出來且超過一半的server完成了跟leader的狀態同步以後，恢復模式結束。
zookeeper的工作原理
爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每個Server在工作過程中有三種狀態：
- LOOKING：當前server沒有發現leader的情況，通常出現在server啓動時。
- LEADING：當前server成爲了leader。
- FOLLOWING：leader已經選舉出來，當前Server與之同步
一、選主流程
當leader奔潰或者leader失去超過一半的follower，這時候會進入恢復模式，恢復模式需要重新選舉一個 新的leader，讓所有server都恢復到一個正確的狀態。
zk的選舉算法有兩種：一種是基於basic paxos算法實現的，另一種是基於 fast paxos算法實現的（系統默認）。
1.1 Basic Paxos 選舉原理
paxos算法[帕克索斯]是最重要的分佈式一致性算法，很多人都把它稱作”分佈式一致性協議“的代名詞。分佈式一致性算法是分佈式計算領域的基礎性問題，其最基本的功能是爲了多個進程之間對某個某些值達成強一致性；進而解決分佈式系統的高可用的問題 。
選舉線程由當前server擔任，該server負責對投票結果進行統計並選出推薦leader。
選舉線程向集羣中所有節點發起提議（proposal），包括自己。選舉線程收到server的回覆之後，通過ZXID驗證對方的回覆信息，是否是自己發起的提議。驗證通過後，選舉線程去獲取對方server的ZXID並存儲到當前提議列表。並獲取對方server提議的leader信息，將推薦leader的關鍵信息存儲到本次選舉投票記錄表。- 當
選舉線程收到所有的server回覆之後，判斷本次選舉投票記錄表中是否有leader獲得超過一半（(集羣節點數/2)+1）票數的推薦。 若有，新leader產生，選舉成功！ 若無，從選舉投票記錄表計算出ZXID最大的server節點，並將這個server節點設置成下一次要投票的server，繼續選舉流程。
- tips：爲了選舉成功，要求zookeeper集羣部署必須是奇數節點。
1.2 Fast Paxos 選舉原理
- 與
Basic Paxos選舉的區別在於，選舉線程在發起提議之初，會主動提議自己成爲leader。 - 當其他server收到提議後，解決epoch和zxid的衝突，並接受對方的提議，然後向對方發送接受提議完成的消息，重複整個流程，完成選舉。
二、狀態同步流程
重新選舉leader之後，zk就會進入狀態同步的過程。
- leader等待server連接
- follower連接leader，將最大的zxid發送給leader
- leader根據follower的zxid確定同步點
- 完成同步後通知follower已經成爲uptodate狀態
- follower收到uptodate消息後，又可以重新接受client的請求了。
三、leader的工作流程
- 恢復數據
- 維持與learner的心跳，接受learner請求並判斷learner的請求消息類型，根據不同 消息類型，進行不同處理。 消息類型包括：
- PING消息 - leader與learner心跳監測
- REQUEST消息 - follower發送的提議請求、寫請求和同步請求
- ACK消息 - follower對提議的回覆
- REVALIDATE消息 - 用來延長session的有效時間
四、follower的工作流程
- 向leader 發送請求（PING,REQUEST,ACK,REVALIDATE）
- 接收leader消息並處理
- 接收client請求，如果爲寫請求，轉發送給leader
- 返回client結果