ZooKeeper解析:分布式系統(tǒng)工程師的瑞士軍刀

責(zé)任編輯:editor006

作者:核子可樂譯

2015-09-28 14:05:51

摘自:51CTO

所謂分布式系統(tǒng),指的是一組通過發(fā)送消息實(shí)現(xiàn)協(xié)作、從而共同達(dá)成同一目標(biāo)的資源集合。而活性則確保了該算法的持續(xù)遞進(jìn),在分布鎖這一場(chǎng)景當(dāng)中,這意味著如果某個(gè)節(jié)點(diǎn)嘗試獲取該鎖、那么最終一定能夠獲取到。

所謂分布式系統(tǒng),指的是一組通過發(fā)送消息實(shí)現(xiàn)協(xié)作、從而共同達(dá)成同一目標(biāo)的資源集合。正如知名計(jì)算機(jī)科學(xué)家Leslie Lamport所指出之定義:“所謂分布式系統(tǒng),其中任意一臺(tái)計(jì)算設(shè)備——即使使用者并未直接使用甚至對(duì)其存在毫不知情——出現(xiàn)故障,亦會(huì)影響到其它設(shè)備的正常運(yùn)作。”

而這條定義也恰恰概括了我們?cè)诜植际较到y(tǒng)當(dāng)中經(jīng)常遇到的一類問題。事實(shí)上,在云計(jì)算時(shí)代之下,資源的匯聚已經(jīng)成為滿足負(fù)載對(duì)于計(jì)算及存儲(chǔ)實(shí)際需求的一種必然手段。這類系統(tǒng)的特點(diǎn)在于包含大量需要管理的資源,而其中故障的出現(xiàn)頻率與整體規(guī)模則成正比關(guān)系。

在分布式系統(tǒng)當(dāng)中,故障屬于一類常規(guī)事態(tài),而非意外狀況——這意味著我們必須時(shí)刻做好心理準(zhǔn)備。有鑒于此,相關(guān)社區(qū)專門創(chuàng)建出專門的工具,旨在幫助開發(fā)人員應(yīng)對(duì)這方面問題,而Apache ZooKeeper正是其中之一。

ZooKeeper是一款極具實(shí)用性、現(xiàn)場(chǎng)測(cè)試能力并擁有廣泛用戶群體的中間件,專門用于構(gòu)建分布式應(yīng)用程序。在OpenStack當(dāng)中,ZooKeeper也成為Nova ServiceGroup API后端中的組成部分。最近,ZooKeeper還與Ceilometer相集成,從而為Central Agent帶來更為理想的高可用性水平——當(dāng)然,這方面話題我們以后將另行討論。

我們?yōu)槭裁葱枰猌ooKeeper?

一般來講,當(dāng)大家設(shè)計(jì)一款分布式應(yīng)用程序時(shí),常常會(huì)發(fā)現(xiàn)需要將各類流程加以協(xié)同才能執(zhí)行預(yù)期任務(wù)。在大多數(shù)情況下,這種協(xié)作關(guān)系依賴于最基本的分布式協(xié)作機(jī)制。

Heat是一款OpenStack編排程序。大家可以利用它創(chuàng)建出一系列云資源,而這類資源會(huì)由一個(gè)模板文件負(fù)責(zé)指定,這就是堆棧的概念。Heat允許用戶對(duì)堆棧進(jìn)行更新,但更新過程必須以原子方式進(jìn)行,否則可能會(huì)導(dǎo)致資源復(fù)制或者相關(guān)性破壞等沖突。這類問題在并發(fā)更新場(chǎng)景下非常常見,而為了解決此類問題,Heat會(huì)在對(duì)堆棧進(jìn)行更新之前首先設(shè)置一套所謂分布式互斥鎖。

在這類原型基礎(chǔ)之上進(jìn)行開發(fā)是項(xiàng)極為困難的工作,而且經(jīng)常帶來令人頭痛的麻煩。事實(shí)上,在分布式系統(tǒng)當(dāng)中反復(fù)出現(xiàn)的這些問題早已成為技術(shù)圈中的共識(shí)。為了簡(jiǎn)化開發(fā)人員的日常工作,雅虎實(shí)驗(yàn)室創(chuàng)造出了Apache ZooKeeper項(xiàng)目,旨在為這些協(xié)作因素提供一套集中式API。歸功于ZooKeeper的幫助,現(xiàn)在我們已經(jīng)能夠輕松實(shí)現(xiàn)多種不同協(xié)議,包括分布式鎖、屏障以及隊(duì)列等等。

ZooKeeper應(yīng)用程序的架構(gòu)與優(yōu)勢(shì)

一款ZooKeeper應(yīng)用程序由一臺(tái)或者多臺(tái)ZK服務(wù)器支撐而成,我們可以將其稱為一個(gè)“集合”,在應(yīng)用程序端則為一組ZK客戶端。

ZooKeeper解析:分布式系統(tǒng)工程師的瑞士軍刀

其設(shè)計(jì)思路在于,該分布式應(yīng)用程序的每一個(gè)節(jié)點(diǎn)都通過使用一個(gè)ZK客戶端在應(yīng)用層級(jí)使用相關(guān)API,這意味著應(yīng)用的運(yùn)行將依賴于ZooKeeper服務(wù)器實(shí)現(xiàn)。

這種架構(gòu)方案擁有以下幾項(xiàng)突出優(yōu)勢(shì):

我們可以立足于應(yīng)用層提取大部分分布式同步負(fù)載,從而實(shí)現(xiàn)一套所謂KISS(即Keep It Simple, Stupid,保持一切簡(jiǎn)單且具傻瓜式特性)架構(gòu)。

常見的各類分布式協(xié)作元能夠?qū)崿F(xiàn)開箱即用,因此開發(fā)人員無需再自行對(duì)其加以處理。

開發(fā)人員不需要處理服務(wù)故障等狀況,因?yàn)檎左w系擁有出色的彈性。ZooKeeper以應(yīng)用程序神經(jīng)中心的姿態(tài)存在,因?yàn)樗?fù)責(zé)控制整個(gè)協(xié)作機(jī)制,因此眾多組件都需要依附于它以實(shí)現(xiàn)作用。出于這些理由,ZooKeeper在設(shè)計(jì)中引入了出色的分布式算法,從而提供開發(fā)人員所需要的高可靠性與可用性保障。一個(gè)ZooKeeper集合基于群體形式存在,且通常由三到五臺(tái)服務(wù)器構(gòu)成。

ZooKeeper集合能夠在多種場(chǎng)景之下發(fā)揮作用,下面讓我們從實(shí)踐角度出發(fā)一同來了解。

實(shí)踐場(chǎng)景中的ZooKeeper

ZooKeeper的API非常簡(jiǎn)單而且直觀,其數(shù)據(jù)模型基于以內(nèi)存樹形式存儲(chǔ)的分層命名空間。該樹中的各項(xiàng)元素被稱為znode,以文件形式容納數(shù)據(jù)并能夠如目錄一般擁有子znode。

首先,大家需要確保自己的運(yùn)行環(huán)境滿足系統(tǒng)配置要求,接下來我們就要著手部署一臺(tái)ZK服務(wù)器了:

$ wget http://apache.crihan.fr/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

$ tar xzf zookeeper-3.4.6.tar.gz

$ cd zookeeper-3.4.6

$ cp conf/zoo_sample.cfg conf/zoo.cfg

$ ./bin/zkServer.sh start

現(xiàn)在ZooKeeper服務(wù)器已經(jīng)能夠以獨(dú)立模式運(yùn)行了,且會(huì)在默認(rèn)情況下監(jiān)聽127.0.0.1:2181。如果大家需要部署一整套服務(wù)器集合,則可以點(diǎn)擊此處閱讀其相關(guān)管理指南。

ZooKeeper命令行界面

我們可以利用ZooKeeper命令行界面(./bin/zkCli.sh)完成一些基礎(chǔ)性操作。其使用方式與shell控制臺(tái)非常相似,操作感受也與文件系統(tǒng)相當(dāng)接近。

下面列出root znode“/”中的全部子znode:

[zk: localhost:2181(CONNECTED) 0] ls /

[zookeeper]

創(chuàng)建一個(gè)路徑為“/myZnode”的znode,其相關(guān)數(shù)據(jù)則為“myData”:

[zk: localhost:2181(CONNECTED) 1] create /myZnode myData

Created /myZnode

[zk: localhost:2181(CONNECTED) 2] ls /

[myZnode, zookeeper]

刪除一個(gè)znode:

[zk: localhost:2181(CONNECTED) 3] delete /myZnode

大家可以輸入“help”命令來查看更多操作命令。在本次示例當(dāng)中,我們將使用應(yīng)用程序編程接口(簡(jiǎn)稱API)來編寫一款分布式應(yīng)用程序。

Python ZooKeeper API

我們的這套ZooKeeper服務(wù)器是由Java編程語言構(gòu)建而成,且綁定了多種由不同語言編寫而成的客戶端集合。在今天的文章中,我們將通過Kazzo這一Python捆綁客戶端來了解該API。

我們可以在虛擬環(huán)境下輕松完成Kazoo的安裝工作:

$ pip install kazoo

首先,我們需要接入一個(gè)ZooKeeper集合:

from kazoo import client as kz_client

my_client = kz_client.KazooClient(hosts='127.0.0.1:2181')

def my_listener(state):

if state == kz_client.KazooState.CONNECTED:

print("Client connected !")

my_client.add_listener(my_listener)

my_client.start(timeout=5)

在以上代碼當(dāng)中,我們利用KazooClient類創(chuàng)建了一個(gè)ZK客戶端。其中的“hosts”參數(shù)負(fù)責(zé)定義該ZK服務(wù)器地址,并以逗號(hào)加以分隔,因此如果某臺(tái)服務(wù)器出現(xiàn)故障,那么該客戶端將自動(dòng)嘗試接入其它服務(wù)器。

Kazoo能夠在連接狀態(tài)出現(xiàn)變化時(shí)向我們發(fā)出通知,根據(jù)當(dāng)前具體狀況,這項(xiàng)功能可以非常實(shí)用地觸發(fā)我們預(yù)設(shè)的各類操作。舉例來說,當(dāng)連接無法順利建立時(shí),該客戶端應(yīng)當(dāng)停止發(fā)送命令,而這正是add_listener()方法的作用所在。

而start()方法則能夠在確認(rèn)會(huì)話創(chuàng)建完畢之后,在客戶端與一臺(tái)ZK服務(wù)器之間建立起連接。每臺(tái)服務(wù)器都會(huì)追蹤每個(gè)客戶端中的一項(xiàng)會(huì)話,這種特性在實(shí)際分布式協(xié)作元方面起到非常重要的基礎(chǔ)性作用。

對(duì)znode進(jìn)行增刪改查

與znode進(jìn)行交互同樣非常簡(jiǎn)單:

# create a znode with data

my_client.create(“/my_parent_znode”)

my_client.create(“/my_parent_znode/child_1”, “child_data_1”)

my_client.create(“/my_parent_znode/child_2”, “child_data_2”)

# get the children of a znode

my_client.get_children(“/my_parent_znode”)

# get the data of a znode

my_client.get(“/my_parent_znode/child_1”)

# update a znode

my_client.set(“/my_parent_znode/child_1”, b"child_new_data_1")

# delete a znode

my_client.delete(“/my_parent_znode/child_1”)

其中set()方法會(huì)接受一條version參數(shù),而后者則允許我們執(zhí)行類似于CAS的操作,如此一來即保證了任何使用者都無法在不讀取最新版本的前提下進(jìn)行數(shù)據(jù)更新。

有時(shí)候,大家可能希望確保某個(gè)znode名稱獨(dú)一無二。我們可以通過使用連續(xù)znode(即sequential znode)的方式實(shí)現(xiàn)這項(xiàng)目標(biāo),相當(dāng)于告知服務(wù)器在每段路徑的結(jié)尾添加一個(gè)單遞增計(jì)數(shù)器。

在這一點(diǎn)上,ZooKeeper的運(yùn)作方式類似于一套普通的數(shù)據(jù)庫,不過更有趣的特性還在后面。

觀察者

觀察者機(jī)制可以算是ZooKeeper的核心功能之一,我們可以利用它對(duì)znode事件進(jìn)行通知。換句話來說,每個(gè)客戶端都能夠訂閱某個(gè)指定znode的事件,并在其狀態(tài)發(fā)生變化時(shí)得到通知。要獲取這類通知,該客戶端必須注冊(cè)一項(xiàng)回調(diào)方法——該方法在特定事件發(fā)生時(shí)即被調(diào)用(通過后臺(tái)線程)。感興趣的朋友可以點(diǎn)擊此處查看ZooKeeper所支持的各不同事件類型(英文原文)。

下面來看一段示例代碼,我們可以在某znode的子集發(fā)生變更時(shí)觸發(fā)通知機(jī)制:

def my_func(event):

# check to see what the children are now

# Set a watcher on "/my_parent_znode", call my_func() when its children change

children = zk.get_children("/my_parent_znode", watch=my_func)

值得指出的是,一旦執(zhí)行了回調(diào),客戶端就必須對(duì)其進(jìn)行重置以保證下次事件發(fā)生時(shí)能夠再次正常獲取通知。

臨時(shí)性znode

正如之前所提到,當(dāng)客戶端與服務(wù)器相對(duì)接時(shí),會(huì)建立一個(gè)會(huì)話。該會(huì)話會(huì)始終保持開啟,負(fù)責(zé)向服務(wù)器發(fā)送心跳消息。而在經(jīng)過一段時(shí)間的閑置之后,如果服務(wù)器端沒有監(jiān)聽到來自客戶端的更多活動(dòng),則該會(huì)話即被關(guān)閉。由于該會(huì)話的存在,服務(wù)器才能夠判斷目標(biāo)客戶端是否仍處于活動(dòng)狀態(tài)。

臨時(shí)性znode與正常znode沒有什么本質(zhì)區(qū)別,最大的不同在于前者會(huì)在該會(huì)話過期時(shí)被服務(wù)器所自動(dòng)釋放。

如果將觀察者與臨時(shí)性znode相結(jié)合,我們就能夠?qū)崿F(xiàn)ZooKeeper的一項(xiàng)殺手級(jí)特性。事實(shí)上,這類特性可以說為我們的分布式協(xié)作元實(shí)現(xiàn)工作帶來了數(shù)量龐大的可能性。下面我們就一起來看看分布鎖機(jī)制。

分布鎖

分布鎖應(yīng)該算是分布式應(yīng)用程序當(dāng)中出鏡頻率最高的機(jī)制了,這是因?yàn)槲覀儠?huì)經(jīng)常需要以互斥的方式訪問某些資源。

在ZooKeeper當(dāng)中,這項(xiàng)任務(wù)可以說非常輕松:

my_lock = my_client.Lock("/lockpath", "my-identifier")

with lock: # blocks waiting for lock acquisition

# do something with the lock

其涉及的API與本地鎖完全一樣,但引擎之下到底發(fā)生了什么?要找到問題的答案,我們首先來聊聊分布式算法的設(shè)計(jì)方式。

任何一種分布式算法都必須滿足兩項(xiàng)特性:安全性與活性。

其中安全性確保了該算法絕對(duì)不會(huì)偏離自己的目標(biāo),而對(duì)于分布樂來說,這意味著只有一個(gè)節(jié)點(diǎn)能夠獲得該鎖。從直觀角度講,同一時(shí)段內(nèi)不可能有兩個(gè)節(jié)點(diǎn)同時(shí)擁有分布鎖。

而活性則確保了該算法的持續(xù)遞進(jìn),在分布鎖這一場(chǎng)景當(dāng)中,這意味著如果某個(gè)節(jié)點(diǎn)嘗試獲取該鎖、那么最終一定能夠獲取到。

以本地方式實(shí)現(xiàn)鎖機(jī)制屬于眾所周知的難題,而且有大量專門作為解決方案的算法出現(xiàn)——例如Dekker算法,而且每一種現(xiàn)代編程語言都會(huì)將其囊括在標(biāo)準(zhǔn)庫當(dāng)中。不過需要強(qiáng)調(diào)的是,在分布式環(huán)境下這個(gè)問題會(huì)變得更加復(fù)雜。這兩大特性之所以難于實(shí)現(xiàn),是因?yàn)楦鱾€(gè)節(jié)點(diǎn)隨時(shí)可能出現(xiàn)故障,而這勢(shì)必造成大量可能出現(xiàn)的故障場(chǎng)景。

ZooKeeper ensures these properties for us:則能夠幫助我們確保這兩大特性:

活性的保障:將多個(gè)臨時(shí)性znode加以結(jié)合以檢測(cè)故障節(jié)點(diǎn),而觀察者機(jī)制則負(fù)責(zé)向其它節(jié)點(diǎn)發(fā)出通知。因此,如果某個(gè)節(jié)點(diǎn)獲得了分布鎖并出現(xiàn)故障,那么其它節(jié)點(diǎn)將立即識(shí)別到這一狀況。

安全性的保障:利用連續(xù)znode以確保各節(jié)點(diǎn)皆擁有彼此獨(dú)立的命名,這樣只有一個(gè)節(jié)點(diǎn)會(huì)獲得分布鎖。

我強(qiáng)烈建議大家點(diǎn)擊此處查看分布鎖說明文檔,其中提到了Kazoo的多種實(shí)現(xiàn)方式。

總結(jié)陳詞

構(gòu)建一款分布式應(yīng)用程序往往會(huì)成為一場(chǎng)令人頭痛的噩夢(mèng),因?yàn)槲覀儽仨氁A(yù)料到一切隨時(shí)可能出現(xiàn)的異常狀況(即隨機(jī)出現(xiàn)的故障),同時(shí)處理多種元素彼此組合產(chǎn)生的指數(shù)級(jí)狀況增長(zhǎng)(系統(tǒng)規(guī)模越大,狀況的具體數(shù)量也就越多)。ZooKeeper是一款非常便捷的工具,而且適合大家用于打理自己的基礎(chǔ)設(shè)施堆棧。有了它的幫助,我們可以將更多精力集中在應(yīng)用程序邏輯身上。

在OpenStack當(dāng)中,我們希望能夠充分發(fā)揮ZooKeeper的設(shè)計(jì)目標(biāo),即利用單獨(dú)一款通用型工具解決所有分布式系統(tǒng)帶來的復(fù)雜難題。因此,我們創(chuàng)建了一套名為Tooz的庫,用于實(shí)現(xiàn)一部分常見的分布式協(xié)作元。Tooz的正常運(yùn)行依賴于多種不同后端驅(qū)動(dòng)要素——ZooKeeper當(dāng)然也是其中之一——而且能夠作用于所有OpenStack項(xiàng)目當(dāng)中。

在下一篇文章中,我們將了解如何利用OpenStack Ceilometer讓Central Agent擁有出色的高可用性——其中涉及另一種重要的分布式元,即組成員(group membership)。屆時(shí)我們也將開發(fā)出自己第一款基于ZooKeeper的真正應(yīng)用程序,咱們到時(shí)候見!

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號(hào)-6京公網(wǎng)安備 11010502049343號(hào)