轉(zhuǎn)載自??Zookeeper一致性協(xié)議原理Zab

ZooKeeper為高可用的一致性協(xié)調(diào)框架，自然的ZooKeeper也有著一致性算法的實(shí)現(xiàn)，ZooKeeper使用的是ZAB協(xié)議作為數(shù)據(jù)一致性的算法， ZAB（ZooKeeper Atomic Broadcast ） 全稱(chēng)為：原子消息廣播協(xié)議；

ZAB可以說(shuō)是在Paxos算法基礎(chǔ)上進(jìn)行了擴(kuò)展改造而來(lái)的，ZAB協(xié)議設(shè)計(jì)了支持崩潰恢復(fù)，ZooKeeper使用單一主進(jìn)程Leader用于處理客戶(hù)端所有事務(wù)請(qǐng)求，采用ZAB協(xié)議將服務(wù)器數(shù)狀態(tài)以事務(wù)形式廣播到所有Follower上；

由于事務(wù)間可能存在著依賴(lài)關(guān)系，ZAB協(xié)議保證Leader廣播的變更序列被順序的處理，：一個(gè)狀態(tài)被處理那么它所依賴(lài)的狀態(tài)也已經(jīng)提前被處理；

ZAB協(xié)議支持的崩潰恢復(fù)可以保證在Leader進(jìn)程崩潰的時(shí)候可以重新選出Leader并且保證數(shù)據(jù)的完整性;

在ZooKeeper中所有的事務(wù)請(qǐng)求都由一個(gè)主服務(wù)器也就是Leader來(lái)處理，其他服務(wù)器為Follower，Leader將客戶(hù)端的事務(wù)請(qǐng)求轉(zhuǎn)換為事務(wù)Proposal，并且將Proposal分發(fā)給集群中其他所有的Follower，然后Leader等待Follwer反饋，當(dāng)有 過(guò)半數(shù)（>=N/2+1） 的Follower反饋信息后，Leader將再次向集群內(nèi)Follower廣播Commit信息，Commit為將之前的Proposal提交;

ZooKeeper從以下幾點(diǎn)保證了數(shù)據(jù)的一致性

① 順序一致性

來(lái)自任意特定客戶(hù)端的更新都會(huì)按其發(fā)送順序被提交。也就是說(shuō)，如果一個(gè)客戶(hù)端將Znode z的值更新為a，在之后的操作中，它又將z的值更新為b，則沒(méi)有客戶(hù)端能夠在看到z的值是b之后再看到值a（如果沒(méi)有其他對(duì)z的更新）。

② 原子性

每個(gè)更新要么成功，要么失敗。這意味著如果一個(gè)更新失敗，則不會(huì)有客戶(hù)端會(huì)看到這個(gè)更新的結(jié)果。

③ 單一系統(tǒng)映像

一個(gè)客戶(hù)端無(wú)論連接到哪一臺(tái)服務(wù)器，它看到的都是同樣的系統(tǒng)視圖。這意味著，如果一個(gè)客戶(hù)端在同一個(gè)會(huì)話(huà)中連接到一臺(tái)新的服務(wù)器，它所看到的系統(tǒng)狀態(tài)不會(huì)比在之前服務(wù)器上所看到的更老。當(dāng)一臺(tái)服務(wù)器出現(xiàn)故障，導(dǎo)致它的一個(gè)客戶(hù)端需要嘗試連接集合體中其他的服務(wù)器時(shí)，所有滯后于故障服務(wù)器的服務(wù)器都不會(huì)接受該連接請(qǐng)求，除非這些服務(wù)器趕上故障服務(wù)器。

④ 持久性

一個(gè)更新一旦成功，其結(jié)果就會(huì)持久存在并且不會(huì)被撤銷(xiāo)。這表明更新不會(huì)受到服務(wù)器故障的影響。

==========================================================================

ZAB協(xié)議的兩個(gè)基本模式：恢復(fù)模式和廣播模式

恢復(fù)模式:（選舉）
當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù)server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和server具有相同的系統(tǒng)狀態(tài)。

具體選舉看下面文章

http://www.jasongj.com/zookeeper/fastleaderelection/

崩潰恢復(fù)過(guò)程中，為了保證數(shù)據(jù)一致性需要處理特殊情況：
1、已經(jīng)被leader提交的proposal確保最終被所有的服務(wù)器follower提交
2、確保那些只在leader被提出的proposal被丟棄
針對(duì)這個(gè)要求,如果讓leader選舉算法能夠保證新選舉出來(lái)的Leader服務(wù)器擁有集群中所有機(jī)器最高的ZXID事務(wù)proposal，就可以保證這個(gè)新選舉出來(lái)的Leader一定具有所有已經(jīng)提交的提案，也可以省去Leader服務(wù)器檢查proposal的提交與丟棄的工作。

?

廣播模式：（數(shù)據(jù)同步）
一旦Leader已經(jīng)和多數(shù)的Follower進(jìn)行了狀態(tài)同步后，他就可以開(kāi)始廣播消息了，即進(jìn)入廣播狀態(tài)。
這時(shí)候當(dāng)一個(gè)Server加入ZooKeeper服務(wù)中，它會(huì)在恢復(fù)模式下啟動(dòng)，發(fā)現(xiàn)Leader，并和Leader進(jìn)行狀態(tài)同步。待到同步結(jié)束，它也參與消息廣播。
ZooKeeper服務(wù)一直維持在廣播狀態(tài)，直到Leader崩潰了或者Leader失去了大部分的Followers支持。
廣播模式極其類(lèi)似于分布式事務(wù)中的2pc（two-phrase commit 兩階段提交）：即Leader提起一個(gè)決議，由Followers進(jìn)行投票，Leader對(duì)投票結(jié)果進(jìn)行計(jì)算決定是否通過(guò)該決議，如果通過(guò)執(zhí)行該決議（事務(wù)），否則什么也不做。

廣播協(xié)議在所有的通訊過(guò)程中使用TCP的FIFO信道，通過(guò)使用該信道，使保持有序性變得非常的容易。通過(guò)FIFO信道，消息被有序的deliver。只要收到的消息一被處理，其順序就會(huì)被保存下來(lái)。 Leader會(huì)廣播已經(jīng)被deliver的Proposal消息。在發(fā)出一個(gè)Proposal消息前，Leader會(huì)分配給Proposal一個(gè)單調(diào)遞增的唯一id，稱(chēng)之為zxid。 廣播是把Proposal封裝到消息當(dāng)中，并添加到指向Follower的輸出隊(duì)列中，通過(guò)FIFO信道發(fā)送到Follower。 當(dāng)Follower收到一個(gè)Proposal時(shí)，會(huì)將其寫(xiě)入到磁盤(pán)，可以的話(huà)進(jìn)行批量寫(xiě)入。一旦被寫(xiě)入到磁盤(pán)媒介當(dāng)中，Follower就會(huì)發(fā)送一個(gè)ACK給Leader。 當(dāng)Leader收到了指定數(shù)量的ACK時(shí)，Leader將廣播commit消息并在本地遞交該消息。當(dāng)收到Leader發(fā)來(lái)commit消息時(shí)，Follower也會(huì)遞交該消息。

ZAB協(xié)議簡(jiǎn)化了2PC事務(wù)提交：
1、去除中斷邏輯移除，follower要么ack，要么拋棄Leader；
2、leader不需要所有的Follower都響應(yīng)成功，只要一個(gè)多數(shù)派ACK即可。

?

丟棄的事務(wù)proposal處理過(guò)程：

ZAB協(xié)議中使用ZXID作為事務(wù)編號(hào)，ZXID為64位數(shù)字，低32位為一個(gè)遞增的計(jì)數(shù)器，每一個(gè)客戶(hù)端的一個(gè)事務(wù)請(qǐng)求時(shí)Leader產(chǎn)生新的事務(wù)后該計(jì)數(shù)器都會(huì)加1， 高32位為L(zhǎng)eader周期epoch編號(hào)，當(dāng)新選舉出一個(gè)Leader節(jié)點(diǎn)時(shí)Leader會(huì)取出本地日志中最大事務(wù)Proposal的ZXID解析出對(duì)應(yīng)的epoch把該值加1作為新的epoch，將低32位從0開(kāi)始生成新的ZXID； ZAB使用epoch來(lái)區(qū)分不同的Leader周期，能有效避免了不同的leader服務(wù)器錯(cuò)誤的使用相同的ZXID編號(hào)提出不同的事務(wù)proposal的異常情況，大大簡(jiǎn)化了提升了數(shù)據(jù)恢復(fù)流程； 所以這個(gè)崩潰的機(jī)器啟動(dòng)時(shí)，也無(wú)法成為新一輪的Leader，因?yàn)楫?dāng)前集群中的機(jī)器一定包含了更高的epoch的事務(wù)proposal。

參考：

https://www.cnblogs.com/sunddenly/p/4138580.html

http://cailin.iteye.com/blog/2014486/

http://www.jasongj.com/zookeeper/fastleaderelection/

http://www.cnblogs.com/ASPNET2008/p/6421571.html

https://zhuanlan.zhihu.com/p/25594630

http://sunxing.cc/2016/06/14/zookeeper-study001/

http://www.jasongj.com/zookeeper/fastleaderelection/

http://www.jasongj.com/zookeeper/distributedlock/

總結(jié)

以上是生活随笔為你收集整理的Zookeeper一致性协议原理Zab的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。