轉載：深刻淺出Zookeeper

 

ZAB協議

1. ZAB協議是專門爲zookeeper實現分佈式協調功能而設計。zookeeper主要是根據ZAB協議是實現分佈式系統數據一致性。
2. zookeeper根據ZAB協議創建了主備模型完成zookeeper集羣中數據的同步。這裏所說的主備系統架構模型是指，在zookeeper集羣中，只有一臺leader負責處理外部客戶端的事物請求(或寫操做)，而後leader服務器將客戶端的寫操做數據同步到全部的follower節點中。 
   
3. ZAB的協議核心是在整個zookeeper集羣中只有一個節點即Leader將客戶端的寫操做轉化爲事物(或提議proposal)。Leader節點再數據寫完以後，將向全部的follower節點發送數據廣播請求(或數據複製)，等待全部的follower節點反饋。在ZAB協議中，只要超過半數follower節點反饋OK，Leader節點就會向全部的follower服務器發送commit消息。即將leader節點上的數據同步到follower節點之上。 
4.  ZAB協議中主要有兩種模式，第一是消息廣播模式；第二是崩潰恢復模式

          

消息廣播模式

1. 在zookeeper集羣中數據副本的傳遞策略就是採用消息廣播模式。zookeeper中數據副本的同步方式與二階段提交類似可是卻又不一樣。二階段提交的要求協調者必須等到全部的參與者所有反饋ACK確認消息後，再發送commit消息。要求全部的參與者要麼所有成功要麼所有失敗。二階段提交會產生嚴重阻塞問題。
2. ZAB協議中Leader等待follower的ACK反饋是指」只要半數以上的follower成功反饋便可，不須要收到所有follower反饋」
3. 圖中展現了消息廣播的具體流程圖 
   
4. zookeeper中消息廣播的具體步驟以下： 
   4.1. 客戶端發起一個寫操做請求 
   4.2. Leader服務器將客戶端的request請求轉化爲事物proposql提案，同時爲每一個proposal分配一個全局惟一的ID，即ZXID。 
   4.3. leader服務器與每一個follower之間都有一個隊列，leader將消息發送到該隊列 
   4.4. follower機器從隊列中取出消息處理完(寫入本地事物日誌中)畢後，向leader服務器發送ACK確認。 
   4.5. leader服務器收到半數以上的follower的ACK後，即認爲能夠發送commit 
   4.6. leader向全部的follower服務器發送commit消息。
5. zookeeper採用ZAB協議的核心就是隻要有一臺服務器提交了proposal，就要確保全部的服務器最終都能正確提交proposal。這也是CAP/BASE最終實現一致性的一個體現。
6. leader服務器與每一個follower之間都有一個單獨的隊列進行收發消息，使用隊列消息能夠作到異步解耦。leader和follower之間只要往隊列中發送了消息便可。若是使用同步方式容易引發阻塞。性能上要降低不少。

 

崩潰恢復

1. zookeeper集羣中爲保證任何全部進程可以有序的順序執行，只能是leader服務器接受寫請求，即便是follower服務器接受到客戶端的請求，也會轉發到leader服務器進行處理。
2. 若是leader服務器發生崩潰，則zab協議要求zookeeper集羣進行崩潰恢復和leader服務器選舉。
3. ZAB協議崩潰恢復要求知足以下2個要求： 
   3.1. 確保已經被leader提交的proposal必須最終被全部的follower服務器提交。 
   3.2. 確保丟棄已經被leader出的可是沒有被提交的proposal。
4. 根據上述要求，新選舉出來的leader不能包含未提交的proposal，即新選舉的leader必須都是已經提交了的proposal的follower服務器節點。同時，新選舉的leader節點中含有最高的ZXID。這樣作的好處就是能夠避免了leader服務器檢查proposal的提交和丟棄工做。
5. leader服務器發生崩潰時分爲以下場景： 
   5.1. leader在提出proposal時未提交以前崩潰，則通過崩潰恢復以後，新選舉的leader必定不能是剛纔的leader。由於這個leader存在未提交的proposal。 
   5.2 leader在發送commit消息以後，崩潰。即消息已經發送到隊列中。通過崩潰恢復以後，參與選舉的follower服務器(剛纔崩潰的leader有可能已經恢復運行，也屬於follower節點範疇)中有的節點已是消費了隊列中全部的commit消息。即該follower節點將會被選舉爲最新的leader。剩下動做就是數據同步過程。

數據同步

1. 在zookeeper集羣中新的leader選舉成功以後，leader會將自身的提交的最大proposal的事物ZXID發送給其餘的follower節點。follower節點會根據leader的消息進行回退或者是數據同步操做。最終目的要保證集羣中全部節點的數據副本保持一致。
2. 數據同步完以後，zookeeper集羣如何保證新選舉的leader分配的ZXID是全局惟一呢？這個就要從ZXID的設計談起。 
   2.1 ZXID是一個長度64位的數字，其中低32位是按照數字遞增，即每次客戶端發起一個proposal,低32位的數字簡單加1。高32位是leader週期的epoch編號，至於這個編號如何產生(我也沒有搞明白)，每當選舉出一個新的leader時，新的leader就從本地事物日誌中取出ZXID,而後解析出高32位的epoch編號，進行加1，再將低32位的所有設置爲0。這樣就保證了每次新選舉的leader後，保證了ZXID的惟一性並且是保證遞增的。 
   

 

 

ZAB協議原理

1. ZAB協議要求每一個leader都要經歷三個階段，即發現，同步，廣播。
2. 發現：即要求zookeeper集羣必須選擇出一個leader進程，同時leader會維護一個follower可用列表。未來客戶端能夠這follower中的節點進行通訊。
3. 同步：leader要負責將自己的數據與follower完成同步，作到多副本存儲。這樣也是體現了CAP中高可用和分區容錯。follower將隊列中未處理完的請求消費完成後，寫入本地事物日誌中。
4. 廣播：leader能夠接受客戶端新的proposal請求，將新的proposal請求廣播給全部的follower。

Zookeeper設計目標

1. zookeeper做爲當今最流行的分佈式系統應用協調框架，採用zab協議的最大目標就是創建一個高可用可擴展的分佈式數據主備系統。即在任什麼時候刻只要leader發生宕機，都能保證分佈式系統數據的可靠性和最終一致性。
2. 深入理解ZAB協議，才能更好的理解zookeeper對於分佈式系統建設的重要性。以及爲何採用zookeeper就能保證分佈式系統中數據最終一致性，服務的高可用性。

 

 

這篇主要分析leader的選主機制，zookeeper提供了三種方式：

• LeaderElection
• AuthFastLeaderElection
• FastLeaderElection

默認的算法是FastLeaderElection，因此這篇主要分析它的選舉機制。

選擇機制中的概念

服務器ID

好比有三臺服務器，編號分別是1,2,3。

編號越大在選擇算法中的權重越大。

數據ID

服務器中存放的最大數據ID.

值越大說明數據越新，在選舉算法中數據越新權重越大。

邏輯時鐘

或者叫投票的次數，同一輪投票過程當中的邏輯時鐘值是相同的。每投完一次票這個數據就會增長，而後與接收到的其它服務器返回的投票信息中的數值相比，根據不一樣的值作出不一樣的判斷。

選舉狀態

• LOOKING，競選狀態。
• FOLLOWING，隨從狀態，同步leader狀態，參與投票。
• OBSERVING，觀察狀態,同步leader狀態，不參與投票。
• LEADING，領導者狀態。

選舉消息內容

在投票完成後，須要將投票信息發送給集羣中的全部服務器，它包含以下內容。

• 服務器ID
• 數據ID
• 邏輯時鐘
• 選舉狀態

選舉流程圖

由於每一個服務器都是獨立的，在啓動時均從初始狀態開始參與選舉，下面是簡易流程圖。

 

 

 

下面詳細解釋一下這個流程：

首先給出幾個名詞定義：

（1）Serverid：在配置server時，給定的服務器的標示id。

（2）Zxid:服務器在運行時產生的數據id，zxid越大，表示數據越新。

（3）Epoch：選舉的輪數，即邏輯時鐘。隨着選舉的輪數++

（4）Server狀態：LOOKING,FOLLOWING,OBSERVING,LEADING

 

 

步驟：

1、  Server剛啓動（宕機恢復或者剛啓動）準備加入集羣，此時讀取自身的zxid等信息。

2、  全部Server加入集羣時都會推薦本身爲leader，而後將（leader id 、 zixd 、 epoch）做爲廣播信息，廣播到集羣中全部的服務器(Server)。而後等待集羣中的服務器返回信息。

3、  收到集羣中其餘服務器返回的信息，此時要分爲兩類：該服務器處於looking狀態，或者其餘狀態。

（1）    服務器處於looking狀態

首先判斷邏輯時鐘 Epoch:

a)     若是接收到Epoch大於本身目前的邏輯時鐘（說明本身所保存的邏輯時鐘落伍了）。更新本機邏輯時鐘Epoch，同時 Clear其餘服務發送來的選舉數據（這些數據已經OUT了）。而後判斷是否須要更新當前本身的選舉狀況（一開始選擇的leader id 是本身）

    判斷規則rules judging：保存的zxid最大值和leader Serverid來進行判斷的。先看數據zxid,數據zxid大者勝出;其次再判斷leaderServerid, leader Serverid大者勝出；而後再將自身最新的選舉結果(也就是上面提到的三種數據（leader Serverid，Zxid，Epoch）廣播給其餘server)

b)     若是接收到的Epoch小於目前的邏輯時鐘。說明對方處於一個比較OUT的選舉輪數，這時只須要將本身的 （leader Serverid，Zxid，Epoch）發送給他便可。

c)     若是接收到的Epoch等於目前的邏輯時鐘。再根據a)中的判斷規則，將自身的最新選舉結果廣播給其餘 server。

 

同時Server還要處理2種狀況：

a)    若是Server接收到了其餘全部服務器的選舉信息，那麼則根據這些選舉信息肯定本身的狀態（Following,Leading），結束Looking，退出選舉。

b)   即便沒有收到全部服務器的選舉信息，也能夠判斷一下根據以上過程以後最新的選舉leader是否是獲得了超過半數以上服務器的支持，若是是則嘗試接受最新數據，假若沒有最新的數據到來，說明你們都已經默認了這個結果,一樣也設置角色退出選舉過程。

 

（2）    服務器處於其餘狀態（Following, Leading）

a)     若是邏輯時鐘Epoch相同,將該數據保存到recvset,若是所接收服務器宣稱本身是leader,那麼將判斷是否是有半數以上的服務器選舉它,若是是則設置選舉狀態退出選舉過程

b)     不然這是一條與當前邏輯時鐘不符合的消息，那麼說明在另外一個選舉過程當中已經有了選舉結果，因而將該選舉結果加入到outofelection集合中，再根據outofelection來判斷是否能夠結束選舉,若是能夠也是保存邏輯時鐘，設置選舉狀態，退出選舉過程。

以上就是FAST選舉過程。

 

 

 轉載至 https://blog.csdn.net/a724888/article/details/80757503 感受應該是全網最好的了。