ZAB協議的原理是什么

今天就跟大家聊聊有關ZAB協議的原理是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

ZAB協議是為分布式協調服務Zookeeper專門設計的一種支持崩潰恢復的原子廣播協議。在Zookeeper中，主要依賴ZAB協議來實現分布式數據一致性。

ZAB協議內容

ZAB協議主要有兩種模式：崩潰恢復和消息廣播。

當服務器啟動、或者Leader宕機、或者Leader與絕大多數Follower無法正常通信時，ZAB協議就會進入崩潰恢復模式用來產生新的Leader。

當選舉產生新的Leader并且完成數據同步以后，ZAB協議將由崩潰恢復模式轉變為消息廣播模式。

在ZAB協議的設計中，每一個進程都可能處于下面三種狀態中的一種：

• LOOKING：Leader選舉階段

• FOLLOWING：Follower服務器和Leader保持同步狀態

• LEADING：Leader服務器作為主進程領導狀態

ZAB協議需要保證以下兩條原則：

• 確保那些已經在Leader服務器上提交的事務最終被所有的服務器進行提交(在Leader上提交，說明絕大多數Follower已經接收到了事務的Proposal請求并返回了ACK響應，只是還未收到commit請求)

• 確保丟棄那些只在Leader服務器上被提出的事務(只在Leader上被提出說明沒有其他Follower并沒有收到Proposal請求)

消息廣播

消息廣播模式是在整個集群穩定運行時的模式。它的操作類似于兩階段提交。

在消息的廣播過程中，Leader會為每一個Follower準備一個事務隊列，該隊列符合FIFO原則。假設Follower接收到了客戶端的寫請求，寫請求會被轉發至Leader處理，當Leader收到客戶端的寫請求時，主要有以下步驟：

1. 為寫請求的事務Proposal分配一個全局唯一遞增的ID(ZXID)

2. 將這個事務放入每個Follower對應的事務隊列，并按照FIFO順序進行廣播

3. Follower接收到事務請求后，將該事務請求寫入本地事務日志文件，并在寫成功后給Leader返回ACK響應

4. 當Leader收到過半的Follower返回的ACK，便向所有的Follower發送commit請求通知Follower執行事務提交，同時Leader自身也完成事務提交

5. Follower收到commit請求后，完成事務提交

Leader為每個Follower使用隊列做了異步解耦，大大降低同步阻塞，提高了系統的吞吐量。

崩潰恢復

崩潰恢復主要用來當Leader宕機或者Leader與大多數Follower因為網絡原因無法通信時進行新Leader的選舉或者集群啟動時進行Leader的選舉。崩潰恢復主要由兩個過程組成：Leader選舉、數據同步。

Leader選舉

保證上述原則實現Leader很簡單，只要保證新選出來的Leader服務器擁有最大的ZXID就可以，那么這個新Leader一定具有所有已提交的事務，還可以省去檢查Proposal的提交和丟棄工作。

首先確認一個點，每個Zookeeper節點進入LOOKING狀態時，都會發起選舉流程，其他的Zookeeper機器收到該請求時，只有兩種響應：

• 接收選票提議，同意Zookeeper節點成為Leader候選人

• 否決選票提議，并推薦自己上一次推薦的服務器作為Leader候選人

其次我們來講述一下ZXID這個概念，ZXID其實就是一個全局單調遞增的唯一的事務ID，由高32位的epoch表示選舉周期和低32位的自增事務ID組成，每經歷一次選舉產生新的Leader，epoch的值將加1，而且低32位的的ID將被置為0，重新從0開始自增。

下面簡單描述一下準Leader選舉的過程，后面會出一篇源碼分析來詳解Leader的選舉：

1. 首先參與Leader選舉的服務器必須是狀態位LOOKING狀態的節點

2. Zookeeper節點向其他的服務器節點發送自己要成為Leader候選人的請求(請求包含ZXID)

3. 其他節點收到請求后，將本地事務日志的ZXID與請求中ZXID進行比較，如果發現比自己的大(如果ZXID一樣大就比較myid(這個后面講))，就同意該節點成為候選人并更新 該節點為推薦候選人而不是自己然后通知其他的節點，否則還是將自己作為候選人推薦

4. 每次投票都會進行統計，判斷是否有過半的服務器收到的推薦候選人是一致的，如果過半就認為已經選出了準Leader

5. 一旦選舉完成，就需要改變服務狀態，新的Leader置為LEADING狀態，其他機器轉變為FOLLOWING狀態

數據同步

只有當集群中的過半及其完成了數據同步，準Leader就可以真正的成為Leader。Follower只會接收ZXID比自己的最后一次事務的ZXID大的提議。

1. 所有的Follower向準Leader發送自己的最后接收事務的epoch

2. 準Leader選出最大的epoch，并在此基礎上進行加1，然后將新的epoch發送給所有的Follower

3. Follower收到新的epoch之后，與自己的進行比較，小于就將自己的epoch更新成新的epoch，并向準Leader反饋ACK信息(epoch、歷史事務集合)

4. 準Leader收到ACK消息后，會在所有歷史事務集合中選出其中一個歷史事務集合作為初始化歷史事務集合，該事務集合必須滿足最大ZXID

5. 準Leader將epoch和初始化歷史事務集合發送給過半的Follower，每個Follower分配一個事務隊列然后逐條將事務發送給Follower

6. Follower接收到事務請求后，如果已執行過則跳過，未執行則執行事務并反饋響應給準Leader

7. 準Leader收到響應后則發起事務commit請求，提交事務

8. 數據完成同步后，準Leader就是Leader，ZAB協議由崩潰恢復模式進入消息廣播模式

ZAB和Paxos區別

本質區別在于設計的目的不一樣，ZAB協議主要使用來構建一個高可用的分布式數據主備系統，Paxos算法主要是用來解決數據一致性。

看完上述內容，你們對ZAB協議的原理是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。