本文的Zookeeper是3.6版本的
定義
Zookeeper是一個經典的分佈式一致性解決方案，致力於爲分佈式應用提供一個高性能，高可用、且具有嚴格順序訪問控制能力的分佈式協調存儲服務。
ZooKeeper並非設計爲通用數據庫或大型對象存儲。相反，它管理協調數據。這些數據可以採用配置，狀態信息，集合點等形式。各種形式的協調數據的共同屬性是它們相對較小：以千字節爲單位。ZooKeeper客戶端和服務器實現具有健全性檢查，以確保znode的數據少於1M，但數據應比平均少得多。對相對大的數據量進行操作將導致某些操作比其他操作花費更多的時間，並且會影響某些操作的延遲，因爲需要更多時間才能通過網絡將更多數據移動到存儲介質上。如果需要大數據存儲，則處理此類數據的通常方式是將其存儲在大容量存儲系統上，
高性能：Zookeeper將全量數據存儲在內存中，並直接服務於客戶端的所有非事務請求。尤其適合以讀爲主的場景。
高可用：Zookeeper一般以集羣的方式對外提供服務，一般3-5臺機器便可組成一個集羣。每臺機器的Zookeeper服務都會在內存中維持自身的服務狀態。並且服務之間都相互保持通信。只要集羣中超過一半的Zookeeper服務能夠對外服務。那麼整個集羣就可以對外提供服務。
嚴格順序訪問：對於客戶端的每個更新請求。Zookeeper都會分配一個全局唯一的遞增編號。這個編號反映了所有事務操作執行的先後順序。
Zookeeper是一個開源的分佈式的，爲分佈式應用提供協調服務的Apache項目。
Zookeeper的工作機制
Zookeeper從設計模式的角度理解，是一個基於觀察者模式設計的分佈式服務管理框架。它負責存儲我們關心的數據，然後接收觀察者的註冊，在數據發生變化時，Zookeeper就負責通知已經在Zookeeper上註冊的那些觀察者做出相應的動作。從而實現集羣中類似master/slave的管理模式。
場景
- 統一命名服務
在分佈式環境下，經常需要對應用服務進行統一命名，便於標識，比如用ip標記服務不易記住，用域名或者特定名字就比較容易。 - 維護統一配置信息
java編程經常會遇到需要配置文件進行配置的情況，比如數據庫mysql配置，redis配置，mq配置等。我們通常把這些配置文件放置在相應的服務器上，當需要更改配置時，就去對應的服務器上修改。但隨着分佈式系統的興起。可能很多服務都需要用到該配置文件。如果把配置分散到各個進行集羣的服務中，當集羣大到一定程度時（成百上千，上萬），每當需要修改配置文件時，就要上每一臺服務器上修改。這將是非常繁瑣且危險的事情。因此，需要一種服務，能夠快速高效且可靠地完成配置的更改等操作，並且需要保證各個配置項在每臺服務器上的數據一致性。
Zookeeper提供的就可以這樣的一種服務，使用Zab協議來保證數據的一致性。現在很多開源項目都使用Zookeeper來維護配置，比如dubbo使用Zookeeper來實現服務的註冊中心來實現服務治理。 - 分佈式鎖服務
在一個分佈式應用集羣中，由多臺服務器組成，爲了提高併發度和可靠性，多臺服務器運行着同一種服務。當多個服務運行時就需要協調各服務的進度。有時候需要保證其中一個服務進行某種操作時，其他服務在此期間不能進行該操作。即對該操作加鎖。當該機器掛掉後，釋放鎖並且fail over到其他機器繼續執行該服務。 - 集羣管理
一個集羣有時會因爲軟件和硬件或者網絡故障等因素，出現某些服務掛掉而被移除出集羣，並且還要某些服務加到集羣的情況，Zookeeper會將這些服務加入/移除的情況通知給集羣中其他正常工作的服務器。以及時調整存儲和計算等資源的分配。 - 生成分佈式唯一ID
以前單庫單表型系統時，可以使用數據庫字段自帶的自增機制實現唯一的記錄id。但是在分庫分表後，就無法使用數據庫字段自帶的自增機制來實現了。此時可以使用Zookeeper在分佈式環境下生成全局唯一ID。大致做法：每次要生成一個唯一ID時，創建一個持久的順序的節點。創建的新節點的序號就是新的唯一id，然後把比自己小的id刪除即可。
Zookeeper的數據模型
Zookeeper的數據是以節點爲單位存儲的，就是一個節點存儲着一個數據，節點稱爲znode。節點間維護着一個樹狀結構，類似於unix系統的目錄系統。一個節點可以有多個子節點， 但是隻能有一個父節點。使用路徑path來定位某個節點。
- 會有一個根節點，類似於unix系統的文件根目錄/，也是用正斜槓/表示。
- 對節點的訪問必須使用絕對路徑，不能使用相對路徑。也沒得來相對…。
- /aa定位的是aa節點，/aa/aa1 、/aa/aa2、 /bb 、 /bb/bb1分別訪問的是aa1、aa2、bb、bb1節點。不同父節點的子節點節點名可以相同，只要全路徑不一樣就可以。
- Zookeeper的數據模型有點類比於unix文件系統，節點類比文件，節點數據類比文件內容，節點acl權限類比文件權限。還有其他元數據，比如創建時間，最後一次修改時間等。
節點的組成部分
一個Zookeeper節點znode大致上可以分爲三個部分：
- 節點數據：就是該節點上存儲的數據，類似於K/V數據模型情況下，節點就是K，全局唯一、V就表示節點上的數據。
- 節點的子節點。
- 節點的狀態stat，來描述當前節點創建，修改記錄、權限等元信息。
stat屬性說明：
| 屬性名 | 屬性說明 |
|---|---|
| cZxid | 數據節點創建的事務id |
| cZxid | 數據節點創建的事務id。 |
| ctime | 數據節點創建的時間。 |
| mZxid | 數據節點最後一次更新時的事務id |
| mtime | 數據節點最後一次更新的時間。 |
| pZxid | 數據節點的子節點最後一次被修改時的事務id。 |
| cversion | 子節點的更改次數。 |
| dataVersion | 節點數據的更改次數，也就是數據的版本。類似於關係型數據庫的樂觀鎖。 |
| aclVersion | 節點ACL權限的更改次數。 |
| ephemeralOwner | 如果節點是臨時節點，則該屬性表示創建該節點的會話SessionId。如果該節點是持久節點，該屬性爲0，可以使用該屬性來判斷節點是否爲臨時節點。 |
| dataLength | 數據的內容長度，單位字節。 |
| numChildren | 子節點的個數。 |
節點的類型
Zookeeper中的節點有四種：
臨時節點：該節點的生命週期依賴於建立它們的會話。一旦服務端任務客戶端連接的會話結束（可能會有一定的超時延遲），臨時節點會被自動刪除，當日也可以手動刪除。雖然每個臨時節點都只綁定到一個客戶端會話，但是它們對所有客戶端都是可見的。Zookeeper的臨時節點不允許擁有子節點。
持久化節點：該節點的生命週期不依賴於會話。並且只有在客戶端顯式執行刪除操作時，他們才能被刪除。
容器節點（3.6新增的）：ZooKeeper具有容器節點的概念。容器節點是特殊用途的節點，可用於諸如集羣中的leader，分佈式鎖等場景。當刪除容器節點的最後一個子節點時，也就是容器節點沒有子節點之後，該容器節點會在未來某個時間被服務器刪除。
TTL節點（3.6新增的）：在創建持久化或者持久化有序節點時，可以把節點設置爲TTL節點。並指定TTL的時間，單位爲毫秒。如果接在在TTL時間內未修改且沒有子代，該節點會在未來某個時間被服務器刪除。該屬性默認是禁用的，需要額外配置才能啓用。
有序節點：同一父節點下的有序節點具有先後順序關係。所謂有序節點就是創建znode時，可以要求ZooKeeper在路徑末尾附加一個單調遞增的計數器。該計數器對於父級znode是唯一的。計數器的格式爲％010d，即10位數字，填充爲0（零）（以這種格式格式化計數器以簡化排序），即“0000000001“。
注意：用於存儲下一個序列號的計數器是父節點維護的帶符號的int（4字節），當計數器增加到2147483647以上時，計數器將溢出（導致名稱 ”-2147483648“）。