一文詳解ZooKeeper的順序一致性
ZooKeeper是一個(gè)分布式的協(xié)調(diào)服務(wù),它提供了高可用性和順序一致性的數(shù)據(jù)存儲(chǔ),通常用于解決分布式系統(tǒng)中的協(xié)調(diào)問(wèn)題。ZooKeeper通過(guò)使用ZooKeeper客戶端庫(kù)與ZooKeeper服務(wù)器集群進(jìn)行交互來(lái)實(shí)現(xiàn)這些特性。
ZooKeeper保證事務(wù)的順序一致性是通過(guò)原子更新操作的方式來(lái)實(shí)現(xiàn)的。ZooKeeper提供了一組原子操作,可以讓客戶端更新服務(wù)器上的數(shù)據(jù)節(jié)點(diǎn)。這些原子操作被稱(chēng)為 ZooKeeper事務(wù),事務(wù)在服務(wù)器端被逐個(gè)處理,并按照它們?cè)诳蛻舳税l(fā)送的順序來(lái)執(zhí)行。這確保了所有客戶端看到的數(shù)據(jù)更新順序是一致的。
ZooKeeper 的設(shè)計(jì)目標(biāo)之一是提供一致性服務(wù),因此在其內(nèi)部實(shí)現(xiàn)中,保持事務(wù)的順序一致性非常重要。
ZooKeeper作為分布式應(yīng)用系統(tǒng)協(xié)調(diào)服務(wù),在分布式系統(tǒng)中的應(yīng)用非常廣泛,在某些業(yè)務(wù)場(chǎng)景下甚至可以作為注冊(cè)中心、分布式鎖來(lái)使用。ZooKeeper之所以能有如此廣泛的應(yīng)用,與它良好的數(shù)據(jù)一致性保障機(jī)制是分不開(kāi)的。我們都知道ZooKeeper專(zhuān)門(mén)設(shè)計(jì)了Zab(Zookeeper Atomic Broadcast)協(xié)議作為其數(shù)據(jù)一致性協(xié)議。
利用Zab協(xié)議的數(shù)據(jù)寫(xiě)入由Leader結(jié)點(diǎn)協(xié)調(diào),使用兩階段提交的方式,達(dá)到數(shù)據(jù)的最終一致性。為什么是最終一致性呢?我們先了解下兩階段的過(guò)程,如圖一所示:
圖一
數(shù)據(jù)寫(xiě)入過(guò)程如下:
第一階段:每次的數(shù)據(jù)寫(xiě)入事件作為提案廣播給所有Follower結(jié)點(diǎn);可以寫(xiě)入的結(jié)點(diǎn)返回確認(rèn)信息ACK;
第二階段:Leader收到一半以上的ACK信息后確認(rèn)寫(xiě)入可以生效,向所有結(jié)點(diǎn)廣播COMMIT將提案生效。
根據(jù)寫(xiě)入過(guò)程的兩階段的描述,我們知道ZooKeeper保證的是最終一致性,即Leader向客戶端返回寫(xiě)入成功后,可能有部分Follower還沒(méi)有寫(xiě)入最新的數(shù)據(jù),所以是最終一致性。
我們都知道ZooKeeper保證的最終一致性也叫順序一致性,即每個(gè)結(jié)點(diǎn)的數(shù)據(jù)都是嚴(yán)格按事務(wù)的發(fā)起順序生效的。
ZooKeeper是如何保證事務(wù)順序的呢?
這里需要了解下它的事務(wù)ID(ZXID),之前的文章介紹過(guò)ZooKeeper的在選舉時(shí)通過(guò)比較各結(jié)點(diǎn)的ZXID和機(jī)器ID選出新的注結(jié)點(diǎn)的。ZXID由Leader節(jié)點(diǎn)生成,有新寫(xiě)入事件時(shí),Leader生成新ZXID并隨提案一起廣播,每個(gè)結(jié)點(diǎn)本地都保存了當(dāng)前最近一次事務(wù)的ZXID,ZXID是遞增的,所以誰(shuí)的ZXID越大,就表示誰(shuí)的數(shù)據(jù)是最新的。
ZXID的生成規(guī)則如下圖所示:
圖二
ZXID有兩部分組成:
任期:完成本次選舉后,直到下次選舉前,由同一Leader負(fù)責(zé)協(xié)調(diào)寫(xiě)入;
事務(wù)計(jì)數(shù)器:?jiǎn)握{(diào)遞增,每生效一次寫(xiě)入,計(jì)數(shù)器加一。
可以看到,ZXID的低32位是計(jì)數(shù)器,所以同一任期內(nèi),ZXID是連續(xù)的,每個(gè)結(jié)點(diǎn)又都保存著自身最新生效的ZXID,通過(guò)對(duì)比新提案的ZXID與自身最新ZXID是否相差“1”,來(lái)保證事務(wù)嚴(yán)格按照順序生效的。
我們都知道ZooKeeper集群的寫(xiě)入是由Leader結(jié)點(diǎn)協(xié)調(diào)的,真實(shí)場(chǎng)景下寫(xiě)入會(huì)有一定的并發(fā)量,那Zab協(xié)議的兩階段提交是如何保證事務(wù)嚴(yán)格按順序生效的呢?在本章介紹兩階段提交的部分描述了Leader在收到半數(shù)以上ACK后會(huì)將提案生效并廣播給所有Follower結(jié)點(diǎn)。
Leader為了保證提案按ZXID順序生效,使用了一個(gè)ConcurrentHashMap,記錄所有未提交的提案,命名為outstandingProposals,key為ZXID,Value為提案的信息。對(duì)outstandingProposals的訪問(wèn)邏輯如下:
1、每發(fā)起一個(gè)提案,會(huì)將提案的ZXID和內(nèi)容放到outstandingProposals中,作為待提交的提案;
2、收到Follower的ACK信息后,根據(jù)ACK中的ZXID從outstandingProposals中找到對(duì)應(yīng)的提案,對(duì)ACK計(jì)數(shù);
3、執(zhí)行tryToCommit嘗試將提案提交,判斷流程如下:
3.1:判斷當(dāng)前ZXID之前是否還有未提交提案,如果有,當(dāng)前提案暫時(shí)不能提交;
3.2:判斷提案是否收到半數(shù)以上ACK,如果達(dá)到半數(shù)則可以提交;
3.3:如果可以提交,將當(dāng)前ZXID從outstandingProposals中清除并向Followers廣播提交當(dāng)前提案;
Leader是如何判斷當(dāng)前ZXID之前是否還有未提交提案的呢?由于前提是保證順序提交的,所以Leader只需判斷outstandingProposals里,當(dāng)前ZXID的前一個(gè)ZXID是否存在,代碼如下:
圖三
所以ZooKeeper是通過(guò)兩階段提交保證數(shù)據(jù)的最終一致性,并且通過(guò)嚴(yán)格的按照Z(yǔ)XID的順序生效提案保證其順序一致性的。