ZooKeeper是一個開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
一、配置維護
在我們的應用中除了代碼外，還有一些就是各種配置。比如數據庫連接等。一般我們都是使用配置文件的方式，在代碼中引入這些配置文件。當我們只有一種配置，只有一台服務器，並且不經常修改的時候，使用配置文件是一個很好的做法，但是如果我們配置非常多，有很多服務器都需要這個配置，這時使用配置文件就不是個好主意了。這個時候往往需要尋找一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。Zookeeper就是這種服務，它使用Zab這種一致性協議來提供一致性。現在有很多開源項目使用Zookeeper來維護配置，比如在HBase中，客戶端就是連接一個Zookeeper，獲得必要的HBase集群的配置信息，然后才可以進一步操作。還有在開源的消息隊列Kafka中，也使用Zookeeper來維護broker的信息。在Alibaba開源的SOA框架Dubbo中也廣泛的使用Zookeeper管理一些配置來實現服務治理。
二、域名服務
名字服務這個就很好理解了。比如為了通過網絡訪問一個系統，我們得知道對方的IP地址，但是IP地址對人非常不友好，這個時候我們就需要使用域名來訪問。但是計算機是不能是域名的。怎么辦呢？如果我們每台機器里都備有一份域名到IP地址的映射，這個倒是能解決一部分問題，但是如果域名對應的IP發生變化了又該怎么辦呢？於是我們有了DNS這個東西。我們只需要訪問一個大家熟知的(known)的點，它就會告訴你這個域名對應的IP是什么。在我們的應用中也會存在很多這類問題，特別是在我們的服務特別多的時候，如果我們在本地保存服務的地址的時候將非常不方便，但是如果我們只需要訪問一個大家都熟知的訪問點，這里提供統一的入口，那么維護起來將方便得多了。
三、分布式同步
其實在第一篇文章中已經介紹了Zookeeper是一個分布式協調服務。這樣我們就可以利用Zookeeper來協調多個分布式進程之間的活動。比如在一個分布式環境中，為了提高可靠性，我們的集群的每台服務器上都部署着同樣的服務。但是，一件事情如果集群中的每個服務器都進行的話，那相互之間就要協調，編程起來將非常復雜。而如果我們只讓一個服務進行操作，那又存在單點。通常還有一種做法就是使用分布式鎖，在某個時刻只讓一個服務去干活，當這台服務出問題的時候鎖釋放，立即fail over到另外的服務。這在很多分布式系統中都是這么做，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。比如HBase的Master就是采用這種機制。但要注意的是分布式鎖跟同一個進程的鎖還是有區別的，所以使用的時候要比同一個進程里的鎖更謹慎的使用。
四、組服務
在分布式的集群中，經常會由於各種原因，比如硬件故障，軟件故障，網絡問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集群。這個時候，集群中其他機器需要感知到這種變化，然后根據這種變化做出對應的決策。比如我們是一個分布式存儲系統，有一個中央控制節點負責存儲的分配，當有新的存儲進來的時候我們要根據現在集群目前的狀態來分配存儲節點。這個時候我們就需要動態感知到集群目前的狀態。還有，比如一個分布式的SOA架構中，服務是一個集群提供的，當消費者訪問某個服務時，就需要采用某種機制發現現在有哪些節點可以提供該服務(這也稱之為服務發現，比如Alibaba開源的SOA框架Dubbo就采用了Zookeeper作為服務發現的底層機制)。還有開源的Kafka隊列就采用了Zookeeper作為Cosnumer的上下線管理。
Java學習參考：橫空出世，又一java教程完整版正式發布，接收一切挑戰！
（1）、什么是Znode？
在Zookeeper中，znode是一個跟Unix文件系統路徑相似的節點，可以往這個節點存儲或獲取數據。
Zookeeper底層是一套數據結構。這個存儲結構是一個樹形結構，其上的每一個節點，我們稱之為“znode”
zookeeper中的數據是按照“樹”結構進行存儲的。而且znode節點還分為4中不同的類型。
每一個znode默認能夠存儲1MB的數據（對於記錄狀態性質的數據來說，夠了）
可以使用zkCli命令，登錄到zookeeper上，並通過ls、create、delete、get、set等命令操作這些znode節點
（2）、Znode節點類型有哪些？
1》PERSISTENT 持久化節點: 所謂持久節點，是指在節點創建后，就一直存在，直到有刪除操作來主動清除這個節點。否則不會因為創建該節點的客戶端會話失效而消失。
2》PERSISTENT_SEQUENTIAL 持久順序節點：這類節點的基本特性和上面的節點類型是一致的。額外的特性是，在ZK中，每個父節點會為他的第一級子節點維護一份時序，會記錄每個子節點創建的先后順序。基於這個特性，在創建子節點的時候，可以設置這個屬性，那么在創建節點過程中，ZK會自動為給定節點名加上一個數字后綴，作為新的節點名。這個數字后綴的范圍是整型的最大值。 在創建節點的時候只需要傳入節點 “/test_”，這樣之后，zookeeper自動會給”test_”后面補充數字。
3》EPHEMERAL 臨時節點：和持久節點不同的是，臨時節點的生命周期和客戶端會 話綁定。也就是說，如果客戶端會話失效，那么這個節點就會自動被清除掉。注意，這里提到的是會話失效，而非連接斷開。另外，在臨時節點下面不能創建子節點。
這里還要注意一件事，就是當你客戶端會話失效后，所產生的節點也不是一下子就消失了，也要過一段時間，大概是10秒以內，可以試一下，本機操作生成節點，在服務器端用命令來查看當前的節點數目，你會發現客戶端已經stop，但是產生的節點還在。
EPHEMERAL_SEQUENTIAL 臨時自動編號節點：此節點是屬於臨時節點，不過帶有順序，客戶端會話結束節點就消失。
（3）、什么是Dubbo？
Dubbo是阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和Spring框架無縫集成。Dubbo框架，是基於容器運行的.。容器是Spring。 ** 其核心部分包含:**
1. 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
2. 集群容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
3. 自動發現: 基於注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
（4）、Dubbo能做什么？
1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。
3.服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。
Dubbo的存在簡單來說就是要減小service層的壓力。
