Chubby和ZooKeeper系統的對比研究

顧小苑

摘要：本文對比探討了分布式鎖服務當中的Chubby和ZooKeeper系統，運用對比分析法，分別從系統所具備的特性，采用的一致性算法，客戶端與主服務器之間的通信等幾個方面作了對比。分析得出，作為商業的Chubby系統注重可靠性和可用性，而作為開源項目的ZooKeeper系統注重簡單性和松耦合交互。兩種服務在特性、通信等方面不同，但都采用Paxos一致性算法。

關鍵詞：分布式鎖 Chubby ZooKeeper

中圖分類號：TP316.7 文獻標識碼：A 文章編號：1007-9416（2016）08-0081-02

在大型分布式文件系統中，系統必須具備高可用性、高可靠性以及數據一致性。為解決系統的可用性和可靠性，系統采用多副本的形式。但同時，也帶來系統數據的一致性問題，為解決分布式環境下數據的一致性問題，Google云系統并沒有直接開發一個直接實現包含了解決一致性問題的Paxos算法函數庫，而是在Paxos算法的基礎上設計了一個全新的鎖服務Chubby。Chubby中涉及的一致性問題都由Paxos算法解決。Zookeeper是Hadoop的正式子項目，是一種用于提供配置信息服務、命名服務、分布式同步和組服務等的集中式協調系統。Zookeeper不僅解決了分布式鎖的問題，其在本質上是一種分布式的小文件存儲系統。

1 Chubby和ZooKeeper各自的特性對比

Chubby作為商業的云計算系統，一是系統必須具備高可用性和高可靠性，在保證此目標的基礎上再考慮系統的吞吐量和存儲能力；二是高擴展性：將數據存儲在價格較為低廉的RAM，支持大規模用戶訪問文件；三是支持粗粒度的建議性鎖服務：具備建議性的鎖能夠提高系統的性能；四是支持通報機制和支持緩存機制。而作為開源項目的ZooKeeper服務，其具有的特性與Chubby系統不同，一是簡易：ZooKeeper的核心就是一個精簡的文件系統，它提供一些簡單的操作以及一些附加的抽象；二是易表達：ZooKeeper的原型是一個豐富的集合，它們是一些已建好的塊，可以用來構建大型的協作數據結構和協議，例如：分布式對壘，分布式鎖以及一組對等體的選舉；三是松散耦合交互：ZooKeeper的交互支持參與者之間并不了解對方。

Chubby和ZooKeeper兩種系統都提供分布式鎖服務，但是兩種系統的應用環境不同，系統設計的側重點也不同，兩種系統具有不同的特性。

2 Chubby和ZooKeeper中的一致性算法對比

2.1 Chubby中的Paxos算法

Paxos算法[1]是一種基于消息傳遞的一致性算法，用于解決分布式系統中的一致性問題。在paxos算法中，節點被劃分為三種類型：proposers、acceptors和learners。其中proposers提出決議，acceptors批準決議，learners獲取并使用已經通過的決議。Paxos算法在滿足約束條件的基礎上，可以將決議的通過分成如下兩個階段。一是準備階段：proposers選擇一個提案并將它的編號設為n，然后將它發送給acceptors中的一個“多數派”，acceptors收到后，如果提案的編號大于它已經回復的所有消息，則acceptors將自己上次的批準回復給proposers，并不再批準小于n的提案。二是批準階段：當proposers接收到acceptors中的這個“多數派”的回復后，就向回復請求的acceptors發送accept請求，在符合acceptors乙方的約束條件下，acceptors收到accept請求后即批準這個請求。

為了減少決議發布過程中的消息量，acceptors將這個通過的決議發送給learners的一個子集，然后由這個子集中的learners去通知其他的learners。一般情況下，以上的算法過程就可以成功解決一致性問題，但是也有特殊情況，即陷入死鎖后重新選舉出一個president，僅允許president提出議案。

2.2 ZooKeeper中的 Zab協議

Zookeeper是以節點樹（znode樹）[2]組織的，ZooKeeper的設計思想是：保證對znode樹的每一次修改都復制到ensemble（類似“多數派”）中的大部分機器上去。如果機器中小部分出故障了，那么至少有一臺機器將會恢復到最新狀態。其他的則保存著副本，直到恢復到最新狀態。基于此，ZooKeeper采用以下設計保證數據的一致性流[3]。即順序的一致性、原子性、單系統映像、容錯性、合時性。

Chubby系統中所有的一致性問題都采用一致性算法解決，而ZooKeeper系統雖然應用Zab協議，并且在協議中運用技術保證數據的一致性流，但是在技術的具體實現上依然采用Paxos一致性算法。

3 客戶端與服務器之間的通信過程對比

3.1 Chubby系統的通信協議

客戶端和主服務器之間的通信是通過KeepAlive握手協議來維持的，KeepAlive握手協議通信過程如圖1所示。

3.2 ZooKeeper中的會話狀態

ZooKeeper客戶端與ensemble表中的服務器嘗試連接，一旦與Zookeeper服務器連接成功，服務器會創建與客戶端的一個新的對話[4]。一個對話的生命周期中用不同的狀態來表示ZooKeeper對象[5]的轉變。其狀態事物圖如圖2所示。

4 結語

本文重點分析比較了Chubby和ZooKeeper系統所具備的特性，采用的一致性算法，客戶端與主服務器之間的通信等幾個方面，尤其對兩種系統具有的特性和同步算法進行了重點分析。研究了分布式鎖服務中兩種系統的異同點，得出：在分布式鎖服務中，不同的云計算系統采用的一致性算法相同，但是應用于不同環境的分布式鎖服務的設計特性和實現過程相異。

參考文獻

[1]劉鵬，等.云計算（第二版）[M].北京：電子工業出版社，2011年：31-35.

[2]何慧虹，王勇，史亮.分布式環境下基于ZooKeeper服務的數據同步研究[J].信息網絡安全，2015，09：227-230.

[3]李汝光，趙俊.基于ZooKeeper的分布式緩存的設計與實現[J].綿陽師范學院學報.2011（11）.

[4]Tom White著，周傲英等譯.Hadoop權威指南（中文版）[M].北京：清華大學出版社，2010年：394-416.

[5]劉芬，王芳，田昊.基于Zookeeper的分布式鎖服務及性能優化[J].計算機研究與發展，2014，S1：229-234.