Zookeeper講解（三）

Hello小夥伴們你們好~本兔君又來鳥~~今天要接着爲你們介紹Zookeeper呢，有沒有很期待喲！下面切入正題！

通常企業級架構的Zookeeper都是採用一主多從的架構，主節點負責寫和讀而從節點負責讀取，在更新數據時，首先更新到主節點（這裏的節點是指服務器，不是Znode），再同步到從節點。在讀取數據時，直接讀取任意從節點。那麼如何保證主從節點數據的一致性呢？Zookeeper採用了ZAB協議，這種協議很是相似於一致性算法Paxos和Raft。

在學習ZAB以前，咱們須要首先了解ZAB協議所定義的三種節點狀態：

Looking ：選舉狀態。

Following ：Follower節點（從節點）所處的狀態。

Leading ：Leader節點（主節點）所處狀態。

最大ZXID又是啥呢？

最大ZXID也就是節點本地的最新事務編號，包含epoch和計數兩部分。epoch是紀元的意思，至關於Raft算法選主時候的term。假如Zookeeper當前的主節點掛掉了，集羣會進行崩潰恢復。ZAB的崩潰恢復分紅三個階段：下面一一爲你們介紹一波~

1

選舉階段

1.Leader election

選舉階段，此時集羣中的節點處於Looking狀態。它們會各自向其餘節點發起投票，投票當中包含本身的服務器ID和最新事務ID（ZXID）。

接下來，節點會用自身的ZXID和從其餘節點接收到的ZXID作比較，若是發現別人家的ZXID比本身大，也就是數據比本身新，那麼就從新發起投票，投票給目前已知最大的ZXID所屬節點。

每次投票後，服務器都會統計投票數量，判斷是否有某個節點獲得半數以上的投票。若是存在這樣的節點，該節點將會成爲準Leader，狀態變爲Leading。其餘節點的狀態變爲Following。

2.Discovery

發現階段，用於在從節點中發現最新的ZXID和事務日誌。或許有人會問：既然Leader被選爲主節點，已是集羣裏數據最新的了，爲何還要從節點中尋找最新事務呢？這是爲了防止某些意外狀況，好比因網絡緣由在上一階段產生多個Leader的狀況。因此這一階段，Leader集思廣益，接收全部Follower發來各自的最新epoch值。Leader從中選出最大的epoch，基於此值加1，生成新的epoch分發給各個Follower。各個Follower收到全新的epoch後，返回ACK給Leader，帶上各自最大的ZXID和歷史事務日誌。Leader選出最大的ZXID，並更新自身歷史日誌。

3.Synchronization

同步階段，把Leader剛纔收集獲得的最新歷史事務日誌，同步給集羣中全部的Follower。只有當半數Follower同步成功，這個準Leader才能成爲正式的Leader。自此，故障恢復正式完成。

2

ZAB實現寫入數據

什麼是Broadcast呢？簡單來講，就是Zookeeper常規狀況下更新數據的時候，由Leader廣播到全部的Follower。其過程以下：

1.客戶端發出寫入數據請求給任意Follower。

2.Follower把寫入數據請求轉發給Leader。

3.Leader採用二階段提交方式，先發送Propose廣播給Follower。

4.Follower接到Propose消息，寫入日誌成功後，返回ACK消息給Leader。

5.Leader接到半數以上ACK消息，返回成功給客戶端，而且廣播Commit請求給Follower。

今天的分享就到這裏啦，本兔兔是否是講的很明白呀，小夥們感受清晰易懂別忘了關注+在看哦，想打個賞我也不攔着~~

本文分享自微信公衆號 - 萌兔it（mengtu_it）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。