Zookeeper一致性协议原理Zab
轉(zhuǎn)載自??Zookeeper一致性協(xié)議原理Zab
ZooKeeper為高可用的一致性協(xié)調(diào)框架,自然的ZooKeeper也有著一致性算法的實(shí)現(xiàn),ZooKeeper使用的是ZAB協(xié)議作為數(shù)據(jù)一致性的算法, ZAB(ZooKeeper Atomic Broadcast ) 全稱為:原子消息廣播協(xié)議;
ZAB可以說是在Paxos算法基礎(chǔ)上進(jìn)行了擴(kuò)展改造而來的,ZAB協(xié)議設(shè)計(jì)了支持崩潰恢復(fù),ZooKeeper使用單一主進(jìn)程Leader用于處理客戶端所有事務(wù)請求,采用ZAB協(xié)議將服務(wù)器數(shù)狀態(tài)以事務(wù)形式廣播到所有Follower上;
由于事務(wù)間可能存在著依賴關(guān)系,ZAB協(xié)議保證Leader廣播的變更序列被順序的處理,:一個(gè)狀態(tài)被處理那么它所依賴的狀態(tài)也已經(jīng)提前被處理;
ZAB協(xié)議支持的崩潰恢復(fù)可以保證在Leader進(jìn)程崩潰的時(shí)候可以重新選出Leader并且保證數(shù)據(jù)的完整性;
在ZooKeeper中所有的事務(wù)請求都由一個(gè)主服務(wù)器也就是Leader來處理,其他服務(wù)器為Follower,Leader將客戶端的事務(wù)請求轉(zhuǎn)換為事務(wù)Proposal,并且將Proposal分發(fā)給集群中其他所有的Follower,然后Leader等待Follwer反饋,當(dāng)有 過半數(shù)(>=N/2+1) 的Follower反饋信息后,Leader將再次向集群內(nèi)Follower廣播Commit信息,Commit為將之前的Proposal提交;
ZooKeeper從以下幾點(diǎn)保證了數(shù)據(jù)的一致性
① 順序一致性
來自任意特定客戶端的更新都會(huì)按其發(fā)送順序被提交。也就是說,如果一個(gè)客戶端將Znode z的值更新為a,在之后的操作中,它又將z的值更新為b,則沒有客戶端能夠在看到z的值是b之后再看到值a(如果沒有其他對z的更新)。
② 原子性
每個(gè)更新要么成功,要么失敗。這意味著如果一個(gè)更新失敗,則不會(huì)有客戶端會(huì)看到這個(gè)更新的結(jié)果。
③ 單一系統(tǒng)映像
一個(gè)客戶端無論連接到哪一臺(tái)服務(wù)器,它看到的都是同樣的系統(tǒng)視圖。這意味著,如果一個(gè)客戶端在同一個(gè)會(huì)話中連接到一臺(tái)新的服務(wù)器,它所看到的系統(tǒng)狀態(tài)不會(huì)比在之前服務(wù)器上所看到的更老。當(dāng)一臺(tái)服務(wù)器出現(xiàn)故障,導(dǎo)致它的一個(gè)客戶端需要嘗試連接集合體中其他的服務(wù)器時(shí),所有滯后于故障服務(wù)器的服務(wù)器都不會(huì)接受該連接請求,除非這些服務(wù)器趕上故障服務(wù)器。
④ 持久性
一個(gè)更新一旦成功,其結(jié)果就會(huì)持久存在并且不會(huì)被撤銷。這表明更新不會(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)者被選舉出來,且大多數(shù)server完成了和leader的狀態(tài)同步以后,恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和server具有相同的系統(tǒng)狀態(tài)。
具體選舉看下面文章
http://www.jasongj.com/zookeeper/fastleaderelection/
崩潰恢復(fù)過程中,為了保證數(shù)據(jù)一致性需要處理特殊情況:
1、已經(jīng)被leader提交的proposal確保最終被所有的服務(wù)器follower提交
2、確保那些只在leader被提出的proposal被丟棄
針對這個(gè)要求,如果讓leader選舉算法能夠保證新選舉出來的Leader服務(wù)器擁有集群中所有機(jī)器最高的ZXID事務(wù)proposal,就可以保證這個(gè)新選舉出來的Leader一定具有所有已經(jīng)提交的提案,也可以省去Leader服務(wù)器檢查proposal的提交與丟棄的工作。
?
廣播模式:(數(shù)據(jù)同步)
一旦Leader已經(jīng)和多數(shù)的Follower進(jìn)行了狀態(tà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支持。
廣播模式極其類似于分布式事務(wù)中的2pc(two-phrase commit 兩階段提交):即Leader提起一個(gè)決議,由Followers進(jìn)行投票,Leader對投票結(jié)果進(jìn)行計(jì)算決定是否通過該決議,如果通過執(zhí)行該決議(事務(wù)),否則什么也不做。
ZAB協(xié)議簡化了2PC事務(wù)提交:
1、去除中斷邏輯移除,follower要么ack,要么拋棄Leader;
2、leader不需要所有的Follower都響應(yīng)成功,只要一個(gè)多數(shù)派ACK即可。
?
丟棄的事務(wù)proposal處理過程:
ZAB協(xié)議中使用ZXID作為事務(wù)編號(hào),ZXID為64位數(shù)字,低32位為一個(gè)遞增的計(jì)數(shù)器,每一個(gè)客戶端的一個(gè)事務(wù)請求時(shí)Leader產(chǎn)生新的事務(wù)后該計(jì)數(shù)器都會(huì)加1, 高32位為Leader周期epoch編號(hào),當(dāng)新選舉出一個(gè)Leader節(jié)點(diǎn)時(shí)Leader會(huì)取出本地日志中最大事務(wù)Proposal的ZXID解析出對應(yīng)的epoch把該值加1作為新的epoch,將低32位從0開始生成新的ZXID; ZAB使用epoch來區(qū)分不同的Leader周期,能有效避免了不同的leader服務(wù)器錯(cuò)誤的使用相同的ZXID編號(hào)提出不同的事務(wù)proposal的異常情況,大大簡化了提升了數(shù)據(jù)恢復(fù)流程; 所以這個(gè)崩潰的機(jī)器啟動(dòng)時(shí),也無法成為新一輪的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的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 儿童乐园设备有哪些
- 下一篇: xp停止服务怎么办 分享给大家