zookeeper 是什么？
ZooKeeper由雅虎研究院開發，是Google Chubby的開源實現，后來托管到Apache，於2010年11月正式成為Apache的頂級項目。
ZooKeeper是一個經典的分布式數據一致性解決方案，致力於為分布式應用提供一個高性能、高可用，且具有嚴格順序訪問控制能力的分布式協調服務。
分布式應用程序可以基於ZooKeeper實現數據發布與訂閱、負載均衡、命名服務、分布式協調與通知、集群管理、Leader選舉、分布式鎖、分布式隊列等功能。
在Zookeeper的官網上有這么一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
這大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服務，提供分布式同步以及集群管理。那這些服務又到底是什么呢？我們為什么需要這樣的服務？我們又為什么要使用Zookeeper來實現呢，使用Zookeeper有什么優勢？接下來我會挨個介紹這些到底是什么，以及有哪些開源系統中使用了。
zookeeper 都有哪些功能？
統一命名服務(naming)
分布式應用中,通常需要有一套完整的命名規則,既能產生唯一的命名又便於識別和記住,通常情況下用樹形的結構是一個理想的選擇,屬性的名稱結構是一個有層次的目錄結構,既對人友好又不會重復,說到這里你可能想到JNDO沒錯Zookeeper的Name Service與JNDI能夠完成的功能是差不多的,他們都是具有層次的目錄結構關聯到一定資源上,但是Zookeeper的NameService更加是廣泛意義上的關聯,也許你並不需要將名稱關聯到特定資源上,你可能只需要一個不會重復的名稱,就想數據庫中產生唯一的數字主鍵一樣.
NameService已經是Zookeeper內置的功能,你只要調用Zookeeper的API就能實現,如調用create接口就可以很容易的創建一個目錄節點.
配置管理
配置管理的在分布式應用環境下很常見,例如同一個應用系統需要多台PC Server運行,但是他們運行的應用系統的某些配置是相同的,如果要修改這個相同的配置項,那么就必須同時修改每台運行這個系統的PC Server這樣非常麻煩而且容易出錯.
像這樣的配置信息完全可以交給Zookeeper來管理,將配置信息保存在Zookeeper的某個目錄節點中,然后將所有需要修改的應用及其監控配置信息的狀態,一旦配置信息發生變化,每台應用及其就會收到ZooKeeper的通知,然后從Zookeeper的通知,然后從Zookeeper獲取新的配置信息應用到系統中
集群管理
Zookeeper能夠很容易的實現集群管理的功能,如有多台Server組成一個服務集群,那么必須要一個總管知道當前及權重每台機器的服務狀態,一旦有機器不能提供服務,集群中其他集群必須知道,從而做出調整重新分配服務政策.同樣增加集群的服務能力時,就會增加一台或者多台server,同樣也必須讓總管知道.
Zookeeper不僅能夠幫你維護當前的集群中機器的服務狀態,而且能夠幫你選出一個'總管',讓這個總管來管理集群,這就是Zookeeper的另一個功能 Leader Election
它們的實現方式都是在 Zookeeper 上創建一個 EPHEMERAL 類型的目錄節點，然后每個 Server 在它們創建目錄節點的父目錄節點上調用 getChildren(String path, boolean watch) 方法並設置 watch 為 true，由於是 EPHEMERAL 目錄節點，當創建它的 Server 死去，這個目錄節點也隨之被刪除，所以 Children 將會變化，這時 getChildren上的 Watch 將會被調用，所以其它 Server 就知道已經有某台 Server 死去了。新增 Server 也是同樣的原理。
Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的一樣每台 Server 創建一個 EPHEMERAL 目錄節點，不同的是它還是一個 SEQUENTIAL 目錄節點，所以它是個 EPHEMERAL_SEQUENTIAL 目錄節點。之所以它是 EPHEMERAL_SEQUENTIAL 目錄節點，是因為我們可以給每台 Server 編號，我們可以選擇當前是最小編號的 Server 為 Master，假如這個最小編號的 Server 死去，由於是 EPHEMERAL 節點，死去的 Server 對應的節點也被刪除，所以當前的節點列表中又出現一個最小編號的節點，我們就選擇這個節點為當前 Master。這樣就實現了動態選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。
分布式鎖
其實在第一篇文章中已經介紹了Zookeeper是一個分布式協調服務。這樣我們就可以利用Zookeeper來協調多個分布式進程之間的活動。比如在一個分布式環境中，為了提高可靠性，我們的集群的每台服務器上都部署着同樣的服務。但是，一件事情如果集群中的每個服務器都進行的話，那相互之間就要協調，編程起來將非常復雜。而如果我們只讓一個服務進行操作，那又存在單點。通常還有一種做法就是使用分布式鎖，在某個時刻只讓一個服務去干活，當這台服務出問題的時候鎖釋放，立即fail over到另外的服務。這在很多分布式系統中都是這么做，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。比如HBase的Master就是采用這種機制。但要注意的是分布式鎖跟同一個進程的鎖還是有區別的，所以使用的時候要比同一個進程里的鎖更謹慎的使用。
參考鏈接：什么是zookeeper