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層的壓力。