Zookeeper 分布式服務架構是Apache Hadoop 的一個子項目，由Yahoo建構，它主要是用來解決分布式應用中經常遇到的一些資料管理問題，如：資料釋出/訂閱、負載均衡、命名服務、分布式協調/通知、叢集管理、Master 選舉、配置維護、分布式同步、分布式鎖和分布式隊列 等功能。
ZooKeeper的目标是将這些不同服務的本質提煉成一個非常簡單的接口，以實作集中的協調服務。服務本身是分布式的，非常可靠。一緻性、組管理和存在協定将由服務實作，這樣應用程式就不需要自己實作它們。這些應用程式的特定用途将由ZooKeeper的特定元件和應用程式特定約定的混合組成。ZooKeeper展示了如何使用這個簡單的服務來建構更強大的抽象。
zookeeper相關
用戶端連接配接
用戶端連接配接zookeeper：用戶端啟動，會和伺服器建立一個TCP連接配接，從第一次連接配接建立開始，用戶端會話的生命周期就開始了。目的是通過這個長連接配接，進行心跳檢測保證用戶端和伺服器的連接配接會話。雙向的進行的，可以向伺服器發送請求和接收響應，也能夠接收來自伺服器的監聽事件通知。
用戶端連接配接示意
Session
session 的 SessionTimeout 值用來設定一個用戶端會話的逾時時間。當由于伺服器 壓力太大、網絡故障或是用戶端主動斷開連接配接等各種原因導緻用戶端連接配接斷開時，隻要在 SessionTimeout 規定的時間内能夠重新連接配接上叢集中任意一台伺服器，那麼之前建立的會話 仍然有效。
用戶端以心跳的方式保持和服務端的會話連接配接。如果會話逾時，則判斷用戶端已當機。
樹形結構（層次命名空間）
zookeeper用于記憶體存儲的一個樹形結構的檔案系統，在和dubbo結合的時候，會給root節點命名為“dubbo”，在這個樹上都是zNode，這個每個節點都可以用來存儲資料。
在根目錄下，有兩個邏輯命名空間config和workers。在config下每個znode最多存儲1MB資料。這麼做的目的是存儲同步資料并描述znode的中繼資料。
ZooKeeper資料模型中的每個znode都維護着一個 stat 結構。一個stat僅提供一個znode的中繼資料。它由版本号，操作控制清單(ACL)，時間戳和資料長度組成。
資料節點分為持久節點（persistent）和臨時節點（ephemeral）
持久節點：建立到樹上，就會一直存在，除非主動進行操作；
臨時節點：生命周期跟用戶端會話綁定，一旦用戶端會話失效，那麼這個用戶端建立的節點就會被剔除。是以，隻有臨時節點不允許有子節點。如果臨時節點被删除，則下一個合适的節點将填充其位置。臨時節點在leader選舉中起着重要作用。
例如一個提供者，因為某些原因逾時或當機，zk就會檢測不到提供者，那這個提供者就會被zk剔除。
監聽事件
使用事件監聽器Watcher，在zk發揮注冊中心作用上很重要的特性，zk允許使用者在指定節點上注冊一些Watcher，并且事件觸發時（例如dubbo提供者增加服務），zk服務端就會将事件通知給訂閱的用戶端。這是釋出/訂閱機制重要組成部分。
問題：一個項目肯定能有很多服務，那麼zk監聽哪些具體的節點？
Client可以在某個ZNode上設定一個Watcher，來Watch該ZNode上的變化。如果該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設定Watcher的Client。
需要注意的是，ZooKeeper中的Watcher是一次性的，即觸發一次就會被取消，如果想繼續Watch的話，需要用戶端重新設定Watcher
先了解節點是什麼？一個用戶端對應一個節點，zk是監控所有訂閱的節點發送通知，例如dubbo裡的消費者。
zookeeper叢集
三種角色：leader、follower、client
叢集最少三個，zk叢集啟動，用戶端可以向任意節點連接配接，一旦用戶端被連接配接，節點将向特定用戶端配置設定SessionID并向該用戶端發送确認。如果用戶端沒有收到确認，它将嘗試連接配接ZooKeeper集合中的另一個節點。 一旦連接配接到節點，用戶端将以有規律的間隔向節點發送心跳，以確定連接配接不會丢失。
問題1：為什麼叢集最少三個？
很簡單，如果叢集不出故障，幾個節點都沒有關系，但是這是不可能的。如果1個節點，節點故障，代表整個叢集當機；如果有2個節點，有一個故障，根據多數判斷當機，一個節點并不是多數；如果有三個節點，有一個節點故障，剩下兩個就是多數，就可以判定有節點當機；如果有四個節點，其中兩個故障，剩下兩個也不能成為多數，是以三個是最少最合适的節點數。
問題2：叢集節點和樹形節點的關系？
叢集選舉
在叢集leader如果當機或失去了大部分的follower，其他follower是可以通過選舉，成為新的leader的。
問題：叢集選舉對線上的影響？
以dubbo為例，消費者和提供者一旦建立長連接配接，zookeeper出現當機，對他們是沒有影響的。隻不過對某些節點需要訂閱zk時，接收不到響應，就會換另外一台機器。
選舉算法
zk選舉有兩種算法實作：basic paxos、fast paxos
basic paxos：
1 .選舉線程由目前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，并選出推薦的Server；
2 .選舉線程首先向所有Server發起一次詢問(包括自己)；
3 .選舉線程收到回複後，驗證是否是自己發起的詢問(驗證zxid是否一緻)，然後擷取對方的id(myid)，
并存儲到目前詢問對象清單中，最後擷取對方提議的leader相關資訊(id,zxid)，并将這些資訊存儲
到當次選舉的投票記錄表中；
4. 收到所有Server回複以後，就計算出zxid最大的那個Server，并将這個Server相關資訊設定成下
一次要投票的Server；
5. 線程将目前zxid最大的Server設定為目前Server要推薦的Leader，如果此時獲勝的Server獲得
n/2 + 1的Server票數， 設定目前推薦的leader為獲勝的Server，将根據獲勝的Server相關資訊設定
自己的狀态，否則，繼續這個過程，直到leader被選舉出來。
通過流程分析我們可以得出：要使Leader獲得多數Server的支援，則Server總數必須是奇數2n+1，且
存活的Server的數目不得少于n+1.
fast paxos：
在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以後，
解決epoch和 zxid的沖突，并接受對方的提議，然後向對方發送接受提議完成的消息，重複這個流
程，最後一定能選舉出Leader。
除了和dubbo組合使用，還能在哪裡使用？
Apache HBase使用ZooKeeper跟蹤分布式資料的狀态。
zookeeper底層了解不多，本篇會有很多認識上的問題，希望大家多多提意見和問題。