HADOOP學習筆記總結三：zookeeper
在學習Hbase時，官方文件說hbase依賴於zookeeper來管理與跟蹤其分散式資料的狀態，hregionserver與hmaster都需要向它註冊。那什麼是zookeeper呢？今天學習一下：
1、zookeeper是什麼
ZooKeeper是一種分散式協調服務，用於管理大型主機。在分散式環境中協調和管理服務是一個複雜的過程。ZooKeeper通過其簡單的架構和API解決了這個問題。ZooKeeper允許開發人員專注於核心應用程式邏輯，而不必擔心應用程式的分散式特性。
ZooKeeper是由叢集（節點組）使用的一種服務，用於在自身之間協調，並通過穩健的同步技術維護共享資料。ZooKeeper本身是一個分散式應用程式，為寫入分散式應用程式提供服務。
那什麼是分散式應用呢？
分散式應用可以在給定時間（同時）在網路中的多個系統上執行，通過協調它們以快速有效的方式完成特定任務。在單機上可能需要花幾個小時的計算的任務，分散式通過使用所有系統的來計算，就可以幾分鐘就完成了。
分散式應用正在執行的一組系統稱為叢集，而在叢集中執行的每臺機器被稱為節點。分散式應當有兩部分：server 與client
server伺服器應用程式實際上是分散式的，並具有通用介面，以便客戶端可以連線到叢集中的任何伺服器並獲得相同的結果。 客戶端應用程式是與分散式應用進行互動的工具。
2、zookeeper提供哪些服務
-
命名服務 - 按名稱標識叢集中的節點。它類似於DNS，但僅對於節點。
-
配置管理 - 加入節點的最近的和最新的系統配置資訊。
-
叢集管理 - 實時地在叢集和節點狀態中加入/離開節點。
-
選舉演算法 - 選舉一個節點作為協調目的的leader。
-
鎖定和同步服務 - 在修改資料的同時鎖定資料。此機制可幫助你在連線其他分散式應用程式（如Apache HBase）時進行自動故障恢復。
-
高度可靠的資料登錄檔 - 即使在一個或幾個節點關閉時也可以獲得資料。
3、ZooKeeper的架構
| 部分 | 描述 |
|---|---|
| Client（客戶端） |
客戶端，我們的分散式應用叢集中的一個節點，從伺服器訪問資訊。對於特定的時間間隔，每個客戶端向伺服器傳送訊息以使伺服器知道客戶端是活躍的。 類似地，當客戶端連線時，伺服器傳送確認碼。如果連線的伺服器沒有響應，客戶端會自動將訊息重定向到另一個伺服器。 |
| Server（伺服器） | 伺服器，我們的ZooKeeper總體中的一個節點，為客戶端提供所有的服務。向客戶端傳送確認碼以告知伺服器是活躍的。 |
| Ensemble | ZooKeeper伺服器組。形成ensemble所需的最小節點數為3。 |
| Leader | 伺服器節點，如果任何連線的節點失敗，則執行自動恢復。Leader在服務啟動時被選舉。 |
| Follower | 跟隨leader指令的伺服器節點。 |
層次名稱空間
下圖描述了用於記憶體表示的ZooKeeper檔案系統的樹結構。ZooKeeper節點稱為 znode 。每個znode由一個名稱標識，並用路徑(/)序列分隔。
-
在圖中，首先有一個由“/”分隔的znode。在根目錄下，你有兩個邏輯名稱空間 config 和 workers 。
-
config 名稱空間用於集中式配置管理，workers 名稱空間用於命名。
-
在 config 名稱空間下，每個znode最多可儲存1MB的資料。這與UNIX檔案系統相類似，除了父znode也可以儲存資料。這種結構的主要目的是儲存同步資料並描述znode的元資料。此結構稱為 ZooKeeper資料模型。
ZooKeeper資料模型中的每個znode都維護著一個 stat 結構。一個stat僅提供一個znode的元資料。它由版本號，操作控制列表(ACL)，時間戳和資料長度組成。
-
版本號 - 每個znode都有版本號，這意味著每當與znode相關聯的資料發生變化時，其對應的版本號也會增加。當多個zookeeper客戶端嘗試在同一znode上執行操作時，版本號的使用就很重要。
-
操作控制列表(ACL) - ACL基本上是訪問znode的認證機制。它管理所有znode讀取和寫入操作。
-
時間戳 - 時間戳表示建立和修改znode所經過的時間。它通常以毫秒為單位。ZooKeeper從“事務ID"(zxid)標識znode的每個更改。Zxid 是唯一的，並且為每個事務保留時間，以便你可以輕鬆地確定從一個請求到另一個請求所經過的時間。
-
資料長度 - 儲存在znode中的資料總量是資料長度。你最多可以儲存1MB的資料。
Znode的型別
Znode被分為持久（persistent）節點，順序（sequential）節點和臨時（ephemeral）節點。
-
持久節點 - 即使在建立該特定znode的客戶端斷開連線後，持久節點仍然存在。預設情況下，除非另有說明，否則所有znode都是持久的。
-
臨時節點 - 客戶端活躍時，臨時節點就是有效的。當客戶端與ZooKeeper集合斷開連線時，臨時節點會自動刪除。因此，只有臨時節點不允許有子節點。如果臨時節點被刪除，則下一個合適的節點將填充其位置。臨時節點在leader選舉中起著重要作用。
-
順序節點 - 順序節點可以是持久的或臨時的。當一個新的znode被建立為一個順序節點時，ZooKeeper通過將10位的序列號附加到原始名稱來設定znode的路徑。例如，如果將具有路徑 /myapp 的znode建立為順序節點，則ZooKeeper會將路徑更改為 /myapp0000000001 ，並將下一個序列號設定為0000000002。如果兩個順序節點是同時建立的，那麼ZooKeeper不會對每個znode使用相同的數字。順序節點在鎖定和同步中起重要作用。
Sessions（會話）
會話對於ZooKeeper的操作非常重要。會話中的請求按FIFO順序執行。一旦客戶端連線到伺服器，將建立會話並向客戶端分配會話ID 。
客戶端以特定的時間間隔傳送心跳以保持會話有效。如果ZooKeeper集合在超過伺服器開啟時指定的期間（會話超時）都沒有從客戶端接收到心跳，則它會判定客戶端宕機。
會話超時通常以毫秒為單位。當會話由於任何原因結束時，在該會話期間建立的臨時節點也會被刪除。
Watches（監視）
監視是一種簡單的機制，使客戶端收到關於ZooKeeper集合中的更改的通知。客戶端可以在讀取特定znode時設定Watches。Watches會向註冊的客戶端傳送任何znode（客戶端登錄檔）更改的通知。
Znode更改是與znode相關的資料的修改或znode的子項中的更改。只觸發一次watches。如果客戶端想要再次通知，則必須通過另一個讀取操作來完成。當連線會話過期時，客戶端將與伺服器斷開連線，相關的watches也將被刪除。