一、Zookeeper工作機制 分散式和集中式系統相比，有很多優勢，比如更強的計算能力，存儲能力，避免單點故障等問題。但是由於在分散式部署的方式遇到網路故障等問題的時候怎麼保證各個節點數據的一致性和可用性是比較關鍵的問題。 那麼，對於分散式集群來說，我們需要一個能夠在各個服務和節點之間進行協調和服務 ...
一、Zookeeper工作機制
分散式和集中式系統相比，有很多優勢，比如更強的計算能力，存儲能力，避免單點故障等問題。但是由於在分散式部署的方式遇到網路故障等問題的時候怎麼保證各個節點數據的一致性和可用性是比較關鍵的問題。
那麼，對於分散式集群來說，我們需要一個能夠在各個服務和節點之間進行協調和服務的中間人——Zookeeper。
Zookeeper從設計模式角度來理解：是一個基於觀察者模式設計的分散式服務管理框架，負責存儲和管理大家都關心的數據，然後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上註冊的那些觀察者做出相應的回應。
二、數據結構
Zookeeper的數據結構和linux的目錄結構類似，也像數據結構中的樹，如下圖：
Zookeeper的數據存儲基於節點，這種節點稱為Znode。Znode的引用方式是路徑的引用，每個Znode都可以通過其路徑唯一標識。
其中Znode中包含有：數據，子節點引用，訪問許可權等，如下圖：
- data：Znode存儲的數據信息
- ACL：記錄Znode的訪問許可權，即哪些人或哪些IP可以訪問本節點
- child：當前節點的子節點引用，類似於二叉樹的左孩子右孩子
- stat：包含Znode的各種元數據，比如事務ID、版本號、時間戳、大小等等
stat 查看根目錄的詳細信息：
[zk: localhost:2181(CONNECTED) 0] stat /
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1
三、選舉機制
Zookeeper集群是一主多從的模式，主為leader，從為follower，其中leader是通過選舉得到。
Zookeeper集群有如下特點：
- Zookeeper：一個領導者（leader），多個跟隨者（follower）組成的集群
- Leader負責進行投票的發起和決議，更新系統狀態
- Follower用於接收客戶請求並向客戶端返回結果，在選舉Leader過程中參與投票
- 集群中只要有半數以上節點存活，Zookeeper集群就能正常服務，所以Zookeeper適合安裝奇數台伺服器
- 全局數據一致：每個server保存一份相同的數據副本，client無論連接到哪個server，數據都是一致的
- 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
- 數據更新原子性，一次數據更新要麼成功，要麼失敗
- 實時性，在一定時間範圍內，client能讀到最新數據
Leader選舉是保證分散式數據一致性的關鍵所在，當Zookeeper進入以下兩種狀態時，需要進入leader選舉：
- 伺服器初始化啟動
- leader宕機掛掉
- 伺服器初始化啟動時的選舉
（1）以三台伺服器組成的集群為例，在集群的初始化階段，當server1啟動時，其單獨無法完成選舉；當server2啟動時，此時兩台機器可以互相通信，每台機器都試圖找到leader，於是進入選舉狀態
（2）每個server首先給自己投票：初始階段，每個伺服器都將自己作為leader來投票，每次投票包含的信息有（myid，ZXID，epoch），此時Server1的投票為(1, 0)，Server2的投票為(2, 0)，然後各自將這個投票發給集群中其他機器
其中epoch用來判斷多個投票是否在同一輪選舉周期中，該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操作
（3）每個server接受來自各個伺服器的投票：集群的每個伺服器收到投票後，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的伺服器
（4）處理投票。針對每一個投票，伺服器都需要將別人的投票和自己的投票進行PK，PK規則如下：
- 優先檢查ZXID。ZXID比較大的伺服器優先作為Leader
- 如果ZXID相同，那麼就比較myid。myid較大的伺服器作為Leader伺服器
對於Server1而言，它的投票是(1, 0)，接收Server2的投票為(2, 0)，首先會比較兩者的ZXID，均為0，再比較myid，此時Server2的myid最大，於是更新自己的投票為(2, 0)，然後重新投票，對於Server2而言，其無須更新自己的投票，只是再次向集群中所有機器發出上一次投票信息即可
（5）統計投票。每次投票後，伺服器都會統計投票信息，判斷是否已經有過半機器接受到相同的投票信息，對於Server1、Server2而言，都統計出集群中已經有兩台機器接受了(2, 0)的投票信息，此時便認為已經選出了Leader，一旦選出leader，後邊的機器不管myid和ZXID多大，都自動成為leader的小弟
（6）改變伺服器狀態。一旦確定了Leader，每個伺服器就會更新自己的狀態，如果是Follower，那麼就變更為FOLLOWING，如果是Leader，就變更為LEADING
- leader伺服器掛掉的投票機制
與啟動時不同的就是，每個伺服器上都有歷史數據，在選舉之前，首先非leader的伺服器改變狀態為LOOKING狀態，因為運行期間每個伺服器ZXID不同，會和啟動時的選舉一樣進行重新投票選舉。
四、監聽機制
- 首先要有一個main()線程
- 在main線程中創建Zookeeper客戶端，這時就會創建兩個線程，一個負責網路連接通信（connet），一個負責監聽（listener）
- 通過connect線程將註冊的監聽事件發送給Zookeeper
- 在Zookeeper的註冊監聽器列表中將註冊的監聽事件添加到列表中
- Zookeeper監聽到有數據或路徑變化，就會將這個消息發送給listener線程
- listener線程內部調用了process（）方法
五、API應用
Zookeeper常用的API如下：
create
創建節點
delete
刪除節點
exists
判斷節點是否存在
getData
獲得一個節點的數據
setData
設置一個節點的數據
getChildren
獲取節點下的所有子節點這其中，exists，getData，getChildren屬於讀操作。Zookeeper客戶端在請求讀操作的時候，可以選擇是否設置Watch。
Watch是什麼意思呢？
我們可以理解成是註冊在特定Znode上的觸發器。當這個Znode發生改變，也就是調用了create，delete，setData方法的時候，將會觸發Znode上註冊的對應事件，請求Watch的客戶端會接收到非同步通知。
具體交互過程如下：
- 客戶端調用getData方法，watch參數是true。服務端接到請求，返回節點數據，並且在對應的哈希表裡插入被Watch的Znode路徑，以及Watcher列表。
- 當被Watch的Znode已刪除，服務端會查找哈希表，找到該Znode對應的所有Watcher，非同步通知客戶端，並且刪除哈希表中對應的Key-Value
六、應用場景
Zookeeper提供的服務包括：統一命名服務、統一配置管理、統一集群管理、伺服器節點動態上下線、軟負載均衡等。
