一文了解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準時推送技術文章,讓你的上班路不在孤獨,而且每月還有送書活動,助你提升硬實力!