歡迎光臨
每天分享高質量文章

什麼是ZooKeeper

來源:Java3y(ID:java3y)

ZooKeeper相信大家已經聽過這個詞了,不知道大家對他瞭解多少呢?我第一次聽到ZooKeeper的時候是在學Eureka的時候,同樣ZooKeeper也可以作為註冊中心

後面聽到ZooKeeper的時候,是因為ZooKeeper可以作為分佈式鎖的一種實現。

直至在瞭解Kafka的時候,發現Kafka也需要依賴ZooKeeper。Kafka使用ZooKeeper管理自己的元資料配置

這篇文章來寫寫我學習ZooKeeper的筆記,如果有錯的地方希望大家可以在評論區指出。

一、什麼是ZooKeeper

從上面我們也可以發現,好像哪都有ZooKeeper的身影,那什麼是ZooKeeper呢?我們先去官網看看介紹:

官網對ZooKeeper的介紹

官網還有另一段話:

ZooKeeper: A Distributed Coordination Service for Distributed Applications

相比於官網的介紹,我其實更喜歡Wiki中對ZooKeeper的介紹:

wiki介紹ZooKeeper

(留下不懂英語的淚水)

我簡單概括一下:

  • ZooKeeper主要服務於分佈式系統,可以用ZooKeeper來做:統一配置管理、統一命名服務、分佈式鎖、集群管理。
  • 使用分佈式系統就無法避免對節點管理的問題(需要實時感知節點的狀態、對節點進行統一管理等等),而由於這些問題處理起來可能相對麻煩和提高了系統的複雜性,ZooKeeper作為一個能夠通用解決這些問題的中間件就應運而生了。

二、為什麼ZooKeeper能幹這麼多?

從上面我們可以知道,可以用ZooKeeper來做:統一配置管理、統一命名服務、分佈式鎖、集群管理。

  • 這裡我們不管統一配置管理、統一命名服務、分佈式鎖、集群管理每個具體的含義(後面會講)

那為什麼ZooKeeper可以乾那麼多事?來看看ZooKeeper究竟是何方神物,在Wiki中其實也有提到:

ZooKeeper nodes store their data in a hierarchical name space, much like a file system or a tree data structure

ZooKeeper的資料結構,跟Unix檔案系統非常類似,可以看做是一顆,每個節點叫做ZNode。每一個節點可以通過路徑來標識,結構圖如下:

ZooKeeper結構圖

那ZooKeeper這顆”樹”有什麼特點呢??ZooKeeper的節點我們稱之為Znode,Znode分為兩種型別:

  • 短暫/臨時(Ephemeral):當客戶端和服務端斷開連接後,所創建的Znode(節點)會自動刪除
  • 持久(Persistent):當客戶端和服務端斷開連接後,所創建的Znode(節點)不會刪除

ZooKeeper和Redis一樣,也是C/S結構(分成客戶端和服務端)

Znode和Znode的型別

2.1 監聽器

在上面我們已經簡單知道了ZooKeeper的資料結構了,ZooKeeper還配合了監聽器才能夠做那麼多事的。

常見的監聽場景有以下兩項:

  • 監聽Znode節點的資料變化
  • 監聽子節點的增減變化
監聽Znode節點的資料有無變化
監聽子節點的增減變化

沒錯,通過監聽+Znode節點(持久/短暫[臨時]),ZooKeeper就可以玩出這麼多花樣了。

三、ZooKeeper是怎麼做到的?

下麵我們來看看用ZooKeeper怎麼來做:統一配置管理、統一命名服務、分佈式鎖、集群管理。

3.1 統一配置管理

比如我們現在有三個系統A、B、C,他們有三份配置,分別是ASystem.yml、BSystem.yml、CSystem.yml,然後,這三份配置又非常類似,很多的配置項幾乎都一樣。

  • 此時,如果我們要改變其中一份配置項的信息,很可能其他兩份都要改。並且,改變了配置項的信息很可能就要重啟系統

於是,我們希望把ASystem.yml、BSystem.yml、CSystem.yml相同的配置項抽取出來成一份公用的配置common.yml,並且即便common.yml改了,也不需要系統A、B、C重啟。

系統A、B、C都使用著這份配置

做法:我們可以將common.yml這份配置放在ZooKeeper的Znode節點中,系統A、B、C監聽著這個Znode節點有無變更,如果變更了,及時響應。

系統A、B、C監聽著ZooKeeper的節點,一旦common.yml內容有變化,及時響應

參考資料:

  • 基於zookeeper實現統一配置管理
    • https://blog.csdn.net/u011320740/article/details/78742625

3.2 統一命名服務

統一命名服務的理解其實跟域名一樣,是我們為這某一部分的資源給它取一個名字,別人通過這個名字就可以拿到對應的資源。

比如說,現在我有一個域名www.java3y.com,但我這個域名下有多台機器:

  • 192.168.1.1
  • 192.168.1.2
  • 192.168.1.3
  • 192.168.1.4

別人訪問www.java3y.com即可訪問到我的機器,而不是通過IP去訪問。

通過名稱去訪問旗下的IP

3.3 分佈式鎖

鎖的概念在這我就不說了,如果對鎖概念還不太瞭解的同學,可參考下麵的文章

我們可以使用ZooKeeper來實現分佈式鎖,那是怎麼做的呢??下麵來看看:

系統A、B、C都去訪問/locks節點

系統A、B、C都去訪問locks節點

訪問的時候會創建帶順序號的臨時/短暫(EPHEMERAL_SEQUENTIAL)節點,比如,系統A創建了id_000000節點,系統B創建了id_000002節點,系統C創建了id_000001節點。

創建出臨時帶順序號的節點

接著,拿到/locks節點下的所有子節點(id_000000,id_000001,id_000002),判斷自己創建的是不是最小的那個節點

  • 如果是,則拿到鎖。
    • 釋放鎖:執行完操作後,把創建的節點給刪掉
  • 如果不是,則監聽比自己要小1的節點變化

舉個例子:

  • 系統A拿到/locks節點下的所有子節點,經過比較,發現自己(id_000000),是所有子節點最小的。所以得到鎖

  • 系統B拿到/locks節點下的所有子節點,經過比較,發現自己(id_000002),不是所有子節點最小的。所以監聽比自己小1的節點id_000001的狀態

  • 系統C拿到/locks節點下的所有子節點,經過比較,發現自己(id_000001),不是所有子節點最小的。所以監聽比自己小1的節點id_000000的狀態

  • ……

  • 等到系統A執行完操作以後,將自己創建的節點刪除(id_000000)。通過監聽,系統C發現id_000000節點已經刪除了,發現自己已經是最小的節點了,於是順利拿到鎖

  • ….系統B如上

3.4集群狀態

經過上面幾個例子,我相信大家也很容易想到ZooKeeper是怎麼”感知“節點的動態新增或者刪除的了。

還是以我們三個系統A、B、C為例,在ZooKeeper中創建臨時節點即可:

各維護一個臨時節點

只要系統A掛了,那/groupMember/A這個節點就會刪除,通過監聽groupMember下的子節點,系統B和C就能夠感知到系統A已經掛了。(新增也是同理)

除了能夠感知節點的上下線變化,ZooKeeper還可以實現動態選舉Master的功能。(如果集群是主從架構樣式下)

原理也很簡單,如果想要實現動態選舉Master的功能,Znode節點的型別是帶順序號的臨時節點(EPHEMERAL_SEQUENTIAL)就好了。

  • Zookeeper會每次選舉最小編號的作為Master,如果Master掛了,自然對應的Znode節點就會刪除。然後讓新的最小編號作為Master,這樣就可以實現動態選舉的功能了。

最後

這篇文章主要講解了ZooKeeper的入門相關的知識,ZooKeeper通過Znode的節點型別+監聽機制就實現那麼多好用的功能了!

當然了,ZooKeeper要考慮的事沒那麼簡單的,後面有機會深入的話,我還會繼續分享,希望這篇文章對大家有所幫助~

參考資料:

  • 分佈式服務框架 Zookeeper
    • https://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html
  • ZooKeeper初識整理(老酒裝新瓶)
    • https://lxkaka.wang/2017/12/21/zookeeper/
  • ZooKeeper
    • https://www.cnblogs.com/sunshine-long/p/9057191.html
  • ZooKeeper 的應用場景
    • https://zhuanlan.zhihu.com/p/59669985

    已同步到看一看
    赞(0)

    分享創造快樂