顧小苑

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

關(guān)鍵詞：分布式鎖 Chubby ZooKeeper

中圖分類號：TP316.7 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9416（2016）08-0081-02

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

1 Chubby和ZooKeeper各自的特性對比

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

Chubby和ZooKeeper兩種系統(tǒng)都提供分布式鎖服務(wù)，但是兩種系統(tǒng)的應(yīng)用環(huán)境不同，系統(tǒng)設(shè)計(jì)的側(cè)重點(diǎn)也不同，兩種系統(tǒng)具有不同的特性。

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

2.1 Chubby中的Paxos算法

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

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

2.2 ZooKeeper中的 Zab協(xié)議

Zookeeper是以節(jié)點(diǎn)樹（znode樹）[2]組織的，ZooKeeper的設(shè)計(jì)思想是：保證對znode樹的每一次修改都復(fù)制到ensemble（類似“多數(shù)派”）中的大部分機(jī)器上去。如果機(jī)器中小部分出故障了，那么至少有一臺機(jī)器將會(huì)恢復(fù)到最新狀態(tài)。其他的則保存著副本，直到恢復(fù)到最新狀態(tài)?；诖?，ZooKeeper采用以下設(shè)計(jì)保證數(shù)據(jù)的一致性流[3]。即順序的一致性、原子性、單系統(tǒng)映像、容錯(cuò)性、合時(shí)性。

Chubby系統(tǒng)中所有的一致性問題都采用一致性算法解決，而ZooKeeper系統(tǒng)雖然應(yīng)用Zab協(xié)議，并且在協(xié)議中運(yùn)用技術(shù)保證數(shù)據(jù)的一致性流，但是在技術(shù)的具體實(shí)現(xiàn)上依然采用Paxos一致性算法。

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

3.1 Chubby系統(tǒng)的通信協(xié)議

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

3.2 ZooKeeper中的會(huì)話狀態(tài)

ZooKeeper客戶端與ensemble表中的服務(wù)器嘗試連接，一旦與Zookeeper服務(wù)器連接成功，服務(wù)器會(huì)創(chuàng)建與客戶端的一個(gè)新的對話[4]。一個(gè)對話的生命周期中用不同的狀態(tài)來表示ZooKeeper對象[5]的轉(zhuǎn)變。其狀態(tài)事物圖如圖2所示。

4 結(jié)語

本文重點(diǎn)分析比較了Chubby和ZooKeeper系統(tǒng)所具備的特性，采用的一致性算法，客戶端與主服務(wù)器之間的通信等幾個(gè)方面，尤其對兩種系統(tǒng)具有的特性和同步算法進(jìn)行了重點(diǎn)分析。研究了分布式鎖服務(wù)中兩種系統(tǒng)的異同點(diǎn)，得出：在分布式鎖服務(wù)中，不同的云計(jì)算系統(tǒng)采用的一致性算法相同，但是應(yīng)用于不同環(huán)境的分布式鎖服務(wù)的設(shè)計(jì)特性和實(shí)現(xiàn)過程相異。

參考文獻(xiàn)

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

[2]何慧虹，王勇，史亮.分布式環(huán)境下基于ZooKeeper服務(wù)的數(shù)據(jù)同步研究[J].信息網(wǎng)絡(luò)安全，2015，09：227-230.

[3]李汝光，趙俊.基于ZooKeeper的分布式緩存的設(shè)計(jì)與實(shí)現(xiàn)[J].綿陽師范學(xué)院學(xué)報(bào).2011（11）.

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

[5]劉芬，王芳，田昊.基于Zookeeper的分布式鎖服務(wù)及性能優(yōu)化[J].計(jì)算機(jī)研究與發(fā)展，2014，S1：229-234.