詳見(jiàn)：http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt375

?

隨著云計(jì)算的推廣，云平臺(tái)的設(shè)計(jì)和實(shí)現(xiàn)越來(lái)越復(fù)雜，很多系統(tǒng)屬性如一致性和可靠性往往是在系統(tǒng)迭代開(kāi)發(fā)時(shí)才被考慮到。如果在原生的系統(tǒng)上重復(fù)的實(shí)現(xiàn)復(fù)雜的一致性算法，這樣不僅會(huì)破壞原有設(shè)計(jì)的結(jié)構(gòu)，而且還帶來(lái)很多開(kāi)發(fā)上的負(fù)擔(dān)。因此很多系統(tǒng)開(kāi)發(fā)人員和架構(gòu)師努力地進(jìn)行系統(tǒng)劃分，將系統(tǒng)分割成很多組件，分層設(shè)計(jì)，模塊調(diào)用，從而最大限度地提高軟件復(fù)用能力，降低系統(tǒng)設(shè)計(jì)和開(kāi)發(fā)的難度。

???????? Google在系統(tǒng)的可靠性方面提出了中心化的組件Chubby—粗粒度鎖服務(wù)，通過(guò)鎖原語(yǔ)為其他系統(tǒng)實(shí)現(xiàn)更高級(jí)的服務(wù)，比如組成員、域名服務(wù)和leader選舉等等。Chubby本身也是一個(gè)小型的cell（通常由5個(gè)chubby結(jié)點(diǎn)組成），cell內(nèi)部采用類似于狀態(tài)機(jī)副本形式實(shí)現(xiàn)可靠容錯(cuò)。Google的Chubby論文在OSDI上發(fā)表后引起了很大的反響，原因很多，主要有兩個(gè)：第一，chubby很好的解決了分布式開(kāi)發(fā)的一致性問(wèn)題；第二，Google Chubby采用Leslie Lamport提出的paxos算法來(lái)實(shí)現(xiàn)可靠容錯(cuò)，這是業(yè)界關(guān)于paxos第一個(gè)完整可行的實(shí)現(xiàn)。正因?yàn)镚oogle Chubby，paxos這個(gè)一直沉淀在學(xué)術(shù)研究的協(xié)議，終于曝光在工業(yè)界中，之后很快地推廣開(kāi)去。

???????? 然而，Google Chubby并不是開(kāi)源的，我們只能通過(guò)其論文和其他相關(guān)的文檔中了解具體的細(xì)節(jié)。值得慶幸的是，Yahoo！借鑒Chubby的設(shè)計(jì)思想開(kāi)發(fā)了Zookeeper，并將其開(kāi)源。和Chubby相比，Zookeeper做了很多突破。不像Chubby的單點(diǎn)服務(wù)的結(jié)構(gòu)，zookeeper采用多個(gè)server同時(shí)處理客戶端的請(qǐng)求，異步讀同步寫(xiě)，通過(guò)primary節(jié)點(diǎn)來(lái)同步數(shù)據(jù)的update，這一點(diǎn)大大改善了讀服務(wù)的性能，當(dāng)然弱化了客戶端與服務(wù)器之間的一致性。另外，zookeeper采用block free的服務(wù)接口，采用watch機(jī)制的方式異步處理請(qǐng)求結(jié)果和指定數(shù)據(jù)的變更。Zookeeper對(duì)外提供了更加低級(jí)的原語(yǔ)primitive，基于此可以實(shí)現(xiàn)更多更加復(fù)雜的分布式算法，如queue、barrier和lock等等。如今很多云計(jì)算系統(tǒng)或者平臺(tái)都使用Zookeeper來(lái)做可靠容錯(cuò)，進(jìn)行訂閱分發(fā)服務(wù)，或者其他應(yīng)用。

???????? 和Chubby一樣，zookeeper采用paxos的變種來(lái)實(shí)現(xiàn)消息傳輸?shù)囊恢滦浴ookeeper開(kāi)發(fā)了原子多播協(xié)議 Zab 來(lái)實(shí)現(xiàn)數(shù)據(jù)的一致性傳輸。Zookeeper采用的是primary-backup的結(jié)構(gòu)，primary節(jié)點(diǎn)產(chǎn)生non- commutative 事務(wù)，通過(guò)協(xié)議按序的廣播到其他backup節(jié)點(diǎn)上。在節(jié)點(diǎn)無(wú)錯(cuò)的情況下，這是非常簡(jiǎn)單的事情，然而，面對(duì)復(fù)雜的網(wǎng)絡(luò)環(huán)境，多變的軟硬件條件，節(jié)點(diǎn)掛掉，重啟，數(shù)據(jù)重復(fù)發(fā)送，這些異常很常見(jiàn)。Zookeeper如何做到即便是系統(tǒng)出現(xiàn)異常，也能夠保證整個(gè)系統(tǒng)狀態(tài)是一致？paxos的變種，Zookeeper的Zab協(xié)議很好的保證了這一點(diǎn)。

???????? Zab 協(xié)議以epoch的方式執(zhí)行（相當(dāng)與序列號(hào)），在每個(gè)epoch最多只有一個(gè)進(jìn)程多播數(shù)據(jù)。如果某個(gè)進(jìn)程執(zhí)行了協(xié)議的的第一階段，那么進(jìn)程將不再接受之前還沒(méi)確定提交的epoch的數(shù)據(jù)。這樣一來(lái)就保證了在進(jìn)程在recovery階段不會(huì)出現(xiàn)丟失已提交的數(shù)據(jù)的情況。在某個(gè)epoch下，所有參加這個(gè)epoch的進(jìn)程必須此epoch之前所有已經(jīng)提交的數(shù)據(jù)鏡像。為了保證一致性，進(jìn)程在完全恢復(fù)之前必須不能廣播新的事務(wù)。Zab協(xié)議的這幾個(gè)特點(diǎn)處理了primary異常、新舊primary以及backup節(jié)點(diǎn)異常的情況，的確保證了primary進(jìn)程原子多播的order特性。

整個(gè)Zab協(xié)議的內(nèi)容分成三個(gè)階段：Discovery、Synchronization和Broadcast階段。

Discovery階段其實(shí)是選舉leader或者發(fā)現(xiàn)leader。在這個(gè)階段里，follower會(huì)給（可能是）leader的進(jìn)程（這里的進(jìn)程可以是多個(gè)）發(fā)送當(dāng)前自己epoch的信息CEPOCH；如果（可能是）leader進(jìn)程收到大多數(shù)的follower的CEPOCH消息，那么leader就會(huì)產(chǎn)生一個(gè)新epoch的消息NEWEPOCH，其中包含新的leader，并發(fā)送給follower；當(dāng)follower?f收到NEWEPOCH時(shí)，f會(huì)判斷其中epoch是否比當(dāng)前的大，如果是則反饋信息ACK-E，其中包含f所接受的最大事務(wù)編號(hào)和歷史數(shù)據(jù)；leader會(huì)從這些ACK-E中選出最新的歷史數(shù)據(jù)來(lái)初始化它當(dāng)前的系統(tǒng)狀態(tài)。這個(gè)階段其實(shí)就是paxos的執(zhí)行過(guò)程，由于兩個(gè)大多數(shù)集合的交集肯定不為空，所以不可能一個(gè)epoch下會(huì)選出兩個(gè)不同的leader。因此Discovery階段最后的結(jié)果肯定只有一個(gè)新leader。在整個(gè)系統(tǒng)初始的時(shí)候，每個(gè)節(jié)點(diǎn)當(dāng)前的epoch都為0，這樣會(huì)給其它節(jié)點(diǎn)發(fā)送請(qǐng)求，這樣有可能會(huì)導(dǎo)致paxos死鎖，對(duì)此，每個(gè)zookeeper節(jié)點(diǎn)會(huì)通過(guò)配置獲得唯一的id，并根據(jù)id的大則優(yōu)先的原則來(lái)推選leader。

Synchronization階段其實(shí)就會(huì)狀態(tài)同步，新leader會(huì)將其最新?tīng)顟B(tài)通知給所有的follower；follower的到leader的狀態(tài)后，會(huì)和自己的進(jìn)行比較，從中提前還未提交的數(shù)據(jù)T，并反饋給leader；leader收到大多數(shù)確認(rèn)反饋時(shí)，則發(fā)送提交命令commit給這些follower；follower收到commit后提交T中的所有數(shù)據(jù)。

Broadcast階段和Synchronization階段相似，只是這個(gè)階段是對(duì)一個(gè)請(qǐng)求的提交而不是一個(gè)集合的提交。

Zab這三個(gè)階段保證了前面提到的協(xié)議的幾個(gè)特性，其正確性無(wú)非就是從integrity、total order 和 casual order三個(gè)方面去證明。從實(shí)際應(yīng)用看，Discovery和synchronization階段在系統(tǒng)狀態(tài)出現(xiàn)不一致時(shí)，這兩個(gè)階段保證了系統(tǒng)即便出問(wèn)題也能恢復(fù)到一致的狀態(tài)；Broadcast階段主要保證了事務(wù)執(zhí)行的順序性。

總而言之，paxos算法是Zookeeper的核心。Google Chubby架構(gòu)師曾說(shuō)，一切一致性協(xié)議都是paxos的變種。仔細(xì)分析，想gossip、viewstamp或者virtual synchronization其實(shí)是對(duì)relax paxos的某些條件。即便是Chubby或者Zookeeper其中采取的算法也是變種中的其中之一。Chubby和Zookeeper現(xiàn)有版本都是采取中心化的思想，在擴(kuò)展性和性能之間的折中表現(xiàn)還不是很好。隨著系統(tǒng)規(guī)模的變大和新環(huán)境的出現(xiàn)，如何對(duì)其去中心化并能保證可靠容錯(cuò)，這將是個(gè)很有趣的問(wèn)題。

總結(jié)

以上是生活随笔為你收集整理的Zookeeper和 Google Chubby对比分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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