詳見：http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt375

?

隨著云計算的推廣，云平臺的設計和實現越來越復雜，很多系統屬性如一致性和可靠性往往是在系統迭代開發時才被考慮到。如果在原生的系統上重復的實現復雜的一致性算法，這樣不僅會破壞原有設計的結構，而且還帶來很多開發上的負擔。因此很多系統開發人員和架構師努力地進行系統劃分，將系統分割成很多組件，分層設計，模塊調用，從而最大限度地提高軟件復用能力，降低系統設計和開發的難度。

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

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

???????? 和Chubby一樣，zookeeper采用paxos的變種來實現消息傳輸的一致性。Zookeeper開發了原子多播協議 Zab 來實現數據的一致性傳輸。Zookeeper采用的是primary-backup的結構，primary節點產生non- commutative 事務，通過協議按序的廣播到其他backup節點上。在節點無錯的情況下，這是非常簡單的事情，然而，面對復雜的網絡環境，多變的軟硬件條件，節點掛掉，重啟，數據重復發送，這些異常很常見。Zookeeper如何做到即便是系統出現異常，也能夠保證整個系統狀態是一致？paxos的變種，Zookeeper的Zab協議很好的保證了這一點。

???????? Zab 協議以epoch的方式執行（相當與序列號），在每個epoch最多只有一個進程多播數據。如果某個進程執行了協議的的第一階段，那么進程將不再接受之前還沒確定提交的epoch的數據。這樣一來就保證了在進程在recovery階段不會出現丟失已提交的數據的情況。在某個epoch下，所有參加這個epoch的進程必須此epoch之前所有已經提交的數據鏡像。為了保證一致性，進程在完全恢復之前必須不能廣播新的事務。Zab協議的這幾個特點處理了primary異常、新舊primary以及backup節點異常的情況，的確保證了primary進程原子多播的order特性。

整個Zab協議的內容分成三個階段：Discovery、Synchronization和Broadcast階段。

Discovery階段其實是選舉leader或者發現leader。在這個階段里，follower會給（可能是）leader的進程（這里的進程可以是多個）發送當前自己epoch的信息CEPOCH；如果（可能是）leader進程收到大多數的follower的CEPOCH消息，那么leader就會產生一個新epoch的消息NEWEPOCH，其中包含新的leader，并發送給follower；當follower?f收到NEWEPOCH時，f會判斷其中epoch是否比當前的大，如果是則反饋信息ACK-E，其中包含f所接受的最大事務編號和歷史數據；leader會從這些ACK-E中選出最新的歷史數據來初始化它當前的系統狀態。這個階段其實就是paxos的執行過程，由于兩個大多數集合的交集肯定不為空，所以不可能一個epoch下會選出兩個不同的leader。因此Discovery階段最后的結果肯定只有一個新leader。在整個系統初始的時候，每個節點當前的epoch都為0，這樣會給其它節點發送請求，這樣有可能會導致paxos死鎖，對此，每個zookeeper節點會通過配置獲得唯一的id，并根據id的大則優先的原則來推選leader。

Synchronization階段其實就會狀態同步，新leader會將其最新狀態通知給所有的follower；follower的到leader的狀態后，會和自己的進行比較，從中提前還未提交的數據T，并反饋給leader；leader收到大多數確認反饋時，則發送提交命令commit給這些follower；follower收到commit后提交T中的所有數據。

Broadcast階段和Synchronization階段相似，只是這個階段是對一個請求的提交而不是一個集合的提交。

Zab這三個階段保證了前面提到的協議的幾個特性，其正確性無非就是從integrity、total order 和 casual order三個方面去證明。從實際應用看，Discovery和synchronization階段在系統狀態出現不一致時，這兩個階段保證了系統即便出問題也能恢復到一致的狀態；Broadcast階段主要保證了事務執行的順序性。

總而言之，paxos算法是Zookeeper的核心。Google Chubby架構師曾說，一切一致性協議都是paxos的變種。仔細分析，想gossip、viewstamp或者virtual synchronization其實是對relax paxos的某些條件。即便是Chubby或者Zookeeper其中采取的算法也是變種中的其中之一。Chubby和Zookeeper現有版本都是采取中心化的思想，在擴展性和性能之間的折中表現還不是很好。隨著系統規模的變大和新環境的出現，如何對其去中心化并能保證可靠容錯，這將是個很有趣的問題。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。