分佈式協調工具zookeeper——應用場景以及數據結構(一)

一、簡介

1.什麼是zookeeper

    zookeeper是一個用Java語言編寫的開源分佈式協調工具。

2.zookeeper的應用場景

    ①事件通知 (類似於發佈訂閱功能)

    發佈與訂閱模型,即所謂的配置中心,顧名思義就是發佈者將數據發佈到ZK節點上,供訂閱者動態獲取數據,實現配置信息的集中式管理和動態更新。

   ②命名服務(註冊中心)

    命名服務也是分佈式系統中比較常見的一類場景。在分佈式系統中,通過使用命名服務,客戶端應用能夠根據指定名字來獲取資源或服務的地址,提供者等信息。被命名的實體通常可以是集羣中的機器,提供的服務地址,遠程對象等等——這些我們都可以統稱他們爲名字(Name)。其中較爲常見的就是一些分佈式服務框架中的服務地址列表。dubbo就是使用zookeeper作爲命名服務,維護全局的服務地址列表。

    ③分佈式配置中心

    zookeeper可以動態的管理配置文件信息,支持傳統的配置文件模式,也支持key-value的數據結構,可以穩定操作,並且具有時效性。

    ④分佈式事務

    ⑤分佈式鎖

    分佈式鎖,這個主要得益於ZooKeeper爲我們保證了數據的強一致性,zk集羣中任意節點(一個zk server)上的相同znode的數據是一定是相同的,鎖服務可以分爲兩類,一個是 保持獨佔,另一個是 控制時序。

    ⑥選舉策略

   Master選舉是一個在分佈式系統中非常常見的應用場景。在分佈式系統中,Master往往用來協調系統中的其他系統單元,具有對分佈式系統狀態變更的決定權。利用zookeeper的強一致性,能夠很好地保證在分佈式高併發情況下節點的創建一定能保證全局唯一性,即zookeeper將會保證客戶端無法重複創建一個已經存在的數據節點。也就是說,如果同時有多個客戶端請求創建同一個節點,那麼最終一定只有一個客戶端能夠創建成功。利用這個特性,就很容易在分佈式環境中進行Master選舉。

    ⑦負載均衡

    這裏說的負載均衡是指軟負載均衡。在分佈式環境中,爲了保證高可用性,通常同一個應用或同一個服務的提供方都會部署多份,達到對等服務。而消費者就須要在這些對等的服務器中選擇一個來執行相關的業務邏輯,其中比較典型的是消息中間件中的生產者,消費者負載均衡。

    ⑧分佈式隊列

    隊列方面,簡單地講有兩種,一種是常規的先進先出隊列,另一種是要等到隊列成員聚齊之後的才統一按序執行。對於第一種先進先出隊列,和分佈式鎖服務中的控制時序場景基本原理一致。

二、zookeeper的數據結構

Zookeeper 的數據模型圖:

Zookeeper 節點類型可以分爲三大類:持久性節點(Persistent)、臨時性節點(Ephemeral)、順序性節點(Sequential)。現實開發中在創建節點的時候通過組合可以生成以下四種節點類型:持久節點、持久順序節點、臨時節點、臨時順序節點。

   ①持久節點就是節點被創建後會一直存在服務器,直到刪除操作主動清除。

   ②持久順序節點就是有順序的持久節點,節點特性和持久節點是一樣的,只是額外特性表現在順序上。順序特性實質是在創建節點的時候,會在節點名後面加上一個數字後綴,來表示其順序。

    ③臨時節點就是會被自動清理掉的節點,它的生命週期和客戶端會話綁在一起,客戶端會話結束,節點會被刪除掉。與持久性節點不同的是,臨時節點不能創建子節點。

    ④臨時順序節點就是有順序的臨時節點,和持久順序節點相同,在其創建的時候會在名字後面加上數字後綴。

注:在同一級節點名稱不可以相同,就類似於創建文件夾一樣,同名文件夾不能並列存在,但是子文件夾可以使用與父文件的兄弟名稱。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章