ZooKeeper典型使用場景一覽

2021-09-01 21:43:42 字數 3198 閱讀 6882

場景類別典型場景描述(zk特性,使用方法)應用中的具體使用

資料發布與訂閱

發布與訂閱即所謂的配置管理,顧名思義就是將資料發布到zk節點上,供訂閱者動態獲取資料,實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊,位址列表等就非常適合使用。

1. 索引資訊和集群中機器節點狀態存放在zk的一些指定節點,供各個客戶端訂閱使用。2. 系統日誌(經過處理後的)儲存,這些日誌通常2-3天後被清除。

3. 應用中用到的一些配置資訊集中管理,在應用啟動的時候主動來獲取一次,並且在節點上註冊乙個watcher,以後每次配置有更新,實時通知到應用,獲取最新配置資訊。

4. 業務邏輯中需要用到的一些全域性變數,比如一些訊息中介軟體的訊息佇列通常有個offset,這個offset存放在zk上,這樣集群中每個傳送者都能知道當前的傳送進度。

5. 系統中有些資訊需要動態獲取,並且還會存在人工手動去修改這個資訊。以前通常是暴露出介面,例如jmx介面,有了zk後,只要將這些資訊存放到zk節點上即可。

name service

這個主要是作為分布式命名服務,通過呼叫zk的create node api,能夠很容易建立乙個全域性唯一的path,這個path就可以作為乙個名稱。

分布通知/協調

zookeeper中特有watcher註冊與非同步通知機制,能夠很好的實現分布式環境下不同系統之間的通知與協調,實現對資料變更的實時處理。使用方法通常是不同系統都對zk上同乙個znode進行註冊,監聽znode的變化(包括znode本身內容及子節點的),其中乙個系統update了znode,那麼另乙個系統能夠收到通知,並作出相應處理。

1. 另一種心跳檢測機制:檢測系統和被檢測系統之間並不直接關聯起來,而是通過zk上某個節點關聯,大大減少系統耦合。2. 另一種系統排程模式:某系統有控制台和推送系統兩部分組成,控制台的職責是控制推送系統進行相應的推送工作。管理人員在控制台作的一些操作,實際上是修改了zk上某些節點的狀態,而zk就把這些變化通知給他們註冊watcher的客戶端,即推送系統,於是,作出相應的推送任務。

3. 另一種工作匯報模式:一些類似於任務分發系統,子任務啟動後,到zk來註冊乙個臨時節點,並且定時將自己的進度進行匯報(將進度寫回這個臨時節點),這樣任務管理者就能夠實時知道任務進度。

總之,使用zookeeper來進行分布式通知和協調能夠大大降低系統之間的耦合。

分布式鎖分布式鎖,這個主要得益於zookeeper為我們保證了資料的強一致性,即使用者只要完全相信每時每刻,zk集群中任意節點(乙個zk server)上的相同znode的資料是一定是相同的。鎖服務可以分為兩類,乙個是保持獨佔,另乙個是控制時序。

所謂保持獨佔,就是所有試圖來獲取這個鎖的客戶端,最終只有乙個可以成功獲得這把鎖。通常的做法是把zk上的乙個znode看作是一把鎖,通過create znode的方式來實現。所有客戶端都去建立 /distribute_lock 節點,最終成功建立的那個客戶端也即擁有了這把鎖。

控制時序,就是所有檢視來獲取這個鎖的客戶端,最終都是會被安排執行,只是有個全域性時序了。做法和上面基本類似,只是這裡 /distribute_lock 已經預先存在,客戶端在它下面建立臨時有序節點(這個可以通過節點的屬性控制:createmode.ephemeral_sequential來指定)。zk的父節點(/distribute_lock)維持乙份sequence,保證子節點建立的時序性,從而也形成了每個客戶端的全域性時序。

集群管理

利用zookeeper有兩個特性,就可以實時另一種集群機器存活性監控系統:a. 客戶端在節點 x 上註冊乙個watcher,那麼如果 x 的子節點變化了,會通知該客戶端。b. 建立ephemeral型別的節點,一旦客戶端和伺服器的會話結束或過期,那麼該節點就會消失。

例如,監控系統在 /clusterservers 節點上註冊乙個watcher,以後每動態加機器,那麼就往 /clusterservers 下建立乙個 ephemeral型別的節點:/clusterservers/. 這樣,監控系統就能夠實時知道機器的增減情況,至於後續處理就是監控系統的業務了。

2.master選舉則是zookeeper中最為經典的使用場景了。

在分布式環境中,相同的業務應用分布在不同的機器上,有些業務邏輯(例如一些耗時的計算,網路i/o處理),往往只需要讓整個集群中的某一台機器進行執行,其餘機器可以共享這個結果,這樣可以大大減少重複勞動,提高效能,於是這個master選舉便是這種場景下的碰到的主要問題。

利用zookeeper的強一致性,能夠保證在分布式高併發情況下節點建立的全域性唯一性,即:同時有多個客戶端請求建立 /currentmaster 節點,最終一定只有乙個客戶端請求能夠建立成功。

利用這個特性,就能很輕易的在分布式環境中進行集群選取了。

另外,這種場景演化一下,就是動態master選舉。這就要用到 ephemeral_sequential型別節點的特性了。

上文中提到,所有客戶端建立請求,最終只有乙個能夠建立成功。在這裡稍微變化下,就是允許所有請求都能夠建立成功,但是得有個建立順序,於是所有的請求最終在zk上建立結果的一種可能情況是這樣: /currentmaster/-1 , /currentmaster/-2 , /currentmaster/-3 ….. 每次選取序列號最小的那個機器作為master,如果這個機器掛了,由於他建立的節點會馬上小時,那麼之後最小的那個機器就是master了。

分布式佇列

佇列方面,我目前感覺有兩種,一種是常規的先進先出佇列,另一種是要等到佇列成員聚齊之後的才統一按序執行。對於第二種先進先出佇列,和分布式鎖服務中的控制時序場景基本原理一致,這裡不再贅述。

第二種佇列其實是在fifo佇列的基礎上作了乙個增強。通常可以在 /queue 這個znode下預先建立乙個/queue/num 節點,並且賦值為n(或者直接給/queue賦值n),表示佇列大小,之後每次有佇列成員加入後,就判斷下是否已經到達佇列大小,決定是否可以開始執行了。這種用法的典型場景是,分布式環境中,乙個大任務task a,需要在很多子任務完成(或條件就緒)情況下才能進行。這個時候,凡是其中乙個子任務完成(就緒),那麼就去 /tasklist 下建立自己的臨時時序節點(createmode.ephemeral_sequential),當 /tasklist 發現自己下面的子節點滿足指定個數,就可以進行下一步按序進行處理了。

ZooKeeper典型使用場景

zookeeper是乙個高可用的分布式資料管理與系統協調框架。基於對paxos演算法的實現,使該框架保證了分布式環境中資料的強一致性,也正是 基於這樣的特性,使得zookeeper能夠應用於很多場景。網上對zk的使用場景也有不少介紹,本文將結合作者身邊的專案例子,系統的對zk的使用場景 進行歸類介紹...

ZooKeeper典型應用場景

zookeeper 是乙個開源的高可用的分布式資料管理與系統協調框架,基於對 paxos 演算法的實現,保證了分布式環境中資料的強一致性。發布與訂閱模型 發布者發布資料到 zk 節點上,供訂閱者動態獲取資料。在資料量很少,但是資料更新快的場景下 訊息中介軟體中的發布者和訂閱者的負載均衡,linked...

ZooKeeper典型使用場景一覽

zookeeper是乙個高可用的分布式資料管理與系統協調框架。基於對paxos演算法的實現,使該框架保證了分布式環境中資料的強一致性,也正是基於這樣的特性,使得zookeeper能夠應用於很多場景。網上對zk的使用場景也有不少介紹,本文將結合作者身邊的專案例子,系統的對zk的使用場景進行歸類介紹。值...