本文主要講述Zookeeper的內部原理以及ZAB協議，Zookeeper算是大資料中的一個協作框架，比較簡單，本文應該是Zookeeper部分的最后一篇文章，關注專欄《破繭成蝶——大資料篇》，查看更多相關的內容~

目錄

一、Zookeeper的內部原理

1.1 節點型別

1.2 Stat結構體

1.3 監聽器

1.4 寫資料流程

1.5 Zookeeper的選舉機制

二、ZAB協議

2.1 ZAB協議是什么

2.2 ZAB協議的作用

2.3 ZAB協議的原理

2.4 ZAB協議的作業

2.4.1 訊息廣播

2.4.2 崩潰恢復

2.5 ZAB資料同步

一、Zookeeper的內部原理

1.1 節點型別

Zookeeper的節點型別可以分為兩種：持久型和短暫型，持久型指當客戶端與服務器斷開連接后，該節點不會洗掉；短暫型指當客戶端與服務器斷開連接后，該節點也會隨之洗掉，

1.2 Stat結構體

Stat結構體在《二十一、Zookeeper的命令列操作》中已經有提到過了，但是這里得再次不厭其煩的說一下，

（1）cZxid：創建節點的事務zxid，每次修改ZooKeeper狀態都會收到一個zxid形式的時間戳，也就是ZooKeeper事務ID，事務ID是ZooKeeper中所有修改總的次序，每個修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前發生，
（2）ctime：znode被創建的毫秒數(從1970年開始)，
（3）mZxid：znode最后更新的事務zxid，
（4）mtime：znode最后修改的毫秒數(從1970年開始)，
（5）pZxid：znode最后更新的子節點zxid，
（6）cversion：znode子節點變化號，znode子節點修改次數，
（7）dataVersion：znode資料變化號，
（8）aclVersion：znode訪問控制串列的變化號，
（9）ephemeralOwner：如果是臨時節點，這個是znode擁有者的session id，如果不是臨時節點則是0，
（10）dataLength：znode的資料長度，
（11）numChildren：znode子節點數量，

1.3 監聽器

1、首先在main()執行緒中創建Zookeeper客戶端，這時會同時創建兩個執行緒：一個用于網路連接通信（A），一個用于監聽（B），

2、通過A執行緒將注冊的監聽事件發送個Zookeeper，這時Zookeeper會將注冊的監聽事件添加到注冊監聽器串列，

3、Zookeeper監聽到有資料或者路徑等等的變化，就會將這個訊息發送給B執行緒，

1.4 寫資料流程

1、客戶端向Zookeeper的服務器上寫資料，首先會發送一個寫請求，

2、如果接收到該請求的服務器（A）不是Leader服務器，那么它會將這個請求轉發給Leader服務器，這時Leader服務器會將請求廣播給集群內的其他服務器，各個服務器會將寫請求加入待寫佇列，并向Leader服務器發送成功的資訊，

3、當Leader服務器收到半數以上的Follower服務器的成功資訊后，說明該寫操作可以執行，這是Leader會向各個Follower發送提交資訊，各個Follower收到資訊后，會落實佇列里面的寫請求，此時寫入成功，

4、服務器A通知客戶端資料寫入成功，

1.5 Zookeeper的選舉機制

選舉機制遵循半數機制，即：集群中半數以上機器存活，集群就是可用狀態，所以Zookeeper適合安裝奇數臺服務器，Zookeeper雖然在組態檔中并沒有指定Master和Slave，但是，Zookeeper作業時，是有一個節點為Leader，其他則為Follower，Leader是通過內部的選舉機制臨時產生的，例如有五臺服務器（A-E）組成的Zookeeper集群，同時它們都是最新啟動的，也就是沒有歷史資料，在存放資料量這一點上，都是一樣的，假設這些服務器依次啟動，那么會發生下面的情況：

1、服務器A啟動，發起一次選舉，服務器A投自己一票，此時服務器A票數一票，不夠半數以上（3票），選舉無法完成，服務器A狀態保持為LOOKING，

2、服務器B啟動，再發起一次選舉，服務器A和B分別投自己一票并交換選票資訊：此時服務器A發現服務器B的ID比自己目前投票推舉的（服務器A）大，更改選票為推舉服務器B，此時服務器A票數0票，服務器B票數2票，沒有半數以上結果，選舉無法完成，服務器A、B狀態保持LOOKING，

3、服務器C啟動，發起一次選舉，此時服務器A和B都會更改選票為服務器C，此次投票結果：服務器A為0票，服務器B為0票，服務器C為3票，此時服務器C的票數已經超過半數，服務器C當選Leader，服務器A、B更改狀態為FOLLOWING，服務器C更改狀態為LEADING，

4、服務器D啟動，發起一次選舉，此時服務器A、B、C已經不是LOOKING狀態，不會更改選票資訊，交換選票資訊結果：服務器C為3票，服務器D為1票，此時服務器D服從多數，更改選票資訊為服務器C，并更改狀態為FOLLOWING，

5、服務器E啟動，程序同4，

二、ZAB協議

2.1 ZAB協議是什么

ZAB協議的全稱是Zookeeper Atomic Broadcast（Zookeeper原子廣播），Zookeeper是通過ZAB協議來保證分布式事務的最終一致性，ZAB協議是為分布式協調服務Zookeeper專門設計的一種支持崩潰恢復的原子廣播協議，是Zookeeper保證資料一致性的核心演算法，ZAB借鑒了Paxos演算法，但又不像Paxos演算法那樣，是一種通用的分布式一致性演算法，它是特別為Zookeeper設計的支持崩潰恢復的原子廣播協議，

在Zookeeper中主要依賴ZAB協議來實作資料一致性，基于該協議，Zookeeper實作了一種主備模型（即Leader和Follower模型）的系統架構來保證集群中各個副本之間資料的一致性，這里的主備系統架構模型，就是指只有一臺客戶端（Leader）負責處理外部的寫事務請求，然后Leader客戶端將資料同步到其他Follower節點，Zookeeper客戶端會隨機的鏈接到Zookeeper集群中的一個節點，如果是讀請求，就直接從當前節點中讀取資料；如果是寫請求，那么節點就會向Leader提交事務，Leader接收到事務提交，會廣播該事務，只要超過半數節點寫入成功，該事務就會被提交，

ZAB協議的特性：

1、ZAB協議需要確保那些已經在Leader服務器上提交的事務最終被所有的服務器提交，

2、ZAB協議需要確保丟棄那些只在Leader上被提出而沒有被提交的事務，

2.2 ZAB協議的作用

1、當主行程出現例外的時候，整個Zookeeper集群依舊能夠正常作業，

2、使用一個Leader來接收并處理客戶端的事務請求，并采用ZAB的原子廣播協議，將服務器資料的狀態變更以事務proposal（事務提議）的形式廣播到所有的Follower行程上去，

3、保證一個全域的變更序列被順序參考，Zookeeper是一個樹形結構，很多操作都要先檢查才能確定是否可以執行，為了保證這一點，ZAB要保證同一個Leader發起的事務要按順序被請求，同時還要保證只有先前Leader的事務被請求之后，新選舉出來的Leader才能再次發起事務，

2.3 ZAB協議的原理

ZAB協議要求每個Leader都要經歷三個階段：發現、同步、廣播，

發現階段要求Zookeeper集群必須選舉出一個Leader，同時Leader會維護一個Follower可用客戶端串列，將來客戶端可以和這些Follower節點進行通信，同步階段Leader要負責將本身的資料與Follower完成同步，做到多副本存盤，Follower將佇列中未處理完的請求消費完成后，寫入本地事務日志中，廣播階段Leader可以接受客戶端新的事務Proposal請求，將新的Proposal請求廣播給所有的Follower，

ZAB協議定義了事務請求的處理方式：所有的事務請求必須由一個全域唯一的服務器來協調處理，這樣的服務器被叫做Leader服務器，其他剩余的服務器則是Follower服務器，Leader服務器負責將一個客戶端事務請求，轉換成一個事務Proposal，并將該Proposal分發給集群中所有的Follower服務器，也就是向所有 Follower節點發送資料廣播請求，分發之后Leader服務器需要等待所有Follower服務器的反饋，在ZAB協議中，只要超過半數的Follower服務器進行了正確的反饋后，那么Leader就會再次向所有的Follower服務器發送Commit訊息，要求其將上一個事務proposal進行提交，這也就是上文中1.4提到的寫資料流程，

2.4 ZAB協議的作業

當整個集群啟動程序中，或者當Leader服務器出現網路中弄斷、崩潰退出或重啟等例外時，ZAB協議就會進入崩潰恢復模式，選舉產生新的Leader，當選舉產生了新的Leader，同時集群中有過半的機器與該Leader服務器完成了狀態同步（即資料同步）之后，ZAB協議就會退出崩潰恢復模式，進入訊息廣播模式，這時，如果有一臺遵守ZAB協議的服務器加入集群，因為此時集群中已經存在一個Leader服務器在廣播訊息，那么該新加入的服務器自動進入恢復模式：找到Leader服務器，并且完成資料同步，同步完成后，作為新的Follower一起參與到訊息廣播流程中，

當Leader出現崩潰退出或者機器重啟，亦或是集群中不存在超過半數的服務器與Leader保存正常通信，ZAB協議就會再一次進入崩潰恢復，發起新一輪Leader選舉并實作資料同步，同步完成后又會進入訊息廣播模式，接收事務請求，在整個訊息廣播中，Leader會將每一個事務請求轉換成對應的proposal來進行廣播，并且在廣播事務Proposal之前，Leader服務器會首先為這個事務Proposal分配一個全域單遞增的唯一ID，稱之為事務ID（即zxid），由于ZAB協議需要保證每一個訊息的嚴格的順序關系，因此必須將每一個proposal按照其zxid的先后順序進行排序和處理，

2.4.1 訊息廣播

訊息廣播的步驟如下：

1、客戶端發起一個寫操作請求，

2、Leader服務器將客戶端的請求轉化為事務Proposal提案，同時為每個Proposal分配一個全域的ID，即zxid，

3、Leader服務器為每個Follower服務器分配一個單獨的佇列，然后將需要廣播的Proposal依次放到佇列中去，并且根據FIFO策略進行訊息發送，

4、Follower接收到Proposal后，會首先將其以事務日志的方式寫入本地磁盤中，寫入成功后向Leader反饋一個Ack回應訊息，

5、Leader接收到超過半數以上Follower的Ack回應訊息后，即認為訊息發送成功，可以發送commit訊息，

6、Leader向所有Follower廣播commit訊息，同時自身也會完成事務提交，Follower接收到commit訊息后，會將上一條事務提交，

Zookeeper采用ZAB協議的核心，就是只要有一臺服務器提交了Proposal，就要確保所有的服務器最終都能正確提交Proposal，Leader服務器與每一個Follower服務器之間都維護了一個單獨的FIFO訊息佇列進行收發訊息，使用佇列訊息可以做到異步解耦，Leader和Follower之間只需要往佇列中發訊息即可，如果使用同步的方式會引起阻塞，性能要下降很多，

2.4.2 崩潰恢復

一旦Leader服務器出現崩潰或者由于網路原因導致Leader服務器失去了與過半Follower的聯系，那么就會進入崩潰恢復模式，在ZAB協議中，為了保證程式的正確運行，整個恢復程序結束后需要選舉出一個新的Leader服務器，

ZAB協議崩潰恢復要求滿足兩個要求：1、確保已經被Leader提交的Proposal必須最終被所有的Follower服務器提交，2、確保丟棄已經被Leader提出的但是沒有被提交的Proposal，根據上述要求ZAB協議需要保證選舉出來的Leader滿足以下條件：1、新選舉出來的Leader不能包含未提交的Proposal，即新選舉的Leader必須都是已經提交了Proposal的Follower服務器節點，2、新選舉的Leader節點中含有最大的zxid，

2.5 ZAB資料同步

1、完成Leader選舉后新的Leader具有最高的zxid，在正式開始作業之前（接收事務請求，然后提出新的Proposal），Leader服務器會首先確認事務日志中的所有的Proposal是否已經被集群中過半的服務器Commit，

2、Leader服務器需要確保所有的Follower服務器能夠接收到每一條事務的Proposal，并且能將所有已經提交的事務Proposal應用到記憶體資料中，等到Follower將所有尚未同步的事務Proposal都從Leader服務器上同步過來并且應用到記憶體資料中以后，Leader才會把該Follower加入到真正可用的Follower串列中，

在ZAB的事務編號zxid設計中，zxid是一個64位的數字，其中低32位可以看成一個簡單的單增計數器，針對客戶端每一個事務請求，Leader在產生新的Proposal事務時，都會對該計數器加1，而高32位則代表了Leader周期的epoch編號，epoch編號可以理解為當前集群所處的年代或者周期，每次Leader變更之后都會在epoch的基礎上加1，這樣舊的Leader崩潰恢復之后，其他Follower也不會聽它的，因為Follower只服從epoch最高的Leader命令，每當選舉產生一個新的Leader，就會從這個Leader服務器上取出本地事務日志中最大編號Proposal的zxid，并從zxid中決議得到對應的epoch編號，然后再對其加1，之后該編號就作為新的epoch值，并將低32位數字歸零，由0開始重新生成zxid，ZAB協議通過epoch編號來區分Leader變化周期，能夠有效避免不同的Leader錯誤的使用了相同的zxid編號提出了不一樣的Proposal的例外情況，基于以上策略當一個包含了上一個Leader周期中尚未提交過的事務Proposal的服務器啟動時，當這臺機器加入集群中，以Follower角色連上Leader服務器后，Leader服務器會根據自己服務器上最后提交的Proposal來和Follower服務器的Proposal進行比對，比對的結果肯定是Leader要求Follower進行一個回退操作，回退到一個確實已經被集群中過半機器Commit的最新Proposal，

到這本文基本上接近尾聲了，這篇文章理論描述居多，可能會比較枯燥，你們有什么問題，歡迎留言，讓我看看你們都有哪些問題~