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

譯文
作者：核子可樂譯 2015-09-28 09:46:31
云計算
分布式 ZooKeeper是一款極具實用性、現(xiàn)場測試能力并擁有廣泛用戶群體的中間件，專門用于構(gòu)建分布式應(yīng)用程序。在OpenStack當(dāng)中，ZooKeeper也成為Nova ServiceGroup API后端中的組成部分。最近，ZooKeeper還與Ceilometer相集成，從而為Central Agent帶來更為理想的高可用性水平。

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

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

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

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

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

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

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

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

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

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

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

這種架構(gòu)方案擁有以下幾項突出優(yōu)勢：

• 我們可以立足于應(yīng)用層提取大部分分布式同步負(fù)載，從而實現(xiàn)一套所謂KISS(即Keep It Simple, Stupid，保持一切簡單且具傻瓜式特性)架構(gòu)。
• 常見的各類分布式協(xié)作元能夠?qū)崿F(xiàn)開箱即用，因此開發(fā)人員無需再自行對其加以處理。
• 開發(fā)人員不需要處理服務(wù)故障等狀況，因為整套體系擁有出色的彈性。ZooKeeper以應(yīng)用程序神經(jīng)中心的姿態(tài)存在，因為它負(fù)責(zé)控制整個協(xié)作機(jī)制，因此眾多組件都需要依附于它以實現(xiàn)作用。出于這些理由，ZooKeeper在設(shè)計中引入了出色的分布式算法，從而提供開發(fā)人員所需要的高可靠性與可用性保障。一個ZooKeeper集合基于群體形式存在，且通常由三到五臺服務(wù)器構(gòu)成。

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

實踐場景中的ZooKeeper

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

首先，大家需要確保自己的運(yùn)行環(huán)境滿足系統(tǒng)配置要求，接下來我們就要著手部署一臺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)行了，且會在默認(rèn)情況下監(jiān)聽127.0.0.1：2181。如果大家需要部署一整套服務(wù)器集合，則可以點(diǎn)擊此處閱讀其相關(guān)管理指南。

ZooKeeper命令行界面

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

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

  
 
 
 

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

創(chuàng)建一個路徑為“/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] 
  
 
 
 

刪除一個znode:

  
 
 
 

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

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

Python ZooKeeper API

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

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

  
 
 
 

   
  
  
  
$ pip install kazoo 
  
 
 
 

首先，我們需要接入一個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)建了一個ZK客戶端。其中的“hosts”參數(shù)負(fù)責(zé)定義該ZK服務(wù)器地址，并以逗號加以分隔，因此如果某臺服務(wù)器出現(xiàn)故障，那么該客戶端將自動嘗試接入其它服務(wù)器。

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

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

#p#

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

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

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

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

觀察者

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

下面來看一段示例代碼，我們可以在某znode的子集發(fā)生變更時觸發(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)，客戶端就必須對其進(jìn)行重置以保證下次事件發(fā)生時能夠再次正常獲取通知。

臨時性znode

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

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

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

分布鎖

分布鎖應(yīng)該算是分布式應(yīng)用程序當(dāng)中出鏡頻率最高的機(jī)制了，這是因為我們會經(jīng)常需要以互斥的方式訪問某些資源。

在ZooKeeper當(dā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è)計方式。

任何一種分布式算法都必須滿足兩項特性：安全性與活性。

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

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

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

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

• 活性的保障：將多個臨時性znode加以結(jié)合以檢測故障節(jié)點(diǎn)，而觀察者機(jī)制則負(fù)責(zé)向其它節(jié)點(diǎn)發(fā)出通知。因此，如果某個節(jié)點(diǎn)獲得了分布鎖并出現(xiàn)故障，那么其它節(jié)點(diǎn)將立即識別到這一狀況。
• 安全性的保障：利用連續(xù)znode以確保各節(jié)點(diǎn)皆擁有彼此獨(dú)立的命名，這樣只有一個節(jié)點(diǎn)會獲得分布鎖。

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

總結(jié)陳詞

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

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

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

原文標(biāo)題：ZooKeeper Part 1: the Swiss army knife of the distributed system engineer

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】

新聞標(biāo)題：ZooKeeper解析：分布式系統(tǒng)工程師的瑞士軍刀
URL鏈接：http://www.dlmjj.cn/article/cceephi.html