一文了解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來實現。

1. 將配置文件寫入Zookeeper的一個ZNode
2. 各個客戶端服務監聽這個ZNode
3. 一旦ZNode發生改變，Zookeeper將通知各個客戶端服務

2.3 統一集羣管理

Zookeeper能夠實現實時監控節點狀態變化，當有一個三個節點的服務，假如其餘一個宕機了，其餘兩個節點可當即收到消息，實現實時監控。將這三個節點寫入Zookeeper的一個ZNode，每一個節點都去監聽這個ZNode，當ZNode發生變化時，這些節點可實時收到變化狀態。

監聽器的原理

1. 建立一個Main()線程
2. 在Main()線程中建立兩個線程，一個負責網絡鏈接通訊（connect），一個負責監聽（listener）
3. 經過connect線程將註冊的監聽事件發送給Zookeeper
4. 將註冊的監聽事件添加到Zookeeper的註冊監聽器列表中
5. Zookeeper監聽到有數據或路徑發生變化時，把這條消息發送給Listener線程
6. 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旅途」進行關注。回覆「1024」便可得到學習視頻及精美電子書。天天7:30準時推送技術文章，讓你的上班路不在孤獨，並且每個月還有送書活動，助你提高硬實力！