理解 zookeeper

官網

zookeeper 是什麼

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.
ZooKeeper是一種集中式服務,用於維護配置信息,命名,提供分佈式同步和提供組服務。所有這些類型的服務都以分佈式應用程序的某種形式使用。每次實施分佈式應用都需要做很多工作來修復不可避免的錯誤和競爭條件。zookeeper就是爲了解決這些問題。

  • zookeeper 可以被用作註冊中心
  • 構建集羣的時候,最好是奇數臺服務器。

zookeeper 是一個典型的分佈式數據一致性的解決方案,分佈式的應用可以使用 zookeeper 來實現發佈/訂閱,服務命名,負載均衡,分佈式協調/通知,Master選舉,集羣管理,分佈式鎖和分佈式隊列等。

最常見的 zookeeper 就是用來當做分佈式註冊中心。例如 Dubbo 就是使用 zookeeper 作爲分佈式註冊中心,spring cloud 1 也是使用 zookeeper ,不過在 spring cloud 2 後,就建議使用 euraka 了。

概念

Session 會話

session 指的是 zookeeper 服務器與客戶端之間的通訊。在 zookeeper 中,一個客戶端連接指客戶端與服務器之間的一個 TCP 長連接。客戶端啓動時,必須先與服務器建立一個 TCP 連接,從第一次建立的時候,客戶端會話的生命週期也就是開始了。通過這個長連接,客戶端能夠通過心跳反應檢測和服務器保持這個會話,也能夠向 zookeeper 服務器發送請求並接受響應,同時還能通過該連接來接收服務器的 watch 事件通知。Session 的sessionTimeout 表示一個客戶端會話的超時時間。當服務器壓力過大、網絡波動或客戶端斷開連接等原因時,只要在 sessionTimeout 規定的時間內能夠重新連接,那麼就表示該會話依然有效。

在爲客戶端創建會話之前,服務器會爲每個客戶端分配一個 sessionID 。該 sessionID 必須保證全局唯一,因爲該 sessionID 是zookeeper 會話的一個重要標識,許多與會話相關的功能都需要這個 sessionID。

Znode 數據節點

zookeeper 將所有的數據存儲在內存中,數據模型是一棵樹(Znode Tree),由 / 進行分隔的路徑,就是一個 Znode。

在 zookeeper 中,node可以分爲持久節點和臨時節點。
持久節點:一旦這個Znode 被創建時,除非 zookeeper 主動刪除,否則這個 Znode 會一直保存在 zookeeper 上。
臨時節點:會話週期和session綁定,當會話失效,這個臨時節點就會被刪除。

STAT

ZooKeeper命名空間中的每個znode都有一個與之關聯的stat結構,類似於Unix/Linux文件系統中文件的stat結構。 znode的stat結構中的字段顯示如下,各自的含義如下:

  • cZxid:這是導致創建znode更改的事務ID。
  • mZxid:這是最後修改znode更改的事務ID。
  • pZxid:這是用於添加或刪除子節點的znode更改的事務ID。
  • ctime:表示從1970-01-01T00:00:00Z開始以毫秒爲單位的znode創建時間。
  • mtime:表示從1970-01-01T00:00:00Z開始以毫秒爲單位的znode最近修改時間。
  • dataVersion:表示對該znode的數據所做的更改次數。
  • cversion:這表示對此znode的子節點進行的更改次數。
  • aclVersion:表示對此znode的ACL進行更改的次數。
  • ephemeralOwner:如果znode是ephemeral類型節點,則這是znode所有者的 session ID。 如果znode不是ephemeral節點,則該字段設置爲零。
  • dataLength:這是znode數據字段的長度。
  • numChildren:這表示znode的子節點的數量。

watcher 事件監聽

zookeeper 允許用戶在指定節點上註冊一些 watcher ,並且在一些特定的事件觸發時,zookeeper 會將該事件通知到 對應的客戶端上。這個機制是 zookeeper 實現分佈式協調服務的重要特性。

ACL

zookeeper 採用 ACL(AccessControlLists)策略來進行權限控制,類型UNIX 文件系統的權限控制。 zookeeper 定義了5種權限。

  • CRETE:創建子節點的權限
  • READ:獲取節點數據和子節點列表的權限
  • WRITE:更新節點數據的權限
  • DELETE:刪除子節點的權限
  • ADMIN:設置節點的ACL的權限
    注意:CREATE和DELETE都是針對子節點的。

特點

  • 順序一致性:從同一客戶端發起的事物請求,最終將會嚴格的安裝順序被應用到 zookeeper 中。
  • 原子性:所有的事物請求的處理結果在集羣的所有服務器上的情況都是一樣的。
  • 單一系統映像:無論客戶端連接到哪個zookeeper ,看到的數據模型都是一致的。
  • 可靠性:一旦一次更改請求被應用,更改的結果就會被持久化,直到下一次被更改覆蓋。

ZAB 協議和 Paxos 算法

ZAB 協議

zookeeper atomic broadcast 原子廣播

分佈式協調服務 zookeeper 專門設計的一種支持崩潰恢復的原子廣播協議。在zookeeper 中,主要依賴ZAB 協議來實現分佈式數據一致性,基於該協議, zookeeper 實現了一種主備模式的系統架構保持集羣中各個副本之間數據的一致性。

ZAB 協議的2種基本模式:崩潰恢復 和 消息廣播

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