Zookeeper分佈式系統協同器概念快速學習

原文格式能夠訪問：https://www.rockysky.tech

分佈式系統的基本操做

1. 主節點選舉：在絕大多數分佈式系統中，都須要進行主節點選舉。主節點負責管理協調其它節點或者同步集羣中其它節點的數據。爲了確保集羣中一直存在一個主節點，須要有主節點的選舉機制。但現有主節點沒法訪問的時候，自動產生新的主節點接管集羣管理和協調的任務
2. 宕機檢測：當集羣中有某個節點或者某部分節點脫離集羣或者不可訪問的時候，分佈式系統的其餘節點能夠識別出來，並執行相應的步驟，去替換或者接管宕機節點的工做，使得整個集羣的功能不會受到影響。
3. 集羣組管理：對於比較大規模的分佈式系統，咱們須要管理其不一樣的分組。好比說Kubernetes集羣就須要管理基本的服務單位POD。如何去管理和協調每一個組的資源和任務分配也是分佈式系統必需要處理的任務。
4. 元數據管理（Metadata）：在一個分佈式系統中須要保存一些元數據。好比每一個節點正在執行的任務，任務的進度，各個節點的狀態。節點間須要共享的一些同步數據等等。

Zookeeper是什麼

Zookeeper是一個分佈式系統協調器，其自己並不直接實現上述的任何一個分佈式系統的基本操做。Zookeeper自己其實就是一個經過Raft共識機制協同的分佈式鍵值對文件存儲系統。Zookeeper的文件以樹狀形式存儲，每一個節點均可以存儲數據，每一個節點叫作一個znode，以下圖所示：

和普通的文件結構不一樣，Zookeeper沒有目錄的概念，每一個節點均可以存儲數據。

持久性節點（Persistent）和易失性（Ephemeral）節點

Zookeeper的節點分爲兩種主要的類型，即持久性節點和易失性節點，

• 持久性節點（Persistent），這種節點的數據必須可以一直保存，即便寫入這些數據的客戶端鏈接丟失，或者客戶端宕機。這些節點和數據任然必須保留。舉個例子，好比說一個並行運算的集羣，給每一個slave節點分配的運算任務必需要可以記錄下來，即便集羣的master節點或者slave節點宕機，爲了保證最後的運算可以完整，也不可以把這些任務刪除。
• 易失性節點（Ephemeral）一旦客戶端自己鏈接中斷或者宕機，這些數據節點會被釋放。例如，一個集羣的Master節點掛了，那這個Master節點的鎖就必需要釋放出來，這個鎖的機制就能夠用易失性節點來完成。

有條件的更新和Watch機制

Zookeeper支持一種watches機制。客戶端能夠給znode設定watch機制，一旦這個znode被更新，就會觸發通知機制發送消息給客戶端，同時刪除這個watch。若是ZooKeeper服務器自己掛掉了，那客戶端會直接收到本地通知。

ZooKeeper保證的是什麼

ZooKeeper的設計原則

Zookeeper自己被設計爲一個很是簡單，高速和可靠的服務。從而爲各種分佈式系統提供高級別和負責的分佈式系統基本操做。對於分佈式系統的CAP分類中，ZooKeeper是一種CP系統，重點保證的是強一致性。包括如下的特色：

• 順序一致性：客戶端對節點的更新必定會保證其最終更新前後順序的的一致性

• 原子性：對znode的更新只會有成功，失敗兩種狀態，不會有中間結果

• 單點一致性：客戶端對zookeeper集羣中任何一節點看到的znode結構和數據徹底相同

• 高可靠性：一旦對znode更新成功，其結果會一直保持，直到下一次變動

• 時效性：在必定時間段，確保系統數據最新（up-to-date）

  不過須要注意的是Zookeeper不確保數據的可用性，必需要等到全部ZooKeeper集羣節點都同步成功，數據更新纔會確認操做成功。這是纔可以讀取這個數據。時效性是值得可以確保在必定的時間段內能夠完成數據跟新和同步。

極爲簡單的API設計

Zookeeper經過API提供服務，提供如下幾個API。

• create : 在樹狀結構上建立znode
• delete : 刪除znode
• exists : 測試某個znode是否存在
• get data : 讀取某個znode的數據
• set data : 向Znode寫入數據
• get children : 獲取子節點列表
• sync : 等待全部zookeeper節點廣播和同步完成。

性能：

在大量讀和少許寫入的狀況先，Zookeeper性能是比較高的。

可靠性：

官方數據顯示，Zookeeper選舉主節點的時間大概在200ms，當節點重新恢復後，整個系統性能能夠迅速恢復。

原文出處：https://www.cnblogs.com/yangjian2006/p/12373994.html