分布式協(xié)調技術

在學習ZooKeeper之前需要先了解一種技術——分布式協(xié)調技術。那么什么是分布式協(xié)調技術？其實分布式協(xié)調技術主要用來解決分布式環(huán)境當中多個進程之間的同步控制，讓他們有序的去訪問某種臨界資源，防止造成"臟數(shù)據(jù)"的后果。這時，有人可能會說這個簡單，寫一個調度算法就輕松解決了。說這句話的人，可能對分布式系統(tǒng)不是很了解，所以才會出現(xiàn)這種誤解。如果這些進程全部是跑在一臺機上的話，相對來說確實就好辦了，問 題就在于他是在一個分布式的環(huán)境下，這時問題又來了，那什么是分布式呢？可以通過下面這張圖幫助大家理解這方面的內容，如下圖所示。

　　給大家分析一下這張圖，在這圖中有三臺機器，每臺機器各跑一個應用程序。然后我們將這三臺機器通過網(wǎng)絡將其連接起來，構成一個系統(tǒng)來為用戶提供服務，對用戶來說這個系統(tǒng)的架構是透明的，他感覺不到我這個系統(tǒng)是一個什么樣的架構。那么我們就可以把這種系統(tǒng)稱作一個分布式系統(tǒng)。
　　那我們接下來再分析一下，在這個分布式系統(tǒng)中如何對進程進行調度，我假設在第一臺機器上掛載了一個資源，然后這三個物理分布的進程都要競爭這個資源，但我們又不希望他們同時進行訪問，這時候我們就需要一個協(xié)調器，來讓他們有序的來訪問這個資源。這個協(xié)調器就是我們經(jīng)常提到的那個鎖，比如說"進程A"在使用該資源的時候，會先去獲得鎖，"進程A"獲得鎖以后會對該資源保持獨占，這樣其他進程就無法訪問該資源，"進程A"用完該資源以后就將鎖釋放掉，讓其他進程來獲得鎖，那么通過這個鎖機制，我們就能保證了分布式系統(tǒng)中多個進程能夠有序的訪問該臨界資源。那么我們把這個分布式環(huán)境下的這個鎖叫作分布式鎖。這個分布式鎖也就是我們分布式協(xié)調技術實現(xiàn)的核心內容，那么如何實現(xiàn)這個分布式呢，那就是我們后面要講的內容。

分布式鎖的實現(xiàn)

面臨的問題

在看了上圖所示的分布式環(huán)境之后，有人可能會感覺這不是很難。無非是將原來在同一臺機器上對進程調度的原語，通過網(wǎng)絡實現(xiàn)在分布式環(huán)境中。是的，表面上是可以這么說。但是問題就在網(wǎng)絡這，在分布式系統(tǒng)中，所有在同一臺機器上的假設都不存在：因為網(wǎng)絡是不可靠的。
　　比如，在同一臺機器上，你對一個服務的調用如果成功，那就是成功，如果調用失敗，比如拋出異常那就是調用失敗。但是在分布式環(huán)境中，由于網(wǎng)絡的不可靠，你對一個服務的調用失敗了并不表示一定是失敗的，可能是執(zhí)行成功了，但是響應返回的時候失敗了。還有，A和B都去調用C服務，在時間上 A還先調用一些，B后調用，那么最后的結果是不是一定A的請求就先于B到達呢？ 這些在同一臺機器上的種種假設，我們都要重新思考，我們還要思考這些問題給我們的設計和編碼帶來了哪些影響。還有，在分布式環(huán)境中為了提升可靠性，我們往往會部署多套服務，但是如何在多套服務中達到一致性，這在同一臺機器上多個進程之間的同步相對來說比較容易辦到，但在分布式環(huán)境中確實一個大難題。
　　所以分布式協(xié)調遠比在同一臺機器上對多個進程的調度要難得多，而且如果為每一個分布式應用都開發(fā)一個獨立的協(xié)調程序。一方面，協(xié)調程序的反復編寫浪費，且難以形成通用、伸縮性好的協(xié)調器。另一方面，協(xié)調程序開銷比較大，會影響系統(tǒng)原有的性能。所以，急需一種高可靠、高可用的通用協(xié)調機制來用以協(xié)調分布式應用。

分布式鎖的實現(xiàn)者

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

Zookeeper介紹

ZooKeeper 是分布式應用程序的分布式開源協(xié)調服務。它公開了一組簡單的原語，分布式應用程序可以基于這些原語實現(xiàn)更高級別的同步、配置維護、組和命名服務等。它被設計為易于編程，并使用一種數(shù)據(jù)模型，該模型以熟悉的文件系統(tǒng)目錄樹結構為風格。它在 Java 中運行，并具有 Java 和 C 的綁定。眾所周知，協(xié)調服務很難做好。它們特別容易出現(xiàn)競爭條件和死鎖等錯誤。ZooKeeper背后的動機是減輕分布式應用程序從頭開始實現(xiàn)協(xié)調服務的責任。

設計目標

ZooKeeper 很簡單。ZooKeeper 允許分布式進程通過共享的分層命名空間相互協(xié)調，該命名空間的組織方式類似于標準文件系統(tǒng)。命名空間由數(shù)據(jù)寄存器組成——在 ZooKeeper 用語中稱為 znodes——它們類似于文件和目錄。然后在該數(shù)據(jù)結構的基礎上定義了一些原語，也就是一些關于該數(shù)據(jù)結構的一些操作。有了這些數(shù)據(jù)結構和原語還不夠，因為我們的ZooKeeper是工作在一個分布式的環(huán)境下，我們的服務是通過消息以網(wǎng)絡的形式發(fā)送給我們的分布式應用程序，所以還需要一個通知機制——Watcher機制。綜上，ZooKeeper所提供的服務主要是通過：數(shù)據(jù)結構+原語+watcher機制，三個部分來實現(xiàn)的。與為存儲而設計的典型文件系統(tǒng)不同，ZooKeeper 數(shù)據(jù)保存在內存中，這意味著 ZooKeeper 可以實現(xiàn)高吞吐量和低延遲數(shù)字。

ZooKeeper 實施非常重視高性能、高可用性、嚴格有序的訪問。ZooKeeper 的性能方面意味著它可以用于大型分布式系統(tǒng)。可靠性方面使其不會成為單點故障。嚴格的排序意味著可以在客戶端實現(xiàn)復雜的同步原語。

ZooKeeper 被復制。與它協(xié)調的分布式進程一樣，ZooKeeper 本身旨在通過一組稱為 ensemble 的主機進行復制。

組成 ZooKeeper 服務的服務器必須相互了解。它們在內存中維護狀態(tài)圖像，以及持久存儲中的事務日志和快照。只要大多數(shù)服務器可用，ZooKeeper 服務就可用。

客戶端連接到單個 ZooKeeper 服務器?？蛻舳司S護一個 TCP 連接，通過它發(fā)送請求、獲取響應、獲取監(jiān)視事件并發(fā)送心跳。如果與服務器的 TCP 連接中斷，客戶端將連接到不同的服務器。

ZooKeeper 已訂購。ZooKeeper 使用反映所有 ZooKeeper 事務順序的數(shù)字標記每個更新。后續(xù)操作可以使用該順序來實現(xiàn)更高級別的抽象，例如同步原語。

ZooKeeper 速度很快。它在“以讀取為主”的工作負載中尤其快。ZooKeeper 應用程序在數(shù)千臺機器上運行，它在讀取比寫入更常見的情況下表現(xiàn)最佳，比率約為 10:1。

zookeeper數(shù)據(jù)模型和分層命名空間

ZooKeeper 提供的命名空間很像標準文件系統(tǒng)。名稱是由斜杠 (/) 分隔的一系列路徑元素。ZooKeeper 命名空間中的每個節(jié)點都由路徑標識。

從上圖中我們可以看出ZooKeeper的數(shù)據(jù)模型，在結構上和標準文件系統(tǒng)的非常相似，都是采用這種樹形層次結構，ZooKeeper樹中的每個節(jié)點被稱為—Znode。和文件系統(tǒng)的目錄樹一樣，ZooKeeper樹中的每個節(jié)點可以擁有子節(jié)點。但也有不同之處：
(1) 引用方式
　　Zonde通過路徑引用，如同Unix中的文件路徑。路徑必須是絕對的，因此他們必須由斜杠字符來開頭。除此以外，他們必須是唯一的，也就是說每一個路徑只有一個表示，因此這些路徑不能改變。在ZooKeeper中，路徑由Unicode字符串組成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如關鍵配額信息。

(2) Znode結構
　　ZooKeeper命名空間中的Znode，兼具文件和目錄兩種特點。既像文件一樣維護著數(shù)據(jù)、元信息、ACL、時間戳等數(shù)據(jù)結構，又像目錄一樣可以作為路徑標識的一部分。圖中的每個節(jié)點稱為一個Znode。 每個Znode由3部分組成:
　?、?stat：此為狀態(tài)信息, 描述該Znode的版本, 權限等信息
　　② data：與該Znode關聯(lián)的數(shù)據(jù)
　?、?children：該Znode下的子節(jié)點
　　ZooKeeper雖然可以關聯(lián)一些數(shù)據(jù)，但并沒有被設計為常規(guī)的數(shù)據(jù)庫或者大數(shù)據(jù)存儲，相反的是，它用來管理調度數(shù)據(jù)，比如分布式應用中的配置文件信息、狀態(tài)信息、匯集位置等等。這些數(shù)據(jù)的共同特性就是它們都是很小的數(shù)據(jù)，通常以KB為大小單位。ZooKeeper的服務器和客戶端都被設計為嚴格檢查并限制每個Znode的數(shù)據(jù)大小至多1M，但常規(guī)使用中應該遠小于此值。

(3) 數(shù)據(jù)訪問
　　ZooKeeper中的每個節(jié)點存儲的數(shù)據(jù)要被原子性的操作。也就是說讀操作將獲取與節(jié)點相關的所有數(shù)據(jù)，寫操作也將替換掉節(jié)點的所有數(shù)據(jù)。另外，每一個節(jié)點都擁有自己的ACL(訪問控制列表)，這個列表規(guī)定了用戶的權限，即限定了特定用戶對目標節(jié)點可以執(zhí)行的操作。
(4) 節(jié)點類型
　　ZooKeeper中的節(jié)點有兩種，分別為臨時節(jié)點和永久節(jié)點。節(jié)點的類型在創(chuàng)建時即被確定，并且不能改變。
　?、?臨時節(jié)點：該節(jié)點的生命周期依賴于創(chuàng)建它們的會話。一旦會話(Session)結束，臨時節(jié)點將被自動刪除，當然可以也可以手動刪除。雖然每個臨時的Znode都會綁定到一個客戶端會話，但他們對所有的客戶端還是可見的。另外，ZooKeeper的臨時節(jié)點不允許擁有子節(jié)點。
　?、?永久節(jié)點：該節(jié)點的生命周期不依賴于會話，并且只有在客戶端顯示執(zhí)行刪除操作的時候，他們才能被刪除。
(5) 順序節(jié)點
　　當創(chuàng)建Znode的時候，用戶可以請求在ZooKeeper的路徑結尾添加一個遞增的計數(shù)。這個計數(shù)對于此節(jié)點的父節(jié)點來說是唯一的，它的格式為"%10d"(10位數(shù)字，沒有數(shù)值的數(shù)位用0補充，例如"0000000001")。當計數(shù)值大于232-1時，計數(shù)器將溢出。

(6) 觀察
　　客戶端可以在節(jié)點上設置watch，我們稱之為監(jiān)視器。當節(jié)點狀態(tài)發(fā)生改變時(Znode的增、刪、改)將會觸發(fā)watch所對應的操作。當watch被觸發(fā)時，ZooKeeper將會向客戶端發(fā)送且僅發(fā)送一條通知，因為watch只能被觸發(fā)一次，這樣可以減少網(wǎng)絡流量。
3.6.0 中的新功能：客戶端還可以在 znode 上設置永久的遞歸監(jiān)??視，這些監(jiān)視在觸發(fā)時不會被刪除，并且會以遞歸方式觸發(fā)已注冊 znode 以及任何子 znode 上的更改。

ZooKeeper中的時間

致使ZooKeeper節(jié)點狀態(tài)改變的每一個操作都將使節(jié)點接收到一個Zxid格式的時間戳，并且這個時間戳全局有序。也就是說，每個對節(jié)點的改變都將產(chǎn)生一個唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所對應的事件發(fā)生在Zxid2所對應的事件之前。實際上，ZooKeeper的每個節(jié)點維護者三個Zxid值，為別為：cZxid、mZxid、pZxid。
① cZxid： 是節(jié)點的創(chuàng)建時間所對應的Zxid格式時間戳。
② mZxid：是節(jié)點的修改時間所對應的Zxid格式時間戳。
③ pZxid： 是與該節(jié)點的子節(jié)點（或該節(jié)點）的最近一次 創(chuàng)建/刪除 的時間戳對應

實現(xiàn)中Zxid是一個64為的數(shù)字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個 新的epoch。低32位是個遞增計數(shù)版本號
對節(jié)點的每一個操作都將致使這個節(jié)點的版本號增加。每個節(jié)點維護著三個版本號，他們分別為：
① version：節(jié)點數(shù)據(jù)版本號
② cversion：子節(jié)點版本號
③ aversion：節(jié)點所擁有的ACL版本號

ZooKeeper節(jié)點屬性

通過前面的介紹，我們可以了解到，一個節(jié)點自身擁有表示其狀態(tài)的許多重要屬性，如下圖所示。
Znode節(jié)點屬性結構

屬性	描述
czxid	節(jié)點被創(chuàng)建的zxid
mzxid	節(jié)點被修改的zxid .
ctime	節(jié)點被創(chuàng)建的時間
mtime	節(jié)點被修改的zxid
version	節(jié)點被修改的版本號
cversion	節(jié)點所擁有的子節(jié)點被修改的版本號
aversion	節(jié)點的ACL被修改的版本號
ephemeralowner	如果此節(jié)點為臨時節(jié)點，那么他的值為這個節(jié)點擁有者的會話ID;否則，他的值為0
dataLength	節(jié)點數(shù)長度
numChildren	節(jié)點用的子節(jié)點長度
pzxid	最新修改的zxid,貌似與mzxid重合了

ZooKeeper中的數(shù)據(jù)保證

ZooKeeper 非常快速且非常簡單。但是，由于它的目標是成為構建更復雜服務（例如同步）的基礎，因此它提供了一組保證。這些都是：

• 順序一致性 - 來自客戶端的更新將按照它們發(fā)送的順序應用。
• 原子性 - 更新成功或失敗。沒有部分結果。
• 單一系統(tǒng)映像 - 客戶端將看到相同的服務視圖，而不管它連接到的服務器如何。即，即使客戶端故障轉移到具有相同會話的不同服務器，客戶端也永遠不會看到系統(tǒng)的舊視圖。
• 可靠性 - 應用更新后，它將從那時起持續(xù)存在，直到客戶端覆蓋更新。
• 及時性——系統(tǒng)的客戶視圖保證在一定的時間范圍內是最新的。

zookeeper簡單的 API操作

ZooKeeper 的設計目標之一是提供一個非常簡單的編程接口。因此，它僅支持以下操作：
create：在樹中的某個位置創(chuàng)建一個節(jié)點
delete : 刪除一個節(jié)點
exists：測試節(jié)點是否存在于某個位置
getACL：獲取數(shù)據(jù)，從節(jié)點讀取數(shù)據(jù)
setACL：設置數(shù)據(jù)，將數(shù)據(jù)寫入節(jié)點
getChildren ：獲取子節(jié)點：檢索節(jié)點的子節(jié)點列表
sync：等待數(shù)據(jù)傳播

執(zhí)行

ZooKeeper 組件展示了 ZooKeeper 服務的高級組件。除了請求處理器之外，組成 ZooKeeper 服務的每個服務器都復制自己的每個組件的副本。

復制數(shù)據(jù)庫是包含整個數(shù)據(jù)樹的內存數(shù)據(jù)庫。更新被記錄到磁盤以便恢復，寫入在應用到內存數(shù)據(jù)庫之前被序列化到磁盤。
每個 ZooKeeper 服務器都服務于客戶端?？蛻舳藘H連接到一臺服務器以提交請求。從每個服務器數(shù)據(jù)庫的本地副本為讀取請求提供服務。改變服務狀態(tài)的請求，寫請求，由協(xié)議協(xié)議處理。
作為協(xié)議協(xié)議的一部分，來自客戶端的所有寫入請求都被轉發(fā)到單個服務器，稱為領導者。ZooKeeper 服務器的其余部分，稱為追隨者，接收來自領導者的消息提議并同意消息傳遞。消息傳遞層負責在失敗時替換領導者并將追隨者與領導者同步。

ZooKeeper 使用自定義原子消息傳遞協(xié)議。由于消息傳遞層是原子的，ZooKeeper 可以保證本地副本永遠不會發(fā)散。當領導者收到一個寫請求時，它會計算系統(tǒng)在應用寫時的狀態(tài)，并將其轉換為捕獲這個新狀態(tài)的事務。

用途
ZooKeeper 的編程接口故意簡單。但是，使用它，您可以實現(xiàn)更高階的操作，例如同步原語、組成員資格、所有權等。

ZooKeeper應用實例

為了方便大家理解ZooKeeper，用以下例子說明ZooKeeper是如何實現(xiàn)的他的服務的，以ZooKeeper提供的基本服務分布式鎖為例。

分布式鎖應用場景

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

傳統(tǒng)解決方案

傳統(tǒng)方式是采用一個備用節(jié)點，這個備用節(jié)點定期給當前主節(jié)點發(fā)送ping包，主節(jié)點收到ping包以后向備用節(jié)點發(fā)送回復Ack，當備用節(jié)點收到回復的時候就會認為當前主節(jié)點還活著，讓他繼續(xù)提供服務。如下圖所示：

而當主節(jié)點掛了，這時候備用節(jié)點收不到回復了，然后他就認為主節(jié)點掛了接替他成為主節(jié)點。如下圖所示：

但是這種方式就是有一個隱患，就是網(wǎng)絡問題，來看一網(wǎng)絡問題會造成什么后果，如下圖7.5所示：

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

ZooKeeper解決方案

Master啟動

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

Master故障

如果"主節(jié)點-A"掛了，這時候他所注冊的節(jié)點將被自動刪除，ZooKeeper會自動感知節(jié)點的變化，然后再次發(fā)出選舉，這時候"主節(jié)點-B"將在選舉中獲勝，替代"主節(jié)點-A"成為主節(jié)點。

Master 恢復

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

更多關于zookeeper的知識分享，請前往博客主頁。編寫過程中，難免出現(xiàn)差錯，敬請指出