Zookeeper工做原理

基本概念 

zookeeper的核心是原子廣播,這個機制保證了各個server之間的同步,實現這個機制的協議叫作zab協議。zab協議有兩種模式: 分別是恢復模式和廣播模式。

• 恢復模式，zookeeper配置爲集羣模式時，系統啓動或者是當前leader崩潰或者是當前leader丟失大多數的follower,zk進入恢復模式,恢復模式須要從新選舉出一個新的leader,當領導者被選舉出來，且大多數Server的完成了和leader的狀態同步之後，恢復模式就結束了。
• 廣播模式，狀態同步保證了Leader和全部Server都具備相同的系統狀態。這時候當Server加入Zookeeper集羣后，會先在恢復模式下啓動該Server，發現Leader後，並和Leader進行狀態同步，待到同步結束，它也參與消息廣播，即進入廣播狀態。Zookeeper服務一直維持在Broadcast狀態，直到Leader崩潰了或者Leader失去了大部分的Followers支持，纔會進入恢復模式，重新選舉Leader。

爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每一個Server在工做過程當中有三種狀態：
1. LOOKING：當前Server不知道leader是誰，正在搜尋
2. LEADING：當前Server即爲選舉出來的leader
3. FOLLOWING：leader已經選舉出來，當前Server與之同步

選主流程

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基於basic paxos實現的，另一種是基於fast paxos算法實現的。系統默認的選舉算法爲fast paxos。

basic paxos流程：
1. 選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，並選出推薦的Server；
2. 選舉線程首先向全部Server發起一次詢問(包括本身)；
3. 選舉線程收到回覆後，驗證是不是本身發起的詢問(驗證zxid是否一致)，而後獲取對方的id(myid)，並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息(id，zxid)，並將這些信息存儲到當次選舉的投票記錄表中；
4.  收到全部Server回覆之後，就計算出zxid最大的那個Server，並將這個Server相關信息設置成下一次要投票的Server；
5. 線程將當前zxid最大的Server設置爲當前Server要推薦的Leader，若是此時獲勝的Server得到n/2 + 1的Server票數， 設置當前推薦的leader爲獲勝的Server，將根據獲勝的Server相關信息設置本身的狀態，不然，繼續這個過程，直到leader被選舉出來。
每一個Server啓動後都會重複以上流程。在恢復模式下，若是是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並按期進行快照，方便在恢復時進行狀態恢復。

fast paxos流程

在選舉過程當中，某Server首先向全部Server提議本身要成爲leader，當其它Server收到提議之後，解決epoch和zxid的衝突，並接受對方的提議，而後向對方發送接受提議完成的消息，重複這個流程，最後必定能選舉出Leader。

同步流程

當經過選主流程選出leader以後，必定是集羣中數據最完整最新的節點。由於全部znode的變動都須要經過leader，leader會爲全部follower和observer建立learnerhandler線程用於接收同步數據請求，當follower和abserver收到leader發過來的信息，比較zxid的大小，若是zxid小於leader的zxid，則把節點最大的zxid發送給leader，leader會將大於該zxid的全部數據同步到該follower，完成同步後，通知改follower進入uptodate狀態，follower接收到uptodate消息後，就能夠接收client的請求了。
讀寫過程

• 寫數據，一個客戶端進行寫數據請求時，會指定zk集羣中節點，若是是follower接收到寫請求，就會把請求轉發給Leader，Leader經過內部的Zab協議進行原子廣播，直到全部zk節點都成功寫了數據後（內存同步以及磁盤更新），此次寫請求算是完成，而後zk service就會給client發回響應

• 讀數據，由於集羣中全部的zk節點都呈現一個一樣的命名空間視圖（就是結構數據），上面的寫請求已經保證了寫一次數據必須保證集羣全部的zk節點都是同步命名空間的，因此讀的時候能夠在任意一臺zk節點上
• ps:其實寫數據的時候不是要保證全部zk節點都寫完才響應，而是保證一半以上的節點寫完了就把此次變動更新到內存，而且當作最新命名空間的應用。因此在讀數據的時候可能會讀到不是最新的zk節點，這時候只能經過sync()解決。

數據一致性與paxos 算法

　　• 在一個分佈式數據庫系統中，若是各節點的初始狀態一致，每一個節點都執行相同的操做序列，那麼他們最後能獲得一個一致的狀態。
　　• Paxos算法解決的什麼問題呢，解決的就是保證每一個節點執行相同的操做序列。好吧，這還不簡單，master維護一個全局寫隊列，全部寫操做都必須 放入這個隊列編號，那麼不管咱們寫多少個節點，只要寫操做是按編號來的，就能保證一致性。沒錯，就是這樣，但是若是master掛了呢。
　　• Paxos算法經過投票來對寫操做進行全局編號，同一時刻，只有一個寫操做被批准，同時併發的寫操做要去爭取選票，只有得到過半數選票的寫操做纔會被 批准（因此永遠只會有一個寫操做獲得批准），其餘的寫操做競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，全部寫操做都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個編號爲100的寫操做，以後又接受到編號爲99的寫操做（由於網絡延遲等不少不可預見緣由），它立刻能意識到本身 數據不一致了，自動中止對外服務並重啓同步過程。任何一個節點掛掉都不會影響整個集羣的數據一致性（總2n+1臺，除非掛掉大於n臺）。

具體寫過程：

1.在Client向Follwer發出一個寫的請求
2.Follwer把請求發送給Leader
3.Leader接收到之後開始發起投票並通知Follwer進行投票
4.Follwer把投票結果發送給Leader
5.Leader將結果彙總後若是須要寫入，則開始寫入同時把寫入操做通知給Leader，而後commit;
6.Follwer把請求結果返回給Client