zookeeper基礎概念

zookeeper基礎概念

1.1 ZooKeeper 概述

**Zookeeper 是一個分佈式協調服務的開源框架。**主要用來解決分佈式集羣中應用系統的一致性問題，例如怎樣避免同時操作同一數據造成髒讀的問題。
**ZooKeeper 本質上是一個分佈式的小文件存儲系統。**提供基於類似於文件系統的目錄樹方式的數據存儲，並且可以對樹中的節點進行有效管理。從而用來維護和監控你存儲的數據的狀態變化。通過監控這些數據狀態的變化，從而可以達到基於數據的集羣管理。諸如：統一命名服務、分佈式配置管理、分佈式消息隊列、分佈式鎖、分佈式協調等功能。

分佈式協調服務： 就是可以在分佈式配置中共享配置，協調鎖資源，提供命名服務等。

1.2 ZooKeeper 特性

1. 全局數據一致：★★★ 每個 server 保存一份相同的數據副本，client 無論連接到哪個 server，展示的數據都是一致的，這是最重要的特徵；
2. 可靠性：如果消息被其中一臺服務器接受，那麼將被所有的服務器接受。
3. 順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息 a 在消息 b 前發佈，則在所有 Server 上消息 a 都將在消息 b 前被髮布；偏序是指如果一個消息 b 在消息 a 後被同一個發送者發佈，a 必將排在 b 前面。
4. 數據更新原子性：一次數據更新要麼成功（半數以上節點成功），要麼失敗，不存在中間狀態；
5. 實時性：Zookeeper 保證客戶端將在一個時間間隔範圍內獲得服務器的更新信息，或者服務器失效的信息。不會超過幾十秒。
6. 單一系統映像： 一個客戶端無論連接到那一臺服務器，他看到的都是同樣的系統試圖。意思就是，如果客戶端無論因爲什麼，在同一個會話中連接到了一臺新的服務器，它所看到的數據都不會比之前的服務器看到的更老。當一臺服務器出現問題時，導致他的客戶端需要連接一臺新的服務器時，所有狀態滯後與故障服務器的服務器都不會接受該連接請求，除非這些服務器將狀態跟新值故障服務器的水平。
7. 持久性： 一旦對zookeeper操作成功，其結果就會持久存在，不會被撤銷。

跨客戶端試圖的同時一致性： 由於性能原因，可能客戶端A將znode的值從 a 更新爲 b ，通知客戶端B去獲取，然後B客戶端讀到的數據卻是 a ，不是 b ，這與zookeeper的一致性保證是完全兼容的。
解決： 爲了避免這種現象發生，客戶端B應該在都讀取前調用sync操作，將當前連接的服務器與leader的數據同步。

1.3 ZooKeeper 集羣角色

Leader:
Zookeeper 集羣工作的核心
事務請求（寫操作）的唯一調度和處理者，保證集羣事務處理的順序性；集羣內部各個服務器的調度者。
對於 create，setData，delete 等有寫操作的請求，則需要統一轉發給leader 處理，leader 需要決定編號、執行操作，這個過程稱爲一個事務。

可以通過將 leaderServes 屬性設置爲no來實現是領導者不接受任何客戶端的連接，在這種情況下，領導者的唯一任務就是協調更新。

Follower:
處理客戶端非事務（讀操作）請求，轉發事務請求給 Leader；
參與集羣 Leader 選舉投票。

此外，針對訪問量比較大的 zookeeper 集羣，還可新增觀察者角色。
Observer:
觀察者角色，觀察 Zookeeper 集羣的最新狀態變化並將這些狀態同步過來，其對於非事務請求可以進行獨立處理，對於事務請求，則會轉發給 Leader服務器進行處理。
不會參與任何形式的投票只提供非事務服務，通常用於在不影響集羣事務處理能力的前提下提升集羣的非事務處理能力。

1.4 ZooKeeper 數據模型

ZooKeeper 的數據模型，在結構上和標準文件系統的非常相似，擁有一個層次的命名空間，都是採用樹形層次結構，ZooKeeper 樹中的每個節點被稱爲—Znode。和文件系統的目錄樹一樣ZooKeeper 樹中的每個節點可以擁有子節點。
但也有不同之處：

1. **Znode 兼具文件和目錄兩種特點。**既像文件一樣維護着數據、元信息、ACL、時間戳等數據結構，又像目錄一樣可以作爲路徑標識的一部分，並可以具有子 Znode。用戶對 Znode 具有增、刪、改、查等操作（權限允許的情況下）。

2. **Znode 具有原子性操作，讀操作將獲取與節點相關的所有數據，寫操作也將替換掉節點的所有數據。**另外，每一個節點都擁有自己的 ACL(訪問控制列表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點可以執行的操作。

3. **Znode 存儲數據大小有限制。**ZooKeeper 雖然可以關聯一些數據，但並沒有被設計爲常規的數據庫或者大數據存儲，相反的是，它用來管理調度數據，比如分佈式應用中的配置文件信息、狀態信息、彙集位置等等。這些數據的共同特性就是它們都是很小的數據，通常以 KB 爲大小單位。ZooKeeper 的服務器和客戶端都被設計爲嚴格檢查並限制每個 Znode 的數據大小至多 1M，當時常規使用中應該遠小於此值。

4. **Znode 通過路徑引用，如同 Unix 中的文件路徑。**路徑必須是絕對的（絕對路徑），因此他們必須由斜槓字符來開頭。除此以外，他們必須是唯一的，也就是說每一個路徑只有一個表示，因此這些路徑不能改變。在 ZooKeeper 中，路徑由Unicode 字符串組成，並且有一些限制。字符串"/zookeeper"用以保存管理信息，比如關鍵配額信息。

   所有的路徑表示必須是規範的，機每條路徑只有唯一的一種表示方式，不支持路徑解析。

   在zookeeper中，不能使用 “.” 來代表當前路徑下。

圖中的每個節點稱爲一個 Znode。 每個 Znode 由 4 部分組成:

1. stat：此爲狀態信息, 描述該 Znode 的版本, 權限等信息
2. data：與該 Znode 關聯的數據
3. children：該 Znode 下的子節點
4. ACL：記錄Znode的訪問權限，即哪些人或哪些IP可以訪問本節點。

1.5 節點屬性

每個 znode 都包含了一系列的屬性，通過命令 get 節點路徑，可以獲得節點的屬性。

• **dataVersion：**數據版本號，每次對節點進行 set 操作，dataVersion 的值都會增加 1（即使設置的是相同的數據），可有效避免了數據更新時出現的先後順序問題。
• **cversion ：**子節點的版本號。當 znode 的子節點有變化時，cversion 的值就會增加 1。
• **aclVersion ：**ACL 的版本號。
• **cZxid ：**Znode 創建的事務 id。
• **mZxid ：**Znode 被修改的事務 id，即每次對 znode 的修改都會更新 mZxid。對於 zk 來說，每次的變化都會產生一個唯一的事務 id，zxid（ZooKeeper Transaction Id）。通過 zxid，可以確定更新操作的先後順序。例如，如果 zxid1小於 zxid2，說明 zxid1 操作先於 zxid2 發生，zxid 對於整個 zk 都是唯一的，即使操作的是不同的 znode。
• **ctime：**節點創建時的時間戳.
• **mtime：**節點最新一次更新發生時的時間戳.
• **ephemeralOwner：**如果該節點爲臨時節點, ephemeralOwner 值表示與該節點綁定的 session id. 如果不是, ephemeralOwner 值爲 0.
  在 client 和 server 通信之前,首先需要建立連接,該連接稱爲 session。連接建立後,如果發生連接超時、授權失敗,或者顯式關閉連接,連接便處於 CLOSED狀態, 此時 session 結束

1.6 節點類型

Znode 有兩種，分別爲臨時節點和永久節點。節點的類型在創建時即被確定，並且不能改變。

• 臨時節點：該節點的生命週期依賴於創建它們的會話。一旦會話結束，臨時節點將被自動刪除，當然可以也可以手動刪除。臨時節點不允許擁有子節點。

• **永久節點：**該節點的生命週期不依賴於會話，並且只有在客戶端顯示執行刪除操作的時候，他們才能被刪除。

  Znode 還有一個序列化的特性，如果創建的時候指定的話，該 Znode 的名字後面會自動追加一個不斷增加的序列號。序列號對於此節點的父節點來說是唯一的，這樣便會記錄每個子節點創建的先後順序。它的格式爲“%10d”(10 位數字，沒有數值的數位用 0 補充，例如“0000000001”)。

這樣便會存在四種類型的 Znode 節點，分別對應：

• PERSISTENT：永久節點

• EPHEMERAL：臨時節點

• PERSISTENT_SEQUENTIAL：永久節點、序列化

• EPHEMERAL_SEQUENTIAL：臨時節點、序列化

ZooKeeper中的時間

ZooKeeper有多種記錄時間的形式，其中包含以下幾個主要屬性：

1. Zxid
   致使ZooKeeper節點狀態改變的每一個操作都將使節點接收到一個zxid格式的時間戳，並且這個時間戳全局有序。也就是說，也就是說，每個對節點的改變都將產生一個唯一的zxid。如果zxid1的值小於zxid2的值，那麼zxid1所對應的事件發生在zxid2所對應的事件之前。實際上，ZooKeeper的每個節點維護者三個zxid值，爲別爲：cZxid、mZxid、pZxid。
2. cZxid： 是節點的創建時間所對應的Zxid格式時間戳。
3. **mZxid：**是節點的修改時間所對應的Zxid格式時間戳。
   實現中zxid是一個64爲的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個 新的epoch。低32位是個遞增計數。