ZooKeeper 是一種分佈式，開源的協同服務。分佈式應用能夠基於其所提供的一些特性來實現服務同步，配置維護，服務分組及命名等。zookeeper是比較簡單易用的，而且使用類文件系統樹狀結構組織數據結構。html
服務同步一直以來都是一個應用中的難點。尤爲是在多線程環境中竟態條件及死鎖情景極易發生的情景下。zookeeper的設計初衷就是爲了減小分佈式應用在服務協同方面所須要付出的成本。node
設計目標
ZooKeeper 很簡單。ZooKeeper 容許分佈式任務進程經過共享層級的命名空間（類文件系統）來實現服務協同。命名空間內部包含數據註冊存儲，zookeeper術語稱之爲znodes，這點和文件系統中的文件和文件夾很相似，所不一樣的是，文件系統是爲了數據存儲，因此通常存儲於硬盤，而zookeeper的數據存儲在內存，這也就保障了zookeeper系統的高吞出，低延遲。數據庫
The ZooKeeper 是一種高性能，高可用，嚴格有序的系統。高性能也就意味着則 zookeeper 能夠用在大型，分佈式應用系統。高可用則是避免了單點故障，嚴格有序則是實現複雜業務服務同步的基本特性。apache
ZooKeeper 複製。zookeeper 的目的是任務協同，同時，zookeeper自身也做爲協同服務的一員參與協同。服務器
zookeeper服務中的每一個服務節點都須要有相互認知。每一個節點都在內存中維護者一份zookeeper服務的實時狀態信息，而且在持久化存儲中保存着事務日誌信息及數據鏡像。只要服務中的大多數服務節點可用，那麼整個服務就可認爲是可用的。數據結構
每一個客戶端只鏈接到一個服務節點。客戶端和zookeeper服務節點維護者一個TCP鏈接，用於收發請求，獲取監聽事件及發送心跳。若是客戶端和服務節點的鏈接中斷，客戶端會從新鏈接zookeeper中另一個服務節點。多線程
ZooKeeper 是有序的。ZooKeeper 會給每個事務打上時間戳，用以標識順序。分佈式
ZooKeeper 很快。尤爲是在以讀爲主的業務系統中，當讀寫比例爲10:1時，性能優佳。性能
數據模型及層級命名空間
zookeeper的命名空間相似文件系統，每一個命名都是以「/」分割的路徑，而且惟一。spa
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。