1. 程式人生 > >Zookeeper簡單介紹

Zookeeper簡單介紹

cnblogs enter 客戶 手動 lock 生命 block 技術分享 丟失

轉自:ZooKeeper學習第一期---Zookeeper簡單介紹

一、分布式協調技術

在給大家介紹ZooKeeper之前先來給大家介紹一種技術——分布式協調技術。那麽什麽是分布式協調技術?那麽我來告訴大家,其實分布式協調技術 主要用來解決分布式環境當中多個進程之間的同步控制,讓他們有序的去訪問某種臨界資源,防止造成"臟數據"的後果。這時,有人可能會說這個簡單,寫一個調 度算法就輕松解決了。說這句話的人,可能對分布式系統不是很了解,所以才會出現這種誤解。如果這些進程全部是跑在一臺機上的話,相對來說確實就好辦了,問 題就在於他是在一個分布式的環境下,這時問題又來了,那什麽是分布式呢?這個一兩句話我也說不清楚,但我給大家畫了一張圖希望能幫助大家理解這方面的內 容,如果覺得不對盡可拍磚,來咱們看一下這張圖,如圖1.1所示。

圖 1.1 分布式系統圖

技術分享

給大家分析一下這張圖,在這圖中有三臺機器,每臺機器各跑一個應用程序。然後我們將這三臺機器通過網絡將其連接起來,構成一個系統來為用戶提供服務,對用戶來說這個系統的架構是透明的,他感覺不到我這個系統是一個什麽樣的架構。那麽我們就可以把這種系統稱作一個分布式系統

那我們接下來再分析一下,在這個分布式系統中如何對進程進行調度,我假設在第一臺機器上掛載了一個資源,然後這三個物理分布的進程都要競爭這個資源,但我們又不希望他們同時進行訪問,這時候我們就需要一個協調器,來讓他們有序的來訪問這個資源。這個協調器就是我們經常提到的那個,比如說"進程-1"在使用該資源的時候,會先去獲得鎖,"進程1"獲得鎖以後會對該資源保持獨占

,這樣其他進程就無法訪問該資源,"進程1"用完該資源以後就將鎖釋放掉,讓其他進程來獲得鎖,那麽通過這個鎖機制,我們就能保證了分布式系統中多個進程能夠有序的訪問該臨界資源。那麽我們把這個分布式環境下的這個鎖叫作分布式鎖。這個分布式鎖也就是我們分布式協調技術實現的核心內容,那麽如何實現這個分布式呢,那就是我們後面要講的內容。

二、分布式鎖的實現

好我們知道,為了防止分布式系統中的多個進程之間相互幹擾,我們需要一種分布式協調技術來對這些進程進行調度。而這個分布式協調技術的核心就是來實現這個分布式鎖。那麽這個鎖怎麽實現呢?這實現起來確實相對來說比較困難的。

1.1 面臨的問題

在看了圖1.1所示的分布式環境之後,有人可能會感覺這不是很難。無非是將原來在同一臺機器上對進程調度的原語,通過網絡實現在分布式環境中。是的,表面上是可以這麽說。但是問題就在網絡這,在分布式系統中,所有在同一臺機器上的假設都不存在:因為網絡是不可靠的。

比如,在同一臺機器上,你對一個服務的調用如果成功,那就是成功,如果調用失敗,比如拋出異常那就是調用失敗。但是在分布式環境中,由於網絡的不可 靠,你對一個服務的調用失敗了並不表示一定是失敗的,可能是執行成功了,但是響應返回的時候失敗了。還有,A和B都去調用C服務,在時間上 A還先調用一些,B後調用,那麽最後的結果是不是一定A的請求就先於B到達呢? 這些在同一臺機器上的種種假設,我們都要重新思考,我們還要思考這些問題給我們的設計和編碼帶來了哪些影響。還有,在分布式環境中為了提升可靠性,我們往 往會部署多套服務,但是如何在多套服務中達到一致性,這在同一臺機器上多個進程之間的同步相對來說比較容易辦到,但在分布式環境中確實一個大難題。

所以分布式協調遠比在同一臺機器上對多個進程的調度要難得多,而且如果為每一個分布式應用都開發一個獨立的協調程序。一方面,協調程序的反復編寫浪 費,且難以形成通用、伸縮性好的協調器。另一方面,協調程序開銷比較大,會影響系統原有的性能。所以,急需一種高可靠、高可用的通用協調機制來用以協調分 布式應用。

1.2 分布式鎖的實現者

目前,在分布式協調技術方面做得比較好的就是Google的Chubby還有Apache的ZooKeeper他們都是分布式鎖的實現者。有人會問 既然有了Chubby為什麽還要弄一個ZooKeeper,難道Chubby做得不夠好嗎?不是這樣的,主要是Chbby是非開源的,Google自家 用。後來雅虎模仿Chubby開發出了ZooKeeper,也實現了類似的分布式鎖的功能,並且將ZooKeeper作為一種開源的程序捐獻給了 Apache,那麽這樣就可以使用ZooKeeper所提供鎖服務。而且在分布式領域久經考驗,它的可靠性,可用性都是經過理論和實踐的驗證的。所以我們 在構建一些分布式系統的時候,就可以以這類系統為起點來構建我們的系統,這將節省不少成本,而且bug也 將更少。

技術分享

技術分享

三、ZooKeeper概述

ZooKeeper是一種為分布式應用所設計的高可用、高性能且一致的開源協調服務,它提供了一項基本服務:分布式鎖服務。由於ZooKeeper的開源特性,後來我們的開發者在分布式鎖的基礎上,摸索了出了其他的使用方法:配置維護、組服務、分布式消息隊列分布式通知/協調等。

註意:ZooKeeper性能上的特點決定了它能夠用在大型的、分布式的系統當中。從可靠性方面來說,它並不會因為一個節點的錯誤而崩潰。除此之外,它嚴格的序列訪問控制意味著復雜的控制原語可以應用在客戶端上。ZooKeeper在一致性、可用性、容錯性的保證,也是ZooKeeper的成功之處,它獲得的一切成功都與它采用的協議——Zab協議是密不可分的,這些內容將會在後面介紹。

前面提到了那麽多的服務,比如分布式鎖、配置維護、組服務等,那它們是如何實現的呢,我相信這才是大家關心的東西。ZooKeeper在實現這些服務時,首先它設計一種新的數據結構——Znode,然後在該數據結構的基礎上定義了一些原語,也就是一些關於該數據結構的一些操作。有了這些數據結構和原語還不夠,因為我們的ZooKeeper是工作在一個分布式的環境下,我們的服務是通過消息以網絡的形式發送給我們的分布式應用程序,所以還需要一個通知機制——Watcher機制。那麽總結一下,ZooKeeper所提供的服務主要是通過:數據結構+原語+watcher機制,三個部分來實現的。那麽我就從這三個方面,給大家介紹一下ZooKeeper。

四、ZooKeeper數據模型

4.1 ZooKeeper數據模型Znode

ZooKeeper擁有一個層次的命名空間,這個和標準的文件系統非常相似,如下圖3.1 所示。

圖4.1 ZooKeeper數據模型與文件系統目錄樹

技術分享 技術分享

從圖中我們可以看出ZooKeeper的數據模型,在結構上和標準文件系統的非常相似,都是采用這種樹形層次結構,ZooKeeper樹中的每個節點被稱為—Znode。和文件系統的目錄樹一樣,ZooKeeper樹中的每個節點可以擁有子節點。但也有不同之處:

(1) 引用方式

Zonde通過路徑引用,如同Unix中的文件路徑。路徑必須是絕對的,因此他們必須由斜杠字符來開頭。除此以外,他們必須是唯一的,也就是說每一個路徑只有一個表示,因此這些路徑不能改變。在ZooKeeper中,路徑由Unicode字符串組成,並且有一些限制。字符串"/zookeeper"用以保存管理信息,比如關鍵配額信息。

(2) Znode結構

ZooKeeper命名空間中的Znode,兼具文件和目錄兩種特點。既像文件一樣維護著數據、元信息、ACL、時間戳等數據結構,又像目錄一樣可以作為路徑標識的一部分。圖中的每個節點稱為一個Znode。 每個Znode由3部分組成:

stat:此為狀態信息, 描述該Znode的版本, 權限等信息

data:與該Znode關聯的數據

children:該Znode下的子節點

ZooKeeper雖然可以關聯一些數據,但並沒有被設計為常規的數據庫或者大數據存儲,相反的是,它用來管理調度數據,比如分布式應用中的配置文件信息、狀態信息、匯集位置等等。這些數據的共同特性就是它們都是很小的數據,通常以KB為大小單位。ZooKeeper的服務器和客戶端都被設計為嚴格檢查並限制每個Znode的數據大小至多1M,但常規使用中應該遠小於此值。

(3) 數據訪問

ZooKeeper中的每個節點存儲的數據要被原子性的操作。也就是說讀操作將獲取與節點相關的所有數據,寫操作也將替換掉節點的所有數據。另外,每一個節點都擁有自己的ACL(訪問控制列表),這個列表規定了用戶的權限,即限定了特定用戶對目標節點可以執行的操作。

(4) 節點類型

ZooKeeper中的節點有兩種,分別為臨時節點永久節點。節點的類型在創建時即被確定,並且不能改變。

① 臨時節點:該節點的生命周期依賴於創建它們的會話。一旦會話(Session)結束,臨時節點將被自動刪除,當然可以也可以手動刪除。雖然每個臨時的Znode都會綁定到一個客戶端會話,但他們對所有的客戶端還是可見的。另外,ZooKeeper的臨時節點不允許擁有子節點。

② 永久節點:該節點的生命周期不依賴於會話,並且只有在客戶端顯示執行刪除操作的時候,他們才能被刪除。

(5) 順序節點

當創建Znode的時候,用戶可以請求在ZooKeeper的路徑結尾添加一個遞增的計數。這個計數對於此節點的父節點來說唯一的,它的格式為"%10d"(10位數字,沒有數值的數位用0補充,例如"0000000001")。當計數值大於232-1時,計數器將溢出。

(6) 觀察

客戶端可以在節點上設置watch,我們稱之為監視器。當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操作。當watch被觸發時,ZooKeeper將會向客戶端發送且僅發送一條通知,因為watch只能被觸發一次,這樣可以減少網絡流量。

4.2 ZooKeeper中的時間

ZooKeeper有多種記錄時間的形式,其中包含以下幾個主要屬性:

(1) Zxid

致使ZooKeeper節點狀態改變的每一個操作都將使節點接收到一個Zxid格式的時間戳,並且這個時間戳全局有序。也就是說,也就是說,每個對 節點的改變都將產生一個唯一的Zxid。如果Zxid1的值小於Zxid2的值,那麽Zxid1所對應的事件發生在Zxid2所對應的事件之前。實際 上,ZooKeeper的每個節點維護者三個Zxid值,為別為:cZxid、mZxid、pZxid。

cZxid: 是節點的創建時間所對應的Zxid格式時間戳。
② mZxid:是節點的修改時間所對應的Zxid格式時間戳。

實現中Zxid是一個64為的數字,它高32位是epoch用來標識leader關系是否改變,每次一個leader被選出來,它都會有一個 新的epoch。低32位是個遞增計數(2) 版本號

對節點的每一個操作都將致使這個節點的版本號增加。每個節點維護著三個版本號,他們分別為:

① version:節點數據版本號
② cversion:子節點版本號
③ aversion:節點所擁有的ACL版本號

4.3 ZooKeeper節點屬性

通過前面的介紹,我們可以了解到,一個節點自身擁有表示其狀態的許多重要屬性,如下圖所示。

圖 4.2 Znode節點屬性結構

技術分享

五、ZooKeeper服務中操作

在ZooKeeper中有9個基本操作,如下圖所示:

圖 5.1 ZooKeeper類方法描述

技術分享

更新ZooKeeper操作是有限制的。delete或setData必須明確要更新的Znode的版本號,我們可以調用exists找到。如果版本號不匹配,更新將會失敗。

更新ZooKeeper操作是非阻塞式的。因此客戶端如果失去了一個更新(由於另一個進程在同時更新這個Znode),他可以在不阻塞其他進程執行的情況下,選擇重新嘗試或進行其他操作。

盡管ZooKeeper可以被看做是一個文件系統,但是處於便利,摒棄了一些文件系統地操作原語。因為文件非常的小並且使整體讀寫的,所以不需要打開、關閉或是尋地的操作。

六、Watch觸發器

(1) watch概述

ZooKeeper可以為所有的讀操作設置watch,這些讀操作包括:exists()、getChildren()及getData()。watch事件是一次性的觸發器,當watch的對象狀態發生改變時,將會觸發此對象上watch所對應的事件。watch事件將被異步地發送給客戶端,並且ZooKeeper為watch機制提供了有序的一致性保證。理論上,客戶端接收watch事件的時間要快於其看到watch對象狀態變化的時間。

(2) watch類型

ZooKeeper所管理的watch可以分為兩類:

數據watch(data watches):getDataexists負責設置數據watch
孩子watch(child watches):getChildren負責設置孩子watch

我們可以通過操作返回的數據來設置不同的watch:

① getData和exists:返回關於節點的數據信息
② getChildren:返回孩子列表

因此

一個成功的setData操作將觸發Znode的數據watch

一個成功的create操作將觸發Znode的數據watch以及孩子watch

一個成功的delete操作將觸發Znode的數據watch以及孩子watch

(3) watch註冊與處觸發

圖 6.1 watch設置操作及相應的觸發器如圖下圖所示:

技術分享

exists操作上的watch,在被監視的Znode創建刪除數據更新時被觸發。
getData操作上的watch,在被監視的Znode刪除數據更新時被觸發。在被創建時不能被觸發,因為只有Znode一定存在,getData操作才會成功。
getChildren操作上的watch,在被監視的Znode的子節點創建刪除,或是這個Znode自身被刪除時被觸發。可以通過查看watch事件類型來區分是Znode,還是他的子節點被刪除:NodeDelete表示Znode被刪除,NodeDeletedChanged表示子節點被刪除。

Watch由客戶端所連接的ZooKeeper服務器在本地維護,因此watch可以非常容易地設置、管理和分派。當客戶端連接到一個新的服務器 時,任何的會話事件都將可能觸發watch。另外,當從服務器斷開連接的時候,watch將不會被接收。但是,當一個客戶端重新建立連接的時候,任何先前 註冊過的watch都會被重新註冊。

(4) 需要註意的幾點

Zookeeper的watch實際上要處理兩類事件:

① 連接狀態事件(type=None, path=null)

這類事件不需要註冊,也不需要我們連續觸發,我們只要處理就行了。

② 節點事件

節點的建立,刪除,數據的修改。它是one time trigger,我們需要不停的註冊觸發,還可能發生事件丟失的情況。

上面2類事件都在Watch中處理,也就是重載的process(Event event)

節點事件的觸發,通過函數exists,getData或getChildren來處理這類函數,有雙重作用:

① 註冊觸發事件

② 函數本身的功能

函數的本身的功能又可以用異步的回調函數來實現,重載processResult()過程中處理函數本身的的功能。

七、ZooKeeper應用舉例 

為了方便大家理解ZooKeeper,在此就給大家舉個例子,看看ZooKeeper是如何實現的他的服務的,我以ZooKeeper提供的基本服務分布式鎖為例。

7.1 分布式鎖應用場景

在分布式鎖服務中,有一種最典型應用場景,就是通過對集群進行Master選舉,來解決分布式系統中的單點故障。什麽是分布式系統中的單點故障:通常分布式系統采用主從模式,就是一個主控機連接多個處理節點。主節點負責分發任務,從節點負責處理任務,當我們的主節點發生故障時,那麽整個系統就都癱瘓了,那麽我們把這種故障叫作單點故障。如下圖7.1和7.2所示:

圖 7.1 主從模式分布式系統 圖7.2 單點故障

技術分享 技術分享

7.2 傳統解決方案

傳統方式是采用一個備用節點,這個備用節點定期給當前主節點發送ping包,主節點收到ping包以後向備用節點發送回復Ack,當備用節點收到回復的時候就會認為當前主節點還活著,讓他繼續提供服務。如圖7.3所示:

圖 7.3 傳統解決方案

技術分享

當主節點掛了,這時候備用節點收不到回復了,然後他就認為主節點掛了接替他成為主節點如下圖7.4所示:

圖 7.4傳統解決方案

技術分享

但是這種方式就是有一個隱患,就是網絡問題,來看一網絡問題會造成什麽後果,如下圖7.5所示:

圖 7.5 網絡故障

技術分享

也就是說我們的主節點的並沒有掛,只是在回復的時候網絡發生故障,這樣我們的備用節點同樣收不到回復,就會認為主節點掛了,然後備用節點將他的Master實例啟動起來,這樣我們的分布式系統當中就有了兩個主節點也就是---雙Master, 出現Master以後我們的從節點就會將它所做的事一部分匯報給了主節點,一部分匯報給了從節點,這樣服務就全亂了。為了防止出現這種情況,我們引入了 ZooKeeper,它雖然不能避免網絡故障,但它能夠保證每時每刻只有一個Master。我麽來看一下ZooKeeper是如何實現的。

7.3 ZooKeeper解決方案

(1) Master啟動

在引入了Zookeeper以後我們啟動了兩個主節點,"主節點-A"和"主節點-B"他們啟動以後,都向ZooKeeper去註冊一個節點。我們 假設"主節點-A"鎖註冊地節點是"master-00001","主節點-B"註冊的節點是"master-00002",註冊完以後進行選舉,編號最 小的節點將在選舉中獲勝獲得鎖成為主節點,也就是我們的"主節點-A"將會獲得鎖成為主節點,然後"主節點-B"將被阻塞成為一個備用節點。那麽,通過這 種方式就完成了對兩個Master進程的調度。

圖7.6 ZooKeeper Master選舉

技術分享

(2) Master故障

如果"主節點-A"掛了,這時候他所註冊的節點將被自動刪除,ZooKeeper會自動感知節點的變化,然後再次發出選舉,這時候"主節點-B"將在選舉中獲勝,替代"主節點-A"成為主節點。

圖7.7 ZooKeeper Master選舉

技術分享

(3) Master 恢復

圖7.8 ZooKeeper Master選舉

技術分享

如果主節點恢復了,他會再次向ZooKeeper註冊一個節點,這時候他註冊的節點將會是"master-00003",ZooKeeper會感知節點的變化再次發動選舉,這時候"主節點-B"在選舉中會再次獲勝繼續擔任"主節點","主節點-A"會擔任備用節點。

如果,您認為閱讀這篇博客讓您有些收獲,不妨點擊一下右下角的【推薦】。
如果,您希望更容易地發現我的新博客,不妨點擊一下左下角的【關註我】。
如果,您對我的博客所講述的內容有興趣,請繼續關註我的後續博客,我是【Sunddenly】。

本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。

Zookeeper簡單介紹