概覽
zookeeper是一個分佈式應用的分佈式的、開放源碼的協作服務。它提供一些源語，分佈式應用基於此，可以爲同步、配置維護、分組和命名建立更高級別的服務。它被設計成易編程和使用類似文件系統目錄樹架構的數據模型。它能運行在Java環境和同時有Java和C的環境中。
協同服務是出了名的難以正確實現。特別容易出錯，比如競爭條件和死鎖。zookeeper背後的原因是解決分佈式應用從頭開始實現協同服務的責任
1、設計目標
簡單
zookeeper允許分佈式進程之間通過一個組織類似於標準文件系統的共享分層命名空間進行協調。命名空間包括數據寄存器，用zookeeper術語稱znode，類似於文件和目錄。不像設計用於存儲的典型的文件系統，zookeeper數據存在內存中，意味着zookeeper能夠實現高吞吐量和低延遲。
zookeeper的實現，爲高性能、高可用和嚴格有序訪問提供了附加性能。在性能方面，zookeeper可以用於大型的、分佈式系統。可靠方面可以避免單點故障。嚴格有序意味着在客戶端可以實現複雜的同步源語。
複製
像分佈式進程一樣協調，zookeeper本身就是一組相互複製的主機的整體。
組成zookeeper服務的服務器必須知道彼此。它們維護一個內存中的狀態的鏡像，這個鏡像具有事務日誌和持久存儲快照。只要大部分服務器可用，那麼zookeeper服務就可用。
客戶端只能連接到一個zookeeper服務器。客戶端維護一個TCP連接，客戶端通過這個TCP連接可以發送請求、獲取應答、獲取watch事件和發送心跳。如果TCP連接斷開，客戶端會連接到不同的服務器。
有序
zookeeper會使用一個反映所有zookeeper事務順序的數字標識每次更新。隨後的操作可以使用順序實現更高等級的抽象，比如同步源語。
快速
在以讀爲主的工作負載下，zookeeper非常快。zookeeper運行在上千臺主機上，在讀比寫常見的情況下，表現的更高，比率大約爲10:1。
2、數據模型和分層命名空間
zookeeper提供的命名空間特別想標準的文件系統。名字是由’/’分割的路徑元素的序列。在zookeeper命名空間的每個節點是由一個路徑標識的。
3、節點和短暫節點
不想標準的文件系統，zookeeper命名空間中的每個節點都有數據，同時也可以有子。就像有一個允許一個文件成爲一個目錄的文件系統。zookeeper設計用來存儲協調數據的，比如狀態信息、配置、位置信息等。因此存儲在每個節點上的數據通常非常小，在字節到千字節範圍內的，也就是不會超過1M。是用術語znode來清晰的表達我們討論的zookeeper數據節點。
znode維護這包含數據改變的版本號、ACL改變、時間戳、允許cache確認和協調更新的stat結果。每次一個znode數據的改變，版本號就會增加。例如，每當客戶端檢索數據的時候，也會接收該數據的版號。
存儲在命名空間的每個znode的數據的讀和寫是原子性的。讀操作會得到與znode相關的所有數據的字節，寫操作會代替所有的數據。每個節點有嚴格控制可以做什麼的訪問控制列表（ACL）。
zookeeper也有短暫節點的概念。只要創建該會話的znode存活，這些znode就存在。當會話結束，該znode就會被刪除。當想部署的時候短暫節點非常有用[待決定]。
協作updates和watches
zookeeper支持watch的概念。客戶端可以在一個znode上設置一個watch。當該znode改變時，watch將被觸發和刪除。當watch被觸發，客戶端會接收到通知該znode已經改變的包。如果客戶端和其中一個zookeeper服務器之間的連接端開，該客戶端會收到一個本地通知。
4、保證
zookeeper是非常快速和簡單的。因爲zookeeper的目的是成爲更復雜的服務架構的基礎，比如同步，所以提供了一系列的保證。
順序一致性
來自客戶端的更新會按照被髮送的順序來進行應用。
原子性
更新要麼成功要麼失敗，不會是一部分結果
單個系統鏡像
不管客戶端連接到哪個服務器，看到的是同樣的服務的情景。
可靠性
一旦更新被應用，會一直保持直到客戶端重寫這個更新
及時
在一定的時間內，客戶端看到系統的數據保證是最新的。
5、簡單的API
zookeeper設計的目的之一就是提供非常簡單可編程的接口。但是隻提供瞭如下操作：
create
在本地以樹的方式創建node
delete
刪除一個node
exists
在本地測試一個node是否存在
get data
從一個node讀取數據
set data
寫數據到node
get children
檢索一個node的子
sync
等數據進行傳播
6、實現
下圖展示了zookeeper服務的組件。除了請求處理器外，每個組成zookeeper服務的服務器複製自己每個組件的副本。
複製數據庫是包含整個數據數的內存數據庫。更新會記錄到磁盤用於恢復，在被應用到內存數據庫之前，寫操作會序列化到磁盤。
每個zookeeper服務器都爲客戶端提供服務。客戶端會精確連接到一個服務器提交irequest。讀請求是由每個服務器數據庫的本地服務提供服務。改變服務狀態的請求、寫請求是通過約定好的協議處理的。
作爲約定好的協議的一部分，所有來自客戶端的寫請求被轉發到一個單獨的服務器，被稱爲leader。剩下的zookeeper服務器被稱爲follower，接收來自leader的信息建議和商定信息發佈。信息層負責替換故障的leader和同步follwer和leader。
zookeeper使用自定義的原子消息協議。由於消息層是原子性的，所以zookeeper能保證本地副本不會偏離。當leader接收到一個讀請求，它計算系統是什麼狀態，當寫操作被應用並且轉化成爲捕捉新狀態的事務。