篇幅目錄：
Zookeeper：一個分布式應用的分布式協調服務
設計目标
資料模型和分級命名空間
節點和臨時節點
條件更新和監控
保證
簡單的API
使用
性能
可靠性
Zookeeper項目
--------------------------------------------------------------------
Zookeeper：一個分布式應用的分布式協調服務
Zookeeper是一個分布式，開源的分布式應用協調服務。它暴露出一組簡單的接口，分布式應用可以在此之上實作進階服務比如：同步、配置維護、分組和命名。它設計的易于開發，使用的類似檔案系統中的目錄樹結構的資料模型。它運作在java上，并且有針對java和C的綁定。
衆所周知，協調服務很難處理正确。它特别容易發生錯誤諸如競争條件和死鎖。Zookeeper的動機是減輕分布式應用的責任并且從頭實作了協調服務。
設計目标
Zookeeper是簡單的。它允許分布式程式通過一個類似于标準的檔案系統的共享的命名空間體系進行協作。命名空間由被叫做znodes的資料注冊者組成，用Zookeeper的說法，它們類似于檔案和目錄。不像傳統的檔案系統，znodes被設計用于存儲，Zookeeper的資料被儲存在記憶體中，這意味着Zookeeper可以達到高吞吐量和低延遲量。
Zookeeper的實作對高性能、高可用、和嚴格順序通路提供了很大的好處。Zookeeper的性能方面意味着它可以被用在大型的分布式系統中，可用性方面使它不能成為單點故障。嚴格的順序通路意味着複雜的同步操作可以在用戶端進行實作。
Zookeeper是重複的。就像它協調的分布式程式一樣，Zookeeper本身的目的是在一組機器集合中進行複制。
組成Zookeeper服務的所有server必須互相知道，它們維持了一個記憶體中的狀态圖，在持久存儲中和事物日志以及快照一起呗存儲。隻要大部分server是可用的，那麼Zookeeper将會是可用的。
用戶端連接配接單個Zookeeper 服務，用戶端會維持一個TCP連接配接，通過這個連接配接發送請求，接受responses，獲得監視事件，發送心跳。如果這個TCP連接配接斷掉了，用戶端将會去連接配接另外一個服務。
Zookeeper是有序的。Zookeeper用一個數字标記每一個更新，這反映了Zookeeper事物的發生順序。後續的操作可以根據這個順序實作更進階别的抽象，比如事物操作。
Zookeeper是快速的。在“讀取占主導”的工作負載中，它的速度尤其快。Zookeeper應用運作在數千台機器上，它在讀操作比寫操作多的情況下性能最好，這個比例為10:1
資料結構&命名空間體系
Zookeeper提供的命名空間和标準的檔案系統很類似。名字是一個由/分隔符 分隔的路徑。每一個Zookeeper的命名空間中的節點都有這個路勁作為唯一辨別。
Nodes and ephemeral nodes
不像标準的檔案系統，Zookeeper 命名空間中的每一個節點包括子節點都可以有資料關聯。就像是一個檔案系統允許檔案也可以作為一個目錄。（Zookeeper 被設計用來存儲資料：狀态資訊，配置，本地資訊，等等..，是以存儲在每個節點上的資料通常都很少，從數byte到數kb之間。）我們使用znode這個術語來說明我們正在讨論的是ZooKeeper的資料節點。
znode維護一個統計結構，其中包括用于資料更改、ACL更改和時間戳的版本号，以允許緩存驗證和協調更新。每當znode的資料變化，這個版本号增加。例如，每當用戶端檢索資料時，它也會接收到資料的版本。
資料存儲在命名空間中的znode上的讀和寫都是原子性的。讀操作擷取znode關聯的所有資料，寫操作會替換所有資料。每個節點都有一個通路控制清單（ACL）來限制誰能做什麼。
Zookeeper也有臨時節點的概念。這些節點随着建立znode的session激活開始，當這個session結束後就會被删除掉。當你想實作[tbd]功能時，臨時節點是很有用的。
條件更新和監控
Zookeeper支援watches的概念。用戶端可以在一個節點上設定一個watch。這個監控會觸發和删除當這個節點變化的時候。當這個watch被觸發時用戶端就會收到節點變化的消息。而且如果這個用戶端和Zookeeper伺服器的連接配接斷了，那麼用戶端會收到一個本地通知，這個可以用來實作[tbd]。
保證
Zookeeper是很快和簡單的。盡管它的目标是成為建構更複雜的服務的基礎，例如同步，它提供了一組保證。他們是：
順序一緻性：來自用戶端的更新将按照發送的順序應用。
原子性：更新要麼成功要麼失敗，不會有中間結果
統一性：而不管它連接配接到何種伺服器，用戶端将看到服務的相同視圖。
可靠性：一旦應用了更新，它将從那個時間一直持續到用戶端重寫更新。
及時性：用戶端對系統的視圖保證在一定的時間内是最新的。
簡單的API
Zookeeper的一個設計目标是提供非常簡單的編碼api，是以，它僅支援下面這些操作
create
在樹中的一個位置建立一個節點
delete
删除一個節點
exists
測試某個位置是否存在一個節點
get data
從節點讀取資料
set data
向節點設定資料
get children
接受節點的一組子節點資料
sync
等待資料傳播（同步）
關于這些問題的更深入的讨論，以及如何使用它們來實作更進階别的操作，請參考[tbd]
實作
Zookeeper元件展示了Zookeeper 服務的進階元件。除了請求處理器之外，組成ZooKeeper服務的每一個伺服器都複制自己的每一個元件的副本。
複制的資料庫是一個包含整個資料樹的記憶體資料庫。更新被記錄到磁盤上，以便恢複，并且在将它們應用到記憶體資料庫之前，将其寫到磁盤上。
每個Zookeeper服務向用戶端提供服務。用戶端連接配接到一個伺服器來送出irequest。讀取請求是從每個伺服器資料庫的本地副本提供服務的。請求會改變服務端的狀态，寫請求會被一個協定處理。
作為協定的一部分，所有來自客戶的寫請求都被轉發到一個名為“leader”的伺服器上。其餘的Zookeeper伺服器，被稱為followers，他們接收來自leader的消息指令，通過消息傳遞指令達成一緻。消息傳遞層負責更換無效的leader，并将followers和leaders同步
動物園管理者使用定制的原子消息傳遞協定。由于消息傳遞層是原子的，是以ZooKeeper可以保證本地副本不會有分歧。當上司者收到一個寫請求時，它會計算出當寫入時系統的狀态是什麼并傳遞給一個捕捉新狀态的事物。
使用
Zookeeper的程式設計接口故意設計的很簡單。然而，有了它，你可以實作更進階的順序操作，比如同步、分組成員關系、所屬關系等等。一些分布式應用程式已經将其應用于：tbd：要了解更多資訊，請參見tbd
性能
Zookeeper被設計成高性能的。但是它真的是嗎？Zookeeper在Yahoo！的研發團隊給出的結果。研究表明确實如此。（看下圖：随着讀寫比率變化的Zookeeper吞吐量變化圖），讀操作比寫操作多時它表現的特别高效，因為寫操作涉及到同步所有伺服器的狀态。（讀操作占主導的經典例子是協調服務。）
上圖的特性是Zookeeper的吞吐量圖，是由兩個2 Ghz Xeon和兩個SATA 15 K RPM驅動器運作的Zookeeper3.2版本的吞吐量圖。一個驅動器是Zookeeper日志服務專用的。快照被寫到OS驅動器。寫請求是1 K寫，讀是1 K讀。“services”表明了組成了該服務的伺服器數量。大約有30個其它伺服器被用來模拟用戶端。Zookeeper叢集被配置為用戶端不可連接配接到leaders
NOTE：3.2版本的讀寫性能比3.1版本提升了2倍。
基準還表明，它也是可靠的。在出現錯誤時的可靠性顯示了部署如何響應各種故障。圖中所列的事件如下：
1. 發生錯誤和恢複follower
2. 發生錯誤和恢複另外一個follower
3. leader節點發生錯誤
4. 2個followers發生錯誤和恢複
5. 另外一個leader發生了錯誤
可靠性
為了顯示系統的行為，随着時間的推移，我們運作了一個由7台機器組成的Zookeeper服務。我們運作的飽和度和以前一樣，但是這次我們把寫的百分比保持在30%不變，這是我們預期的工作負載。
| Reliability in the Presence of Errors |
| |
這裡有一些很重要的觀察結果。第一，follower的失敗和恢複是很迅速的，Zookeeper可以保持高的吞吐量盡管發生了錯誤。但是更重要的是，leader選舉算法允許系統快速恢複，以防止吞吐量大幅下降。在我們的觀察中，Zookeeper用了少于200ms選舉leader。第三，follower 恢複後，Zookeeper就可以再次提高處理請求的吞吐量。
Zookeeper 項目
Zookeeper被成功應用于很多的工業應用中，在雅虎中，作為協調和錯誤恢複服務。Message Broker，它是一個高度可伸縮的釋出-訂閱系統，管理數千個用于複制和資料傳遞的主題。它被Yahoo的抓取服務使用！爬行器，它還管理故障恢複。大量的Yahoo !廣告系統還使用Zookeeper來實作可靠的服務。
鼓勵所有使用者和開發人員加入社群并貢獻他們的專業知識。請參閱Apache上的Zookeeper項目以獲得更多資訊。