Zookeeper是什么

這篇文章主要講解了“Zookeeper是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 將配置文件寫入Zookeeper的一個ZNode

3. 各個客戶端服務監聽這個ZNode

4. 一旦ZNode發生改變，Zookeeper將通知各個客戶端服務

2.3 統一集群管理

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

監聽器的原理

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 創建一個Main()線程

3. 在Main()線程中創建兩個線程，一個負責網絡連接通信(connect)，一個負責監聽(listener)

4. 通過connect線程將注冊的監聽事件發送給Zookeeper

5. 將注冊的監聽事件添加到Zookeeper的注冊監聽器列表中

6. Zookeeper監聽到有數據或路徑發生變化時，把這條消息發送給Listener線程

7. 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 一樣當小弟。

感謝各位的閱讀，以上就是“Zookeeper是什么”的內容了，經過本文的學習后，相信大家對Zookeeper是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！