分布式應用協同服務
ZooKeeper 是一種分布式，開源的協同服務。分布式應用可以基於其所提供的一些特性來實現服務同步，配置維護，服務分組及命名等。zookeeper是比較簡單易用的，並且使用類文件系統樹狀結構組織數據結構。
服務同步一直以來都是一個應用中的難點。尤其是在多線程環境中竟態條件及死鎖情景極易發生的情景下。zookeeper的設計初衷就是為了減少分布式應用在服務協同方面所需要付出的成本。
設計目標
ZooKeeper 很簡單。ZooKeeper 允許分布式任務進程通過共享層級的命名空間（類文件系統）來實現服務協同。命名空間內部包含數據注冊存儲，zookeeper術語稱之為znodes，這點和文件系統中的文件和文件夾很類似，所不同的是，文件系統是為了數據存儲，所以一般存儲於硬盤，而zookeeper的數據存儲在內存，這也就保障了zookeeper系統的高吞出，低延遲。
The ZooKeeper 是一種高性能，高可用，嚴格有序的系統。高性能也就意味着則 zookeeper 可以用在大型，分布式應用系統。高可用則是避免了單點故障，嚴格有序則是實現復雜業務服務同步的基本特性。
ZooKeeper 復制。zookeeper 的目的是任務協同，同時，zookeeper自身也作為協同服務的一員參與協同。
zookeeper服務中的每個服務節點都需要有相互認知。每個節點都在內存中維護者一份zookeeper服務的實時狀態信息，並且在持久化存儲中保存着事務日志信息及數據鏡像。只要服務中的大多數服務節點可用，那么整個服務就可認為是可用的。
每個客戶端只連接到一個服務節點。客戶端和zookeeper服務節點維護者一個TCP連接，用於收發請求，獲取監聽事件及發送心跳。如果客戶端和服務節點的連接中斷，客戶端會重新連接zookeeper中另外一個服務節點。
ZooKeeper 是有序的。ZooKeeper 會給每一個事務打上時間戳，用以標識順序。
ZooKeeper 很快。尤其是在以讀為主的業務系統中，當讀寫比例為10:1時，性能優佳。
數據模型及層級命名空間
zookeeper的命名空間類似文件系統，每個命名都是以“/”分割的路徑，並且唯一。
ZooKeeper 的層級命名空間
節點及瞬時節點
zookeeper的節點及子節點都可以存儲數據，稱之為znode。zookeeper節點是設計用來存儲服務協同數據，包括狀態信息，服務配置，位置信息等，所以節點數據通常需要很小。
Znode 以版本信息維護數據，ACL及時間戳變更。版本會隨着發生的變更而增加。
節點數據的讀寫是原子性的，讀寫操作都是針對節點的所有數據。每個節點都維護者一份ACL（訪問控制列表）信息用以控制數據訪問。
ZooKeeper 瞬時節點，生命周期同節點創建的會話生命周期，會話結束，則節點會被刪除。
條件更新及監控
ZooKeeper watch事件，客戶端在zookeeper節點上設置watch，節點變化時watch被觸發，然后被刪除，watch觸發后，客戶端會收到節點變化的信息。客戶端和服務節點斷開后，客戶端也會收到提醒。
服務保障
ZooKeeper 很快並且很簡單，為了實現服務復雜業務系統的目的，zookeeper提供以下保障：
- 順序一致性：更新會按客戶端發送的順序依次執行。
- 原子性：更新要么成功要么失敗。
- 單一系統鏡像：每個客戶端看到的zookeeper服務信息是一致的。
- 可靠性：更新只有在下一次更新復寫之后才會消失。
- 實時性：客戶端能實時獲取zookeeper服務信息。
簡單的 API
ZooKeeper 的設計目標之一便是提供簡便的開發接口，因此其只是支持如下操作：
-
create : 創建節點
-
delete : 刪除節點
-
exists : 判斷節點是否存在
-
get data : 獲取節點數據
-
set data : 設置節點數據
-
get children : 獲取節點子節點數據
-
sync : 數據復制傳遞
實現
概覽圖：
復制型數據庫是一種內存型數據庫，存儲着zookeeper服務完整的數據。更新會被記錄日志到硬盤以便用以數據恢復。寫操作在被應用到內存數據庫之前會被先序列化到硬盤。
zookeeper的每一個服務節點都可以作為客戶端服務節點，每個客戶端連接到一個服務節點來發送請求。服務節點以本地數據副本來響應客戶端請求，寫請求則會通過zookeeper的一致性協議來處理。
一致性協議要求客戶端的所有寫請求都轉發到一台服務器，我們稱之為領導者服務節點，其余的服務節點稱之為跟隨者。跟隨者接收領導者提議消息，同意或拒絕並回復。消息層協議用於領導者選舉及跟隨者同步。
ZooKeeper 原子廣播協議。原子性也就保證了追着服務節點的本地數據副本的實時性，一致性。當zookeeper服務接收到寫請求時，領導者應用寫請求，然后獲取將數據狀態作為事務消息發送到跟隨者。
性能
ZooKeeper 在讀請求為主的應用中能夠獲得更好的性能（因為寫操作涉及到數據及服務狀態的同步）。
參考資料：ZooKeeper Throughput as the Read-Write Ratio Varies
可靠性
如上圖所示：當跟隨者宕機然后快速恢復，zookeeper在期間仍能保持較高的吞吐量。更重要的是，領導者選舉協議保障了服務節點的快速恢復從而避免吞吐量急劇變化，通常領導者選舉耗時不超過200ms。
詳細參閱：ZooKeeper Wiki.
CAP：
zookeeper保障基本的CP特性。
項目地址：https://github.com/windwant/rpc-service.git | https://github.com/windwant/rmi-service.git