目錄
1. 簡介
2. 叢集架構
3. 資料模型
4. 使用場景（常用功能）
4.1 Master選舉
4.2 成員管理（負載均衡實作）
4.3 配置管理（釋出訂閱）
4.4 任務配置設定
4.5 分布式鎖
1. 簡介
Zookeeper是一個開源的分布式協調服務，其設計目标是将那些複雜的且容易出錯的分布式一緻性服務封裝起來，構成一個高效可靠的原語集，并以一些簡單的接口提供給使用者使用。其是一個典型的分布式資料一緻性的解決方案，分布式應用程式可以基于它實作諸如資料釋出/訂閱、負載均衡、命名服務、分布式協調/通知、叢集管理、Master選舉、分布式鎖和分布式隊列等功能。
2. 叢集架構
官網配圖
ZooKeeper叢集由一組Server節點組成，這一組Server節點中存在一個角色為Leader的節點，其他節點都為Follower。
寫請求：每個寫請求都會通過Follower轉發給Leader，通過ZAB協定達到一緻性和順序性，然後同步至全部follower，最終達成資料一緻。
讀請求：在zookeeper中，所有的server(leader和follower)都可以直接響應讀請求。
基于以上讀寫方式，決定了zookeeper在讀遠多于寫的情況下，性能最好。如果讀沒有明顯多于寫的情況下，不太适合對并發和性能要求太高的情況。
3. 資料模型
在zookeeper中，資料是按樹形存儲，每個節點被稱為Znode，類似于檔案系統。但是與檔案系統不同的是，上圖中的每個Znode也可以存儲資料。就相當于，檔案系統中，目錄中也可以存内容。例如：建立/app2時可以同時設定内容其内容為"I am app2 content"。之後可以從/app2節點讀取相應資料。
4. 使用場景（常用功能）
4.1 Master選舉
目前node1為leader，leader節點的内容是"node1"，當node1挂掉後，/leader節點會被删除。node2和node3監控/leader節點，當/leader節點被删除時，嘗試建立/leader節點。建立成功的成為新的leader，并同時将leader節點的内容設定為新的leader節點。
4.2 成員管理（負載均衡實作）
成員管理的目的就是，叢集内某個節點當機或者新加入節點，可以及時感覺。舉例如下：
上圖中，起初node2和node3分别注冊/cluster-1目錄下的/node2和/node3,client1、client2連接配接node2，client3連接配接node3。當新增節點node1時，被client1感覺到。client1實作了負載均衡算法，是以從node2改為連接配接node1。
舉例中，用戶端程式client監聽/cluster-1的變化，但不僅限于此，所有對/cluster-1的變化感興趣的元件都可以注冊監聽，例如上圖中node節點。
4.3 配置管理（釋出訂閱）
client1、client2和client3 同時監聽/conf節點。當/conf内容發生變化時，所有節點都會收到通知。
4.4 任務配置設定
任務配置設定程式監聽/tasks,當有新任務task1，task2來到，将task1配置設定給/processor1,即在/processor1下建立task1，然後删除task1。processor1處理完成後删除task1。task2與之相同。
4.5 分布式鎖
在zookeeper中，支援建立節點時字尾自動編号的特性。例如上圖中，client1 執行建立"/lock/node-" 的指令時，在/lock下自動建立類似node-01的節點，當client2執行相同指令時，則自動生成node-02。
此時，client1發現node-01是編号最小的，是以client1獲得鎖，當執行完成後，删除node-01。而client2發現在自己之前還有node-01，是以它監聽node-01的删除事件。當node-01被删除時，client2即獲得鎖。以此類推。Curator中就使用類似的方式。