簡介

Apache ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，由Client和Server構成，Server提供了一致性複製和儲存服務，Client包含一個簡單的原語集，分散式應用程式可以基於它實現同步服務，配置維護和命名服務等。ZooKeeper的設計非常易於程式設計，ZooKeeper維護著一個hierarchal（層次）的名字空間，它採用樹形的資料結構，類似於標準檔案系統。因為想要從零實現一個分散式協作服務是非常難的。最常見的問題就是競爭條件和死鎖。Apache ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。

Zookeepr的資料都存放在記憶體中（更新資料也會持久化到磁碟），所以它的吞吐量會非常高，同時延遲會很低。ZooKeeper的實現更重視high performance（高效能）, highly available（高可用性）, strictly ordered access（嚴格有序訪問）。Zookeeper效能方面的表現讓它能夠用於大型分散式系統，高可用性可以避免出現單點故障，嚴格有序訪問可以讓Client實現複雜的同步原語。

Zookeeper系統模型

上圖的哪些Server組成了Zookeeper服務，每個Server都知道彼此的存在。這些server在記憶體中保持著狀態的映象，還通過transaction logs和快照持久到硬碟中。只要叢集中多數Server可訪問，那麼ZooKeeper服務就可用。

Clients會連線到某一個ZooKeeper Server上。Client和Server保持一個TCP長連線，通過該TCP長連線，Client可以傳送請求，得到response，得到watch event，還有傳送心跳（客戶端和服務端通過心跳來保持連線，即session）。如果和Server的TCP長連線斷了，那麼Client就會連線到另外一個Server上。

Zookeeper是有序的：Zookeeper用stamps(數字)作為所有事務的順序。

Zookeeper是非常快的：特別是以讀為主的情況下，Zookeeper應用程式可以執行在數千臺機器上，它效能表現最佳的是在讀寫比率為10:1的情況下。

Zookeeper資料模型

ZooKeeper資料模型的結構與Unix檔案系統很類似，整體上可以看作是一棵樹，每個節點稱做一個ZNode。每個ZNode上可儲存少量資料(預設是1M, 可以通過配置修改, 通常不建議在ZNode上儲存大量的資料)，下面說說Zookeeper幾個比較重要的概念：

一，Znode

1，Zookeeper節點稱為Znode，每個節點都有唯一的路徑標示。Znode分類兩類：1，普通的Znode；2，ephemeral（臨時）Znode
2，Znode維護了stat結構，裡面包含資料，ACL變更的版本號，還有時間戳去允許快取驗證和協調更新。當znode的data改變了，版本號就會增加
3，Znode可以有子節點，並且Znode可以存放資料，但是ephemeral（臨時）Znode不能有子節點。
4，Znode資料可以有多個版本，客戶端可以根據版本獲取該節點的資料。
5，如果建立ephemeral（臨時）Znode的客戶端和服務端失去連線的話，那麼該零時節點也自動刪除。
6，Znode可以自動編號。
7，Znode中可以新增watch，該watch用於監控該節點儲存的資料是否有修改，子節點目錄的變化等，一旦變化可以通知設定監控的客戶端。
8，Znode的讀寫操作都具備原子性，每個Znode都有一個訪問控制列表（ACL）來控制誰能做什麼操作。

二，Session
Client與ZooKeeper之間的通訊，需要建立一個Session，這個Session會有一個超時時間。因為ZooKeeper叢集會把Client的Session資訊持久化，所以在Session沒超時之前，Client與ZooKeeper Server的連線可以在各個ZooKeeper Server之間透明地移動。
在實際的應用中，如果Client與Server之間的通訊足夠頻繁，Session的維護就不需要其它額外的訊息了。否則，ZooKeeper Client會每T/3 ms發一次心跳給Server，如果Client 2T/3 ms沒收到來自Server的心跳回應，就會換到一個新的ZooKeeper Server上。這裡T是使用者配置的Session的超時時間。

三，Watcher
ZooKeeper支援一種Watch操作，Client可以在某個ZNode上設定一個Watcher，來Watch該ZNode上的變化。如果該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設定Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即觸發一次就會被取消，如果想繼續Watch的話，需要客戶端重新設定Watcher。

四，事務日誌和快照

dataDir目錄指定了Zookeeper的資料目錄，用於儲存Zookeeper的快照檔案（snapshot）。

dataLogDir定義了Zookeeper的事務日誌目錄，目錄存放Zookeeper的事務日誌，正常情況下，所有的更新操作在返回客戶端更新成功前，Zookeeper肯定已經將本次更新操作寫入到事務日誌了（即磁碟中）。事務日誌的檔名是log.，zxid是寫入這個檔案的第一個事務id。在完成若干次事務後會一次資料快照，將當前Server上所有節點的狀態以快照檔案的形式dump到磁碟上去，即snapshot檔案。

Zookeeper角色

Zookeepr角色分可以分為四類：

Server的狀態可以分為如下四種：

leading：當前Server為Leader。

following：當前Server為Follower。

observing：當前Server為Observer。

looking：當前Server不知道leader是誰，正在搜尋。

Zookeeper特性

順序一致性：按照客戶端傳送請求的順序更新資料。Zookeeper是不屬於強一致性，因為watcher沒辦法撲捉到每次的變化。
原子性：更新要麼成功，要麼失敗，不會出現部分更新。
單一系統映像 ：無論客戶端連線哪個server，都會看到同一個檢視。
可靠性：具有簡單、健壯、良好的效能，如果訊息被到一臺伺服器接受，那麼它將被所有的伺服器接受。
時效性：Zookeeper保證客戶端將在一個時間間隔範圍內獲得伺服器的更新資料，或者伺服器失效的資訊。但由於網路延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的資料，如果需要最新資料，應該在讀資料之前呼叫sync()介面。

ZooKeeper原理

Zookeeper的核心是原子廣播，通過Zab協議保證各個Server之間資料的同步。Zab協議有兩種模式，分別是恢復模式（選舉Leader）和廣播模式（同步）。服務啟動或者Leader崩潰後，Zab就會進入了恢復模式，當Leader被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了Leader和Server具有相同的系統狀態。

為了保證事務的順序一致性，Zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。

每個Server在工作過程中有四種狀態：
    LOOKING：當前Server不知道leader是誰，正在搜尋。
    LEADING：當前Server即為選舉出來的leader。
    FOLLOWING：leader已經選舉出來，當前Server與之同步。
    OBSERVING：不選舉，只從Leader同步狀態。

Zookeeper API

Zookeeper的一個設計目標是提供簡單的程式設計介面，僅僅支援如下操作：

create：建立一個Znode。path是其路徑，data是要儲存在該Znode上的資料，createMode包括：PERSISTEN，PERSISTENT_SEQUENTAIL，EPHEMERAL，EPHEMERAL_SEQUENTAIL。

delete：刪除一個Znode。可以刪除指定版本的Znode，如果version設定為-1的話，就刪除所有的版本。

exists：判斷Znode是否存在，設定是否Watch這個Znode。

get data：讀取指定Znode上的資料，並設定是否watch這個Znode。

set data：更新指定Znode的資料，並設定是否Watch這個Znode。

get children：更新指定ZNode的資料，並設定是否Watch這個Znode。

sync：把sync之前的更新操作都同步過來。

set acl：設定指定ZNode的Acl資訊

get acl：獲取指定ZNode的Acl資訊

其他

讀、寫(更新)模式：
Zookeeper叢集中，客戶端可以從任意一個ZooKeeper伺服器讀取，這一特點保證了ZooKeeper有比較好的讀效能；

寫的請求會先Forwarder到Leader，然後由Leader來通過ZooKeeper中的原子廣播協議，將請求廣播給所有的Follower，Leader收到一半以上的寫成功的Ack後，就認為該寫成功了，就會將該寫進行持久化，並告訴客戶端寫成功了。

WAL(Write-Ahead-Log)和Snapshot：
ZooKeeper也有WAL，每一個更新操作，ZooKeeper都會先寫WAL，然後再對記憶體中的資料做更新，最後向Client通知更新結果。

ZooKeeper還會定期將記憶體中的目錄樹進行Snapshot，落地到磁碟上。其實跟HDFS中的fsimage和edits log是類似的。這麼做的主要目的，一當然是資料的持久化，二是加快重啟之後的恢復速度，如果全部通過Replay WAL的形式恢復的話，會比較慢。

FIFO：
對於每一個ZooKeeper客戶端而言，所有的操作都是遵循FIFO順序的，這一特性是由下面兩個基本特性來保證的：

一是ZooKeeper Client與Server之間的網路通訊是基於TCP，TCP保證了Client/Server之間傳輸包的順序；

二是ZooKeeper Server執行客戶端請求也是嚴格按照FIFO順序的。

線性化：
ZooKeeper包括全域性有序和偏序兩種：

全域性有序是針對伺服器端。例如：在一臺伺服器上訊息A在訊息B前釋出，那麼所有伺服器上的訊息A都將在訊息B前被髮布；

偏序是針對客戶端。例如：在同一個客戶端傳送訊息B在訊息A後釋出，那麼執行的順序必將是先執行訊息A然後在是訊息B；

所有的更新操作都有嚴格的偏序關係，更新操作都是序列執行的，這一點是保證ZooKeeper功能正確性的關鍵。

使用場景

1，資料釋出與訂閱

2，名空間服務

3，分散式通知/協調

4，分散式鎖

5，叢集管理

等等。。。

參考：