應用場景1－統一命名服務
»分佈式應用中，通常需要有一套完整的命名規則，既能夠產生唯一的名稱又便於人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。
»Name Service 是 Zookeeper 內置的功能，只要調用 Zookeeper 的 API 就能實現
應用場景2－配置管理
»配置的管理在分佈式應用環境中很常見，例如同一個應用系統需要多臺 PC Server 運行，但是它們運行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麼就必須同時修改每臺運行這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。
»將配置信息保存在 Zookeeper 的某個目錄節點中，然後將所有需要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺應用機器就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中。
應用場景3－集羣管理
»Zookeeper 能夠很容易的實現集羣管理的功能，如有多臺 Server 組成一個服務集羣，那麼必須要一個“總管”知道當前集羣中每臺機器的服務狀態，一旦有機器不能提供服務，集羣中其它集羣必須知道，從而做出調整重新分配服務策略。同樣當增加集羣的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓“總管”知道。
》Zookeeper 不僅能夠維護當前的集羣中機器的服務狀態，而且能夠選出一個“總管”，讓這個總管來管理集羣，這就是 Zookeeper 的另一個功能 Leader Election
»規定編號最小的爲master,所以當我們對SERVERS節點做監控的時候，得到服務器列表，只要所有集羣機器邏輯認爲最小編號節點爲master，那麼master就被選出，而這個master宕機的時候，相應的znode會消失，然後新的服務器列表就被推送到客戶端，然後每個節點邏輯認爲最小編號節點爲master，這樣就做到動態master選舉。
應用場景4－共享鎖
共享鎖在同一個進程中很容易實現，但是在跨進程或者在不同 Server 之間就不好實現了。Zookeeper 卻很容易實現這個功能，實現方式也是需要獲得鎖的 Server 創建一個 EPHEMERAL_SEQUENTIAL 目錄節點，然後調用 getChildren方法獲取當前的目錄節點列表中最小的目錄節點是不是就是自己創建的目錄節點，如果正是自己創建的，那麼它就獲得了這個鎖，如果不是那麼它就調用 exists(String path, boolean watch) 方法並監控 Zookeeper 上目錄節點列表的變化，一直到自己創建的節點是列表中最小編號的目錄節點，從而獲得鎖，釋放鎖很簡單，只要刪除前面它自己所創建的目錄節點就行了。
應用場景5－隊列管理
»Zookeeper 可以處理兩種類型的隊列：當一個隊列的成員都聚齊時，這個隊列纔可用，否則一直等待所有成員到達，這種是同步隊列；隊列按照 FIFO 方式進行入隊和出隊操作，例如實現生產者和消費者模型
»創建一個父目錄 /synchronizing，每個成員都監控目錄 /synchronizing/start 是否存在，然後每個成員都加入這個隊列（創建 /synchronizing/member_i 的臨時目錄節點），然後每個成員獲取 / synchronizing 目錄的所有目錄節點，判斷 i 的值是否已經是成員的個數，如果小於成員個數等待 /synchronizing/start 的出現，如果已經相等就創建 /synchronizing/start。
