一文了解Zookeeper
Zookeeper是Apache開源的一個分布式框架，它主要為分布式應用提供協調服務。
Zookeeper主要負責存儲和管理大家都關心的數據，一旦這些數據的狀態發生變化，Zookeeper就會通知那些注冊在Zookeeper上的服務。簡單來講就是zookeeper=文件系統+通知機制。
一 Zookeeper的數據結構
Zookeeper的數據結構與Unix文件系統很類似，整體上可以看作是一棵樹，與Unix文件系統不同的是Zookeeper的每個節點都可以存放數據，每個節點稱作一個ZNode，默認存儲1MB的數據，每個ZNode都可以通過其路徑唯一標識。
1.1 四種類型的ZNode
- 持久化目錄節點：客戶端與Zookeeper斷開連接后，該節點依舊存在。
- 持久化順序編號目錄節點：客戶端與Zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱就行順序編號。
- 臨時目錄節點：客戶端與Zookeeper斷開連接后，該節點被刪除。
- 臨時順序編號目錄節點：客戶端與Zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱就行順序編號。
說明：創建ZNode時設置順序標識，ZNode名稱后會附加一個值，順序號是一個單調遞增的計數器，由父節點維護。
1.2 stat結構體
ZNode主要包含以下信息：
- czxid-創建節點的事務 zxid：
每次修改 ZooKeeper 狀態都會收到一個 zxid 形式的時間戳，也就是 ZooKeeper 事務 ID。
事務 ID 是 ZooKeeper 中所有修改總的次序。每個修改都有唯一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之前發生。
- ctime ：znode 被創建的毫秒數(從 1970 年開始)
- mzxid：znode 最后更新的事務 zxid
- mtime：znode 最后修改的毫秒數(從 1970 年開始)
- pZxid：znode 最后更新的子節點 zxid
- cversion：znode 子節點變化號，znode 子節點修改次數
- dataversion：znode 數據變化號
- aclVersion：znode 訪問控制列表的變化號
- ephemeralOwner：如果是臨時節點，這個是 znode 擁有者的 session id。如果不是臨時節
點則是 0
- dataLength：znode 的數據長度
- numChildren：znode 子節點數量
二 Zookeeper的應用場景
Zookeeper的主要應用場景有統一命名服務，統一配置管理，統一集群管理，服務器節點動態上下線等。
2.1 統一命名服務
在分布式環境中，經常需要對服務進行統一命名，假如有一個服務部署了2兩個副本，直接調用具體的服務肯定有些不合適，因為我們并不清楚哪個服務可以更快的處理我們的請求，這時候我們可以將這三個服務進行統一命名，然后其內部再去負載。這樣就可以調用最優的那個服務了。
2.2 統一配置管理
分布式環境下，配置文件的同步可以由Zookeeper來實現。
- 將配置文件寫入Zookeeper的一個ZNode
- 各個客戶端服務監聽這個ZNode
- 一旦ZNode發生改變，Zookeeper將通知各個客戶端服務
2.3 統一集群管理
Zookeeper可以實現實時監控節點狀態變化，當有一個三個節點的服務，假如其他一個宕機了，其他兩個節點可立即收到消息，實現實時監控。將這三個節點寫入Zookeeper的一個ZNode，每個節點都去監聽這個ZNode，當ZNode發生變化時，這些節點可實時收到變化狀態。
監聽器的原理
- 創建一個Main()線程
- 在Main()線程中創建兩個線程，一個負責網絡連接通信(connect)，一個負責監聽(listener)
- 通過connect線程將注冊的監聽事件發送給Zookeeper
- 將注冊的監聽事件添加到Zookeeper的注冊監聽器列表中
- Zookeeper監聽到有數據或路徑發生變化時，把這條消息發送給Listener線程
- Listener線程內部調用process()方法
三 Zookeeper集群
Zookeeper集群雖然沒有指定Master和Slave。但是，在Zookeeper工作時，會通過內部選舉機制產生一個Leader節點，其他節點為Follower或者是Observer。
被聲明為Observer的節點，不參與選舉過程，也不參與寫操作的”過半寫成功“策略。
過半寫成功策略：Leader節點接收到寫請求后，這個Leader會將寫請求廣播給各個server，各個server會將該寫請求加入待寫隊列，并向Leader發送成功信息，當Leader收到一半以上的成功消息后，說明該寫操作可以執行。Leader會向各個server發送提交消息，各個server收到消息后開始寫。
Follower和Observer只提供數據的讀操作，當他們接收的寫請求時，會將該請求轉發給Leader節點。
集群中只要有半數以上的節點存活，Zookeeper集群就能正常服務。因此Zookeeper集群適合安裝奇數臺機器。
3.1 選舉機制
(1)服務器 1 啟動，發起一次選舉。服務器 1 投自己一票。此時服務器 1 票數一票，不夠半數以上(3 票)，選舉無法完成，服務器 1 狀態保持為 LOOKING;
(2)服務器 2 啟動，再發起一次選舉。服務器 1 和 2 分別投自己一票并交換選票信息：此時服務器 1 發現服務器 2 的 ID 比自己目前投票推舉的(服務器 1)大，更改選票為推舉服務器 2。此時服務器 1 票數 0 票，服務器 2 票數 2 票，沒有半數以上結果，選舉無法完成，服務器 1，2 狀態保持 LOOKING;
(3)服務器 3 啟動，發起一次選舉。此時服務器 1 和 2 都會更改選票為服務器 3。此次投票結果：服務器 1 為 0 票，服務器 2 為 0 票，服務器 3 為 3 票。此時服務器 3 的票數已經超過半數，服務器 3 當選 Leader。服務器 1，2 更改狀態為 FOLLOWING，服務器 3 更改狀態為 LEADING;
(4)服務器 4 啟動，發起一次選舉。此時服務器 1，2，3 已經不是 LOOKING 狀態，不會更改選票信息。交換選票信息結果：服務器 3 為 3 票，服務器 4 為 1 票。此時服務器 4服從多數，更改選票信息為服務器 3，并更改狀態為 FOLLOWING;
(5)服務器 5 啟動，同 4 一樣當小弟。
本文轉載自微信公眾號「Java旅途」，可以通過以下二維碼關注。轉載本文請聯系Java旅途公眾號。
