Zookeeper一致性協議Zab如何理解

這篇文章給大家介紹Zookeeper一致性協議Zab如何理解，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

zookeeper是分布式協調系統，用來協調、同步多服務器之間的狀態，容錯能力強

一個應用要保證HA，往往需要N個服務器（N>1)提供服務，其中有M臺master，N-M臺slave。這樣一臺掛了，另外N-1臺也能提供服務。所以，數據也會備份成N份散布在這些服務器上。現在的問題變成了，如何管理這N臺服務器？如何在master節點失敗的時候重新選擇master？如何保證所有服務器存儲的備份數據一致？

如果你碰到上面那些棘手的問題，zookeeper剛好可以幫到你：

• 存儲公共配置信息

• 跟蹤所有進程運行狀態

• 集群中各節點的管理

• master選主

• 提供分布式同步支持（分布式鎖等功能）

上面列出的是官方提供的功能支持，還有很多其他功能等待挖掘。

當你的系統依賴zookeeper保證HA和一致性的時候，你肯定也好奇，zookeeper本身是如何保證這兩個特性的。幕后功臣往往容易被忽視，其實它就是Zookeeper原子廣播協議（Zab協議）。如果你了解過二階段提交、paxos算法、raft算法等大名鼎鼎的分布式一致性算法，Zab肯定也不會陌生，因為他們要達到的目的相同，就是保證應用程序的HA和一致性。

為了讀懂后面的內容，有些術語需要了解：

Zab的理論和實現并不完全一致。

實現是在理論的基礎之上做了一些優化手段，這些優化是在zookeeper不斷發展的過程中給加上的。我接下來的講解，也是參照這篇論文，以zookeeper 3.3.3的版本的實現為準，并用自己的語言總結。

隨著系統啟動或者恢復，會經歷Zab協議中描述的如下四個階段

• 階段0：Leader選舉。每個peer從Quorum peer中選出自己心中的預備leader

• 階段1：發現。預備leader從Quorum Follower中發現最新的數據，并覆蓋自己的過期數據

• 階段2：同步。預備leader采用二階段提交的方式將自己的最新數據同步給Quorum Follower。完成這個步驟，預備leader就轉為正式leader

• 階段3：廣播。Leader接受寫請求，并通過二階段提交的方式廣播給Quorum Follower

之前我只是簡述了一下理論中的協議，然而理想很骨感，有很多需要改進或者妥協的地方。下面我會一一闡明：

• 階段0的選舉leader實際上很簡陋，只是“看對眼”了就選為預備leader，所以預備leader的數據可能并非最新

• 預備leader數據過期，就需要用階段1來彌補，通過互相傳輸數據，來發現最新的數據，并完成預備leader的數據升級

• 更多的網絡間數據傳輸代表了更大的網絡開銷

了解了理想的骨感之后，我們回歸現實。

真正apache zookeeper在實現上提出設想：優化leader選舉，直接選出最新的Peer作為預備Leader，這樣就能將階段0和階段1合并，減少網絡上的開銷和多流程的復雜性

由圖可知，代碼實現上，協議被簡化為三個階段

• 快速選舉Leader階段：從Quorum Peer中選出數據最新的peer作為leader

• 恢復階段：Leader將數據同步給Quorum Follower

• 廣播階段：Leader接受寫請求，并廣播給Quorum Follower

Talk is cheap.Show me the Code

這時Linus說過的一句話，無論語言多么有力，只有代碼才能真正展現作者的思想。之前我只是對是協議實現的三個階段做了一番簡述，只有代碼才能真正撥開Zab協議外面那層迷霧。（為了不浪費篇幅，這里采用偽代碼）

首先初始化一些數據

• ReceivedVotes：投票箱，存儲投票節點以及當前投票信息

• OutOfElection：存儲已經成為Leader、Follower，不參與投票的節點信息，以及它的歷史投票信息

• 在選票中寫上自己的大名

• send notification：發起選票通知，該節點會攜帶選票，進入目標節點的隊列中，相當于給自己投了一票，并毛遂自薦給其他人

如果當前節點處于選舉狀態，則它也會接到選票通知。它會從隊列中不斷輪詢節點，以便獲取選票信息（如果超時，則不斷放松超時時間，直至上限）。根據輪詢出來的發送節點的狀態，來做相應的處理。

• election：如果發送節點的輪次（round）大于自己，說明自己的選舉信息過時，則更新自己的選舉輪次，清空投票箱，更新自己的選票內容，并將新的選票通知給其他節點；如果發送節點的輪次等于自己，并且投票內容比自己的更新，則只需要更新自己的選票，并通知給其他節點就行；如果發送節點的輪次小于自己，說明投票內容過期，沒有參考意義，直接忽略。所有未被忽略的選票，都會進入投票箱。最終根據選票箱中的結果，判斷當前節點的選票是不是占大多數，如果是就根據當前節點的選票選出Leader

• leading或following：發送節點輪次等于自己，說明發送節點還參與投票，如果發送節點是Leading或者它的選票在選票箱中占大多數，則直接完成選舉；如果發送節點已經完成選舉（輪次不同）或者它收集的選票較少，那么它的信息都會存放在OutOfElection中。當節點不斷完成選舉，OutOfElection中數量逐漸變成Quorum時，就把OutOfElection當做投票箱，從中檢查發送節點的選票是否占多數，如果是就直接選出Leader

經過FLE，已經選出了日志中具有最新已提交的事務的節點作為預備Leader。下面就分Leader和Follower兩個視角來介紹具體實現。

首先，更新lastZxid，將紀元+1，計數清零，宣布改朝換代啦。然后在每次接收到Follower的數據同步請求時，都會將自己lastZxid反饋回去，表示所有Follower以自己的lastZxid為準。接下來，根據具體情況來判斷該如何將數據同步給Follower

• 如果Leader的歷史提交事務比Follower的最新事務要新，說明Follower的數據有待更新。更新方式取決于，Leader最早事務有沒有比Follower最新事務要新：如果前者更新，說明在Leader看來Follower所有記錄的事務都太過陳舊，沒有保留價值，這時只需要將Leader所有history發給Follower就行（響應SNAP）；如果后者更新，說明在Leader看來，Follower從自己的lastZxid開始到Leader日志的最新事務，都需要同步，于是將這一部分截取并發送給Follower（響應DIFF）

• 如果Leader的歷史提交事務沒有Follower的最新事務新，說明Follower存在沒有提交的事務，這些事務都應該被丟棄（響應TRUNC）

當Follower完成同步時，會發送同步ack，當Leader收到Quorum ack時，表示數據同步階段大功告成，進入最后的廣播階段。

通知Leader，表示自己希望能同步Leader中的數據。

• 當收到Leader的拒絕響應時，說明Leader不承認自己作為Follower，有可能該Leader并不可靠，于是開始重新開始FLE

• 當收到SNAP或DIFF響應時，Follower會同步Leader發送過來的事務

• 當收到TRUNC響應，Follower會丟棄所有未完成的數據

當每個Follower完成上述的同步過程時，會發送ack給Leader，并進入廣播階段。

進入到這個階段，說明所有數據完成同步，Leader已經轉正。開始zookeper最常見的工作流程：廣播。

廣播階段是真正接受事務請求（寫請求）的階段，也代表了zookeeper正常工作階段。所有節點都能接受客戶端的寫請求，但是Follower會轉發給Leader，只有Leader才能將這些請求轉化成事務，廣播出去。這個節點一樣有兩個角色，下面還是按照這兩個角色來講解。

Leader視角：

• Leader必須經過ready，才能接受寫請求。完成ready的Leader不斷接受寫請求，轉化成事務請求，廣播給Quorum Follower。

• 當Leader接收到ack時，說明Follower完成相應處理，Leader廣播提交請求，Follower完成提交。

• 當發現新Peer請求作為Follower加入時，將自己的紀元、事務日志發送給該Peer，以便它完成上述恢復階段的過程。收到該Peer的同步完成的ack時，Leader會發送提交請求，以便Peer提交所有同步完成的事務。這時，該Peer轉正為Follower，被Leader納入Quorum Follower中。

Follower視角：

• Follower被發現是Leading狀態，則執行ready過程，用來接受寫請求。

• 當接受到Leader廣播過來的事務請求時，Follower會將事務記錄在history，并響應ack。

• 當接收到Leader廣播過來的提交請求時，Follower會檢查history中有沒有尚未提交的事務，如果有，需要等待之前的事務按照FIFO順序提交之后，才能提交本事務。

文章沒有介紹Zookeeper的使用，而是著重講解它的核心協議Zab的實現。正如文中提及，Zab最早的設想和現在的實現并不相同，今日的實現是在Zookeeper不斷發展壯大的過程中不斷優化、改進而來的，也許早期的實現就是yahoo論文中構想的那樣。羅馬不是一日建成，任何人都不能指望一口吃個大胖子。如果Zookeeper剛開始就想著如何優化到極致，那反而會嚴重影響到這個項目本身的價值，因為它很可能還沒面試就被淘汰。

可以看出，過早優化是萬惡之源。但是同時，一個好的程序員也不會忘記需要優化的那部分，他會定位相應的代碼，然后針對性的修改。這也是zookeeper的開發者所做的。

關于Zookeeper一致性協議Zab如何理解就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。