Zookeeper（一）：基本概念講解

Zookeeper詳解

一：基本概念

下面是百度百科的解釋：

• ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。
• ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
• ZooKeeper包含一個簡單的原語集，提供Java和C的接口。
• ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口，代碼在$zookeeper_home\src\recipes。其中分佈鎖和隊列有Java和C兩個版本，選舉只有Java版本。

道人自己的理解：

• Zookeeper 解決了什麼需求？道人覺得最根本的原因是，微服務興起、分佈式應用的興起導致。集羣如何管理節點，微服務中如何進行服務管理（服務註冊中心）。zookeeper這個中間件便是主要解決上述痛點（而且做得挺好）。

• 在道人眼中，zookeeper是一個開源的、對分佈式應用進行協調服務的項目，其主要的應用場景有：統一配置維護、統一域名服務、分佈式同步、服務註冊中心等，這些應用基於zookeeper的樹形文件系統（結構）以及其通知機制來實現。同時zookeeper在分佈式鎖上應用，是基於其代碼版本，提供的分佈式鎖、隊列、選舉的接口來實現的。

二：關鍵名詞解釋

結構模型圖

1. ZK的數據結構

• 樹形文件系統：Zookeeper提供一個多層級的節點命名空間（節點稱爲znode）。與文件系統不同的是，這些節點都可以設置關聯的數據，而文件系統中只有文件節點可以存放數據而目錄節點不行。Zookeeper爲了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得Zookeeper不能用於存放大量的數據，每個節點的存放數據上限爲1M。
• 通知機制：client端會對某個znode建立一個watcher事件，當該znode發生變化時，這些client會收到zk的通知，然後client可以根據znode變化來做出業務上的改變等

2. 節點類型

• Znode 兼具文件和目錄兩種特點。既像文件一樣維護着數據、元信息、ACL、 時間戳等數據結構，又像目錄一樣可以作爲路徑標識的一部分，並可以具有 子 Znode。用戶對 Znode 具有增、刪、改、查等操作(權限允許的情況下)。
• Znode 具有原子性操作，讀操作將獲取與節點相關的所有數據，寫操作也將 替換掉節點的所有數據。另外，每一個節點都擁有自己的 ACL(訪問控制列 表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點可以執行的 操作
• Znode 存儲數據大小有限制。ZooKeeper 雖然可以關聯一些數據，但並沒有 被設計爲常規的數據庫或者大數據存儲，相反的是，它用來管理調度數據， 比如分佈式應用中的配置文件信息、狀態信息、彙集位置等等。這些數據的 共同特性就是它們都是很小的數據，通常以 KB 爲大小單位。ZooKeeper 的服 務器和客戶端都被設計爲嚴格檢查並限制每個 Znode 的數據大小至多 1M，當 時常規使用中應該遠小於此值。
• Znode 通過路徑引用，如同 Unix 中的文件路徑。路徑必須是絕對的，因此他 們必須由斜槓字符來開頭。除此以外，他們必須是唯一的，也就是說每一個 路徑只有一個表示，因此這些路徑不能改變。在 ZooKeeper 中，路徑由 Unicode 字符串組成，並且有一些限制。字符串"/zookeeper"用以保存管理 信息，比如關鍵配額信息。

zk節點類型的三大類：持久性節點（Persistent）、臨時性節點（Ephemeral）、順序性節點（Sequential）

• 持久節點（Persistent）：創建後會一直存在服務器，直到刪除操作主動清除。
• 持久順序節點（Persistent-Sequential）：持久性與持久節點一致，創建節點的時候，會在節點名後面加上一個數字後綴，來表示其順序。
• 臨時節點（Ephemeral）：會被自動清理掉的節點，它的生命週期和客戶端會話綁在一起，客戶端會話結束，節點會被刪除掉。
• 臨時順序節點（Ephemeral-Sequential）：就是有順序的臨時節點，和持久順序節點相同，在其創建的時候會在名字後面加上數字後綴。

3. 節點的內容信息

節點信息包括兩類：節點數據內容和節點狀態信息。

使用 “ls2 節點” 獲取節點信息

• cZxid 就是 Create ZXID，表示節點被創建時的事務 ID。
• mZxid 就是 Modified ZXID，表示節點最後一次被修改時的事務 ID。
• ctime 就是 Create Time，表示節點創建時間。
• mtime 就是 Modified Time，表示節點最後一次被修改的時間。
• pZxid 表示該節點的子節點列表最後一次被修改時的事務 ID。只有子節點列表變更纔會更新 pZxid，子節點內容變更不會更新。
• cversion 表示子節點的版本號。
• dataVersion 表示內容版本號。
• dataLength 表示數據長度。
• numChildren 表示子節點數。
• ephemeralOwner 表示創建該臨時節點時的會話
• sessionID，如果是持久性節點那麼值爲 0。

狀態信息：你可以理解其包括創建檢點的事務ID，最後一次修改事務ID，創建時間，修改時間，子節點最後一次被修改的事務，版本信息，數據長度，臨時節點會話信息等。

概括總結下

• 事務信息（ID）：自身節點（創建，最後一次修改）與子節點（最後一次修改）
• 時間信息：自身節點（創建，最後一次修改）
• 版本信息：自身內容版本號，子節點版本號
• 數據信息：數據長度，子節點數量
• 臨時信息：針對臨時節點的會話信息（會話ID）

4. Zookeeper的特點

• 順序一致性：
  從同一個客戶端發起的事務請求，最終將會嚴格按照其發起順序被應用到ZooKeeper中。
• 原子性：
  所有事務請求的結果在集羣中所有機器上的應用情況是一致的，也就是說要麼整個集羣所有集羣都成功應用了某一個事務，要麼都沒有應用，一定不會出現集羣中部分機器應用了該事務，而另外一部分沒有應用的情況。
• 單一視圖：
  無論客戶端連接的是哪個ZooKeeper服務器，其看到的服務端數據模型都是一致的。
• 可靠性：
  一旦服務端成功地應用了一個事務，並完成對客戶端的響應，那麼該事務所引起的服務端狀態變更將會被一直保留下來，除非有另一個事務又對其進行了變更。
• 實時性：
  通常人們看到實時性的第一反應是，一旦一個事務被成功應用，那麼客戶端能夠立即從服務端上讀取到這個事務變更後的最新數據狀態。這裏需要注意的是，ZooKeeper僅僅保證在一定的時間段內，客戶端最終一定能夠從服務端上讀取到最新的數據狀態。

都看到這了，道友們，點個贊再走唄！