ZooKeeper---譯名為“動物園管理員”。動物園裡當然有好多的動物，遊客可以根據動物園提供的嚮導圖到不同的場館觀賞各種型別的動物，而不是像走在原始叢林裡，心驚膽顫的被動 物所觀賞。為了讓各種不同的動物呆在它們應該呆的地方，而不是相互串門，或是相互廝殺，就需要動物園管理員按照動物的各種習性加以分類和管理，這樣我們才能更加放心安全的觀賞動物。

回到企業級應用系統中，隨著資訊化水平的不斷提高，企業級系統變得越來越龐大臃腫，效能急劇下降，客戶抱怨頻頻。拆分系統是目前我們可選擇的解決系統可伸縮性和效能問題的唯一行之有效的方法。但是拆分系統同時也帶來了系統的複雜性——各子系統不是孤立存在的，它們彼此之間需要協作和互動，這就是我們常說的分散式系統0。各個子系統就好比動物園裡的動物，為了使各個子系統能正常為使用者提供統一

Zookeeper的設計目的

我們知道要寫一個分散式應用是非常困難的，主要原因就是區域性故障。一個訊息通過網路在兩個節點之間傳遞時，網路如果發生故障，傳送方並不知道接收方是否接收到了這個訊息。他可能在網路故障遷就收到了此訊息，也坑沒有收到，又或者可能接收方的程序死了。傳送方瞭解情況的唯一方法就是再次連線傳送方，並向他進行詢問。這就是區域性故障：根本不知道操作是否失敗。因此，大部分分散式應用需要一個主控、協調控制器來管理物理分佈的子程序。目前，大部分應用需要開發私有的協調程式，缺乏一個通用的機制。協調程式的反覆編寫浪費，且難以形成通用、伸縮性好的協調器。協調服務非常容易出錯，並很難從故障中恢復。例如：協調服務很容易處於競態1甚至死鎖2。Zookeeper的設計目的，是為了減輕分散式應用程式所承擔的協調任務。

Zookeeper並不能阻止區域性故障的發生，因為它們的本質是分散式系統。他當然也不會隱藏區域性故障。ZooKeeper的目的就是提供一些工具集，用來建立安全處理區域性故障的分散式應用。
ZooKeeper是一個分散式小檔案系統，並且被設計為高可用性。通過選舉演算法和叢集複製可以避免單點故障3，由於是檔案系統，所以即使所有的ZooKeeper節點全部掛掉，資料也不會丟失，重啟伺服器之後，資料即可恢復。另外ZooKeeper的節點更新是原子的，也就是說更新不是成功就是失敗。通過版本號，ZooKeeper實現了更新的樂觀鎖4，當版本號不相符時，則表示待更新的節點已經被其他客戶端提前更新了，而當前的整個更新操作將全部失敗。當然所有的一切ZooKeeper已經為開發者提供了保障，我們需要做的只是呼叫API。與此同時，隨著分散式應用的的不斷深入，需要對叢集管理逐步透明化監控叢集和作業狀態，可以充分利ZK的獨有特性。

Zookeeper簡介

①Zookeeper是Google的Chubby一個開源的實現，是Hadoop的分散式協調服務
   ②它包含一個簡單的原語集，分散式應用程式可以基於它實現同步服務，配置維護和命名維護等
   ③它的檔案系統使用了我們所熟悉的目錄樹結構。
   ④Zookeeper的設計目的是為了減輕分散式應用程式所承擔的協調任務

Zookeeper叢集

ZK叢集如下圖2.1所示。這是實際應用的一個場景，該ZooKeeper叢集當中一共有5臺伺服器，有兩種角色Leader和Follwer，5臺伺服器連通在一起，客戶端有分別連在不同的ZK伺服器上。如果當資料通過客戶端1，在左邊第一臺Follower伺服器上做了一次資料變更，他會把這個資料的變化同步到其他所有的伺服器，同步結束之後，那麼其他的客戶端都會獲得這個資料的變化。

注意：

通常Zookeeper由2n+1臺servers組成，每個server都知道彼此的存在。每個server都維護的記憶體狀態映象以及持久化儲存的事務日誌和快照。為了保證Leader選舉能過得到多數的支援，所以ZooKeeper叢集的數量一般為奇數。對於2n+1臺server，只要有n+1臺（大多數）server可用，整個系統保持可用。

2.3.1 叢集中的角色

在ZooKeeper叢集當中，叢集中的伺服器角色有兩種Leader和Learner，Learner角色又分為Observer和Follower，具體功能如下：

1.領導者(leader)，負責進行投票的發起和決議，更新系統狀態

2.學習者(learner)，包括跟隨者（follower）和觀察者（observer），

3.follower用於接受客戶端請求並向客戶端返回結果，在選主過程中參與投票

4.Observer可以接受客戶端請求，將寫請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是為了擴充套件系統，提高讀取速度。

5. 客戶端(client)，請求發起方

        org.apache.zookeeper.CreateMode中定義了四種節點型別，分別對應：

        PERSISTENT：永久節點

        EPHEMERAL：臨時節點

        PERSISTENT_SEQUENTIAL：永久節點、序列化

        EPHEMERAL_SEQUENTIAL：臨時節點、序列化

    一旦與ZooKeeper伺服器連線成功，伺服器會建立與客戶端的一個新的對話。每個回話都有超時時段，這是應用程式在建立它時設定      的。如果伺服器沒有在超時時段內得到請求，他可能會中斷這個會話。一旦會話被中斷了，他可能不再被開啟，而且任何與會話相連線     的臨時節點都將丟失。

    無論什麼時候會話持續空閒長達一定時間，都會由客戶端傳送ping請求保持活躍（猶如心跳）。時間段要足夠小以監測伺服器故障（由    讀操作超時反應），並且能再回話超市時間段內重新連線到另一個伺服器。

    在ZooKeeper中有幾個time引數。tick time是ZooKeeper中的基本時間長度，為ensemble裡的伺服器所使用，用來定義對於互動執行的    排程。其他設定以tick time的名義定義，或者至少由它來約束。

    建立更復雜的臨時性狀態的應用程式應該支援更長的會話超時，因為重新構建的代價會更昂貴。在一些情況下，我們可以讓應用程式在    一定會話時間內能夠重啟，並且避免會話過期。（這可能更適合執行維護或是升級）每個會話都由伺服器給定一個唯一的身份和密碼，    而且如果是在建立連線時被傳遞給ZooKeeper的話，只要沒有過期它能夠恢復會話。

    這些特性可以視為一種可以避免會話過期的優化，但它並不能代替用來處理會話過期。會話過期可能出現在機器突然故障時，或是由於    任何原因導致的應用程式安全關閉了，但在會話中斷前沒有重啟。

讀操作exists、getChildren和getData都被設定了watch，並且這些watch都由寫操作來觸發：create、delete和setData。ACL操作並不參與到watch中。當watch被觸發時，watch事件被生成，他的型別由watch和觸發他的操作共同決定。ZooKeeper所管理的watch可以分為兩類：

1.資料watch（data watches）：getData和exists負責設定資料watch；

2.孩子watch（child watches）：getChildren負責設定孩子watch；

我們可以通過操作返回的資料來設定不同的watch：

1.getData和exists：返回關於節點的資料資訊

2.getChildren：返回孩子列表

因此，一個成功的setData操作將觸發Znode的資料watch。

一個成功的create操作將觸發Znode的資料watch以及孩子watch。

一個成功的delete操作將觸發Znode的資料watch以及孩子watch。

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

exists操作上的watch，在被監視的Znode建立、刪除或資料更新時被觸發。

getData操作上的watch，在被監視的Znode刪除或資料更新時被觸發。在被建立時不能被觸發，因為只有Znode一定存在，getData操作才會成功。

getChildren操作上的watch，在被監視的Znode的子節點建立或刪除，或是這個Znode自身被刪除時被觸發。可以通過檢視watch事件型別來區分是Znode還是他的子節點被刪除：NodeDelete表示Znode被刪除，NodeDeletedChanged表示子節點被刪除。

watch設定操作及相應的觸發器如圖下圖所示：

watch事件包括了事件所涉及的Znode的路徑，因此對於NodeCreated和NodeDeleted事件來說，根據路徑就可以簡單區分出是哪個Znode被建立或是被刪除了。為了查詢在NodeChildrenChanged事件後哪個子節點被改變了，需要再次呼叫getChildren來獲得新的children列表。同樣的，為了查詢NodeDeletedChanged事件後產生的新資料，需要呼叫getData。在兩種情況下，Znode可能在獲取watch事件或執行讀操作這兩種狀態下切換，在寫應用程式時，必須記住這一點。

（1）Zookeeper的watch實際上要處理兩類事件：

1. 連線狀態事件(type=None, path=null)

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

2. 節點事件

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

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

（2）節點事件的觸發，通過函式exists,getData或getChildren來處理

這類函式，有雙重作用：

1. 註冊觸發事件

2. 函式本身的功能

函式的本身的功能又可以用非同步的回撥函式來實現,過載processResult()過程中處理函式本身的的功能。

函式還可以指定自己的watch,所以每個函式都有4個版本。根據自己的需要來選擇不同的函式，不同的版本。

3.3 ZooKeeper訪問控制列表ACL

ZooKeeper使用ACL來對Znode進行訪問控制。ACL的實現和Unix檔案訪問許可非常相似：它使用許可位來對一個節點的不同操作進行允許或禁止的許可權控制。但是，和標準的Unix許可不同的是，Zookeeper對於使用者類別的區分，不止侷限於所有者(owner)、組 (group)、所有人(world)三個級別。Zookeeper中，資料節點沒有“所有者”的概念。訪問者利用id標識自己的身份，並獲得與之相應的 不同的訪問許可權。

注意：

傳統的檔案系統中，ACL分為兩個維度，一個是屬組，一個是許可權，子目錄/檔案預設繼承父目錄的ACL。而在Zookeeper中一個ACL和一個ZooKeeper節點相對應。並且，父節點的ACL與子節點的ACL是相互獨立的。也就是說，ACL不能被子節點所繼承，父節點所擁有的許可權與子節點所用的許可權都沒有任何關係。

Zookeeper支援可配置的認證機制。它利用一個三元組來定義客戶端的訪問許可權：(scheme:expression, perms) 。其中：

1.scheme：定義了expression的含義。

如：（host:host1.corp.com，READ）,標識了一個名為host1.corp.com的主機,有該資料節點的讀許可權。

2.Perms：標識了操作許可權。

如：（ip:19.22.0.0/16, READ）,表示IP地址以19.22開頭的主機,有該資料節點的讀許可權。

Zookeeper的ACL也可以從三個維度來理解：一是，scheme; 二是，user; 三是，permission，通常表示為scheme:id:permissions，如下圖所示。

1.world : id格式：anyone。

如：world:anyone代表任何人，zookeeper中對所有人有許可權的結點就是屬於world:anyone的。

2.auth : 它不需要id。

注：只要是通過authentication的user都有許可權，zookeeper支援通過kerberos來進行認證, 也支援username/password形式的認證。

3.digest: id格式：username:BASE64(SHA1(password))。

它需要先通過username:password形式的authentication。

4.ip: id格式：客戶機的IP地址。

設定的時候可以設定一個ip段。如：ip:192.168.1.0/16, 表示匹配前16個bit的IP段

5.super: 超級使用者模式。

在這種scheme情況下，對應的id擁有超級許可權，可以做任何事情

ZooKeeper許可權定義如下圖所示：

ZooKeeper內建的ACL模式如下圖所示：

當會話建立的時候，客戶端將會進行自我驗證。另外，ZooKeeper Java API支援三種標準的使用者許可權，它們分別為：

1.ZOO_PEN_ACL_UNSAFE：對於所有的ACL來說都是完全開放的，任何應用程式可以在節點上執行任何操作，比如建立、列出並刪除子節點。

2.ZOO_READ_ACL_UNSAFE：對於任意的應用程式來說，僅僅具有讀許可權。

3.ZOO_CREATOR_ALL_ACL：授予節點建立者所有許可權。需要注意的是，設定此許可權之前，建立者必須已經通了伺服器的認證。

10,ZooKeeper一致性

在ensemble中的領導者和跟隨著非常靈活，跟隨者通過更新號來滯後領導者11，結果導致了只要大部分而不是所有的ensemble中的元素確認更新，就能被提交了。對於ZooKeeper來說，一個較好的智慧模式是將客戶端連線到跟著領導者的ZooKeeper伺服器上。客戶端可能被連線到領導者上，但他不能控制它，而且在如下情況時，甚至可能不知道。參見下圖：

每一個Znode樹的更新都會給定一個唯一的全域性標識，叫zxid（表示ZooKeeper事務“ID”）。更新是被排序的，因此如果zxid的z1<z2，那麼z1就比z2先執行。對於ZooKeeper來說，這是分散式系統中排序的唯一標準。

ZooKeeper是一種高效能、可擴充套件的服務。ZooKeeper的讀寫速度非常快，並且讀的速度要比寫快。另外，在進行讀操作的時候，ZooKeeper依然能夠為舊的資料提供服務。這些都是由ZooKeeper所提供的一致性保證的，它具有如下特點：

（1）順序一致性

任何一個客戶端的更新都按他們傳送的順序排序，也就意味著如果一個客戶端將Znode z的值更新為值a，那麼在之後的操作中，他會將z更新為b，在客戶端發現z帶有值b之後，就不會再看見帶有值a的z。

（2）原子性

更新不成功就失敗，這意味著如果更新失敗了，沒有客戶端會知道。☆☆

（3）單系統映像

無論客戶端連線的是哪臺伺服器，他與系統看見的檢視一樣。這就意味著，如果一個客戶端在相同的會話時連線了一臺新的伺服器，他將不會再看見比在之前伺服器上看見的更老的系統狀態，當伺服器系統出故障，同時客戶端嘗試連線ensemble中的其他機器時，故障伺服器的後面那臺機器將不會接受連線，直到它連線到故障伺服器。

（4）容錯性

一旦更新成功後，那麼在客戶端再次更新他之前，他就固定了，將不再被修改，這就會保證產生下面兩種結果：

如果客戶端成功的獲得了正確的返回程式碼，那麼說明更新已經成功。如果不能夠獲得返回程式碼（由於通訊錯誤、超時等原因），那麼客戶端將不知道更新是否生效。

當故障恢復的時候，任何客戶端能夠看到的執行成功的更新操作將不會回滾。

（5）實時性

在任何客戶端的系統檢視上的的時間間隔是有限的，因此他在超過幾十秒的時間內部會過期。這就意味著，伺服器不會讓客戶端看一些過時的資料，而是關閉，強制客戶端轉到一個更新的伺服器上。

解釋一下：

由於效能原因，讀操作由ZooKeeper伺服器的記憶體提供，而且不參與寫操作的全域性排序。這一特性可能會導致來自使用ZooKeeper外部機制交流的客戶端與ZooKeeper狀態的不一致。舉例來說，客戶端A將Znode z的值a更新為a'，A讓B來讀z，B讀到z的值是a而不是a’。這與ZooKeeper的保證機制是相容的（不允許的情況較作“同步一致的交叉客戶端視 圖”）。為了避免這種情況的發生，B在讀取z的值之前，應該先呼叫z上的sync。Sync操作強制B連線上的ZooKeeper伺服器與leader保 持一致這樣，當B讀到z的值時，他將成為A設定的值（或是之後的值）

容易混淆的是：

sync操作只能被非同步呼叫12。這樣操作的原因是你不需要等待他的返回，因為ZooKeeper保證了任何接下去的操作將會發生在sync在伺服器上執行以後，即使操作是在sync完成前被呼叫的。

這些已執行的保證後，ZooKeeper更高階功能的設計與實現將會變得非常容易，例如：leader選舉、佇列，以及可撤銷鎖等機制的實現。