Zookeeper主要用在分布式應用中實作一緻性協調排程服務。它的命名空間類似傳統檔案系統，每個節點都以唯一的路徑進行辨別，不同的是，每個節點除了可以擁有子節點外，還可擁有相對性的data資料。
一、Zookeeper命名空間
上圖是一個典型的Zookeeper命名空間結構，通過路徑"/app1/p_1"可通路znode1節點，每個節點可存儲少量資料，如狀态、配置、位置資訊等等，且data資訊量很小，一般在byte到KB級别。節點znode維護一個狀态stat結構（包括資料變化的版本号、ACL變化、時間戳），以允許緩存驗證與協調更新。每當節點資料内容改變時，多一個版本号，類似HBase。用戶端擷取資料的同時也擷取相對應的版本号。節點資料内容以原子方式讀寫，讀操作會讀取該znode的全部data資料，同樣寫操作也會覆寫該znode的全部data資料，不存在部分讀寫的情況。同時，每個節點有一個通路控制清單ACL（Access Control List）來限制通路操作，即具有權限控制。
znode存在兩種：
正常的znode: 由使用者顯式建立和删除
ephemeral znode：臨時型znode, 其生命周期伴随于建立它的session， session結束後，ZooKeeper Server會自動删除它，當然使用者也可以顯式的删除
二、Zookeeper的Watches
Zookeeper對Node的增删改查都可觸發監聽，每個client可對一個znode設定一個watch事件。當watch監視的資料發生變化時，會通知設定了該watch的client，即watcher。watch事件是一次性觸發器，即觸發一次就會被取消，該client如果還要監視該znode的變化，需要再次設定相應的watch事件。
注：
watch事件異步發送至觀察者，可能導緻當兩次觸發時間間隔太短的時候，不同的接收者收到的事件不一緻
watch是一次性觸發的且在擷取watch事件和設定watch事件之間有延遲，是以不能可靠的觀察到節點的每一次變化
用戶端監視一個節點，總是先擷取watch事件，再發現節點的資料變化。
watch事件的順序對應于zookeeper服務所見的資料更新順序
三、Zookeeper讀寫流程
讀請求到來時，将直接從replicated database擷取資料，replicated database是一個記憶體資料庫，是以讀寫效率高
寫請求到來時，所有的寫請求都會先發送給一個稱之為leader的server，然後由該leader廣播給各個follower（server），在收到超過一半的server回報的ack之後，認為此次寫操作成功。同時，再寫操作更新到記憶體資料庫之前，會先持久化到磁盤，用于恢複。如下圖所示：
四、在dubbo中的應用
在分布式系統中，通過使用命名服務，用戶端應用能夠根據指定名字來擷取資源或服務的位址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務位址，遠端對象等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分布式服務架構中的服務位址清單。通過調用ZK提供的建立節點的API，能夠很容易建立一個全局唯一的path，這個path就可以作為一個名稱。比如dubbo應用中：
服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL位址，這個操作就完成了服務的釋出。
服務消費者啟動的時候，訂閱/dubbo/serviceName/providers目錄下的提供者URL位址，并向/dubbo/serviceName/providers目錄下的提供者URL位址，并向/dubbo/{serviceName} /consumers目錄下寫入自己的URL位址。
注意，所有向ZK上注冊的位址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。
另外，Dubbo還有針對服務粒度的監控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的資訊。
本文轉自zsdnr 51CTO部落格，原文連結：http://blog.51cto.com/12942149/1949809，如需轉載請自行聯系原作者