原文格式可以訪問：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，當節點從新恢復後，整個系統性能可以迅速恢復。

相關推薦