Zookeeper 服務注冊中心

Zookeeper 官網

ZooKeeper：分布式應用程序的分布式協調服務

ZooKeeper 是分布式應用程序的分布式開源協調服務。它公開了一組簡單的原語，分布式應用程序可以基于這些原語來實現更高級別的同步、配置維護以及組和命名服務。它被設計為易于編程，并使用以熟悉的文件系統目錄樹結構為樣式的數據模型。它在 Java 中運行，并具有 Java 和 C 的綁定。

眾所周知，協調服務很難做好。它們特別容易出現諸如競爭條件和死鎖之類的錯誤。ZooKeeper 背后的動機是減輕分布式應用程序從頭開始實現協調服務的責任。

設計目標

ZooKeeper 很簡單。 ZooKeeper 允許分布式進程通過共享的分層命名空間相互協調，該命名空間的組織類似于標準文件系統。命名空間由數據寄存器組成——在 ZooKeeper 中稱為 znodes——這些類似于文件和目錄。與典型的為存儲而設計的文件系統不同，ZooKeeper 數據保存在內存中，這意味著 ZooKeeper 可以實現高吞吐量和低延遲。

ZooKeeper 實現非常重視高性能、高可用、嚴格有序的訪問。ZooKeeper 的性能方面意味著它可以用于大型分布式系統?？煽啃苑矫媸蛊洳粫蔀閱吸c故障。嚴格的排序意味著可以在客戶端實現復雜的同步原語。

**ZooKeeper 被復制。**就像它協調的分布式進程一樣，ZooKeeper 本身旨在通過一組稱為集合的主機進行復制。

組成 ZooKeeper 服務的服務器必須相互了解。它們維護內存中的狀態圖像，以及持久存儲中的事務日志和快照。只要大多數服務器可用，ZooKeeper 服務就可用。

客戶端連接到單個 ZooKeeper 服務器。客戶端維護一個 TCP 連接，通過它發送請求、獲取響應、獲取監視事件和發送心跳。如果與服務器的 TCP 連接中斷，客戶端將連接到不同的服務器。

**ZooKeeper 已訂購。**ZooKeeper 用反映所有 ZooKeeper 事務順序的數字標記每個更新。后續操作可以使用順序來實現更高級別的抽象，例如同步原語。

**ZooKeeper 速度很快。**它在“讀取主導”工作負載中特別快。ZooKeeper 應用程序在數千臺機器上運行，它在讀取比寫入更常見的情況下表現最佳，比率約為 10:1。

數據模型和分層命名空間

ZooKeeper 提供的命名空間很像標準文件系統的命名空間。名稱是由斜杠 (/) 分隔的一系列路徑元素。ZooKeeper 命名空間中的每個節點都由路徑標識。

ZooKeeper 的分層命名空間

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-pI4DouOu-1623079005390)(C:\Users\ASUS\Desktop\spring-boot系列\springcloud\zookeeper.assets\image-20210607222849533.png)]

節點和臨時節點

與標準文件系統不同，ZooKeeper 命名空間中的每個節點都可以擁有與其關聯的數據以及子節點。這就像擁有一個允許文件也成為目錄的文件系統。（ZooKeeper 旨在存儲協調數據：狀態信息、配置、位置信息等，因此每個節點存儲的數據通常很小，在字節到千字節范圍內。）我們使用術語znode來明確我們正在談論 ZooKeeper 數據節點。

Znodes 維護一個統計結構，其中包括數據更改、ACL 更改和時間戳的版本號，以允許緩存驗證和協調更新。每次 znode 的數據更改時，版本號都會增加。例如，每當客戶端檢索數據時，它也會收到數據的版本。

存儲在命名空間中每個 znode 的數據是原子讀寫的。讀取獲取與 znode 關聯的所有數據字節，寫入替換所有數據。每個節點都有一個訪問控制列表 (ACL)，它限制了誰可以做什么。

ZooKeeper 也有臨時節點的概念。只要創建 znode 的會話處于活動狀態，這些 znode 就存在。當會話結束時，znode 被刪除。

有條件的更新和監視

動物園管理員支持的概念手表?？蛻舳丝梢栽?znode 上設置監視。當 znode 發生變化時，會觸發并移除 watch。當 watch 被觸發時，客戶端會收到一個數據包，說 znode 已經改變了。如果客戶端和 ZooKeeper 服務器之一之間的連接中斷，客戶端將收到本地通知。

**3.6.0 中的新功能：**客戶端還可以在 znode 上設置永久的遞歸監視，在觸發時不會刪除這些監視，并且會以遞歸方式觸發注冊的 znode 以及任何子 znode 上的更改。

保證

ZooKeeper 非?？焖偾曳浅：唵巍５?#xff0c;由于它的目標是成為構建更復雜服務（例如同步）的基礎，因此它提供了一組保證。這些都是：

• 順序一致性 - 來自客戶端的更新將按發送順序應用。
• 原子性 - 更新要么成功要么失敗。沒有部分結果。
• 單一系統映像 - 無論連接到哪個服務器，客戶端都將看到相同的服務視圖。即，即使客戶端故障轉移到具有相同會話的不同服務器，客戶端也永遠不會看到系統的舊視圖。
• 可靠性 - 應用更新后，它將從那時起一直存在，直到客戶端覆蓋更新。
• 及時性 - 系統的客戶視圖保證在特定時間范圍內是最新的。

簡單的API

ZooKeeper 的設計目標之一是提供一個非常簡單的編程接口。因此，它僅支持以下操作：

• create : 在樹中的某個位置創建一個節點
• delete : 刪除一個節點
• 存在：測試節點是否存在于某個位置
• get data : 從節點讀取數據
• 設置數據：將數據寫入節點
• get children : 檢索節點的子節點列表
• sync : 等待數據被傳播

執行

ZooKeeper 組件顯示了 ZooKeeper 服務的高級組件。除了請求處理器之外，組成 ZooKeeper 服務的每個服務器都復制每個組件的自己的副本。

復制數據庫是包含整個數據樹的內存數據庫。更新會記錄到磁盤以實現可恢復性，并且寫入會在應用到內存數據庫之前序列化到磁盤。

每個 ZooKeeper 服務器都為客戶端提供服務?？蛻舳酥贿B接到一臺服務器來提交請求。讀取請求由每個服務器數據庫的本地副本提供服務。改變服務狀態的請求，寫請求，由協議協議處理。

作為協議協議的一部分，來自客戶端的所有寫請求都被轉發到一個稱為領導者的服務器。其余的 ZooKeeper 服務器，稱為follower，接收來自領導者的消息提議并就消息傳遞達成一致。消息傳遞層負責在失敗時替換領導者并將追隨者與領導者同步。

ZooKeeper 使用自定義原子消息傳遞協議。由于消息傳遞層是原子的，ZooKeeper 可以保證本地副本永遠不會發散。當領導者收到一個寫請求時，它會計算應用寫時系統的狀態，并將其轉換為捕獲這個新狀態的事務。

總結

以上是生活随笔為你收集整理的Zookeeper 服务注册中心的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。