Zookeeper Introduction

問題思考

對於 hadoop 生態系統來講,有幾個問題須要經過分佈式協調服務來解決:

1. 高可用性的主節點選舉。對於集羣各服務,如 HDFS、YARN、HBASE、SPARK 等如何保證同一時間只有一個主節點對外提供服務。
2. YARN 中 ResourceManager 失敗後如何恢復執行任務的必要信息:Application 狀態信息,Application 對應的 ApplicationAttempt 信息,以及一些相關的安全令牌信息。
3. Hive 數據倉庫中 SQL 查詢的併發鎖問題。

所以,誕生了一個針對分佈式系統的可靠協調系統,即 Zookeeper。

 

簡介

Zookeeper 是一個針對大型分佈式系統的可靠協調系統,提供的功能包括:配置維護、名字服務、分佈式同步、組服務等。

ZooKeeper 的目標就是封裝好複雜易出錯的關鍵服務,將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。相關例子包括:分佈式隊列、分佈式鎖和一些節點的「領導者選舉」。

 

數據結構

Zookeeper 維護一種樹狀層次結構,樹中的節點被稱爲 znode,znode 用來存儲數據。一種是短暫 znode,一種是持久 znode。

短暫 node 是根據會話鏈接存在,會話消失或超時,則消失。

持久 znode 只有客戶端明確要刪除該持久 znode 時才被刪除。

Zookeeper 使用這樣一個相似文件系統的樹結構,數據能夠掛在某個節點上,能夠對這個節點進行刪改。因爲 zookeeper 集羣做爲一個總體對提供服務,因此對於任何節點上的修改都是對集羣總體進行修改,也能夠說是對集羣內全部的節點同時進行修改。

Znode 的大小存在限制,默認是 1MB。能夠經過參數調整,可是 Zookeeper 設計的初衷並非存儲大數據量,而是對關鍵數據對外提供高效穩定的服務。

合理的使用 znode,不只提升 Zookeeper 服務的性能,也能保證 Zookeeper 服務的穩定性。

選舉

Zookeeper 服務有兩種運行模式:Standalone 模式和 Replicated 模式。當只有一個服務器來做爲 Zookeeper 服務器時,是 Standalone 模式,能夠用於開發測試環境。

生產環境下,Zookeeper 一般使用 Replicated 模式,來保證高可用性和可恢復性,Replicated模式下集羣內部只要有半數以上的服務器處於可用狀態,它就可以提供服務。

Replicated 模式下集羣內的全部機器經過一個選擇過程選出一臺稱爲」領導者(leader)」,其餘機器稱爲「跟隨者(follower)」。一旦半數以上(或指定數量)的跟隨者已經將其狀態與領導者同步,則選舉過程結束。若是 Leader 掛了,zk 集羣會從新選舉,在毫秒級別就會從新選舉出一個 Leaer。Leader 提供寫入請求,全部機器提供讀取請求,觀察者咱們這裏不談。全部的寫請求都會發送給領導者,再有領導者將更新廣播給全部的跟隨者。當半數以上的跟隨者已經將修改持久化以後,領導者纔會提交這個更新。而後客戶端會受到一個更新成功的響應。這個用來達成共識的協議被設計成具備原子性,所以每一個修改要麼成功要麼失敗。這相似於數據庫中的兩段式提交協議。

爲了保證客戶端查看 Zookeeper 各機器數據的及時性,客戶端對 znode 的數據讀取會自動調用 sync 操做。Sync 操做會強制此服務器的 znode 同步到 leader 的狀態。

一般狀況下,生產環境使用 replicated 模式,集羣一般包含奇數臺機器。通常 3 或 5臺。例如,在一個有 5 節點的集羣內部,只容許最多 2 臺機器出現故障,只要有 3 臺或者 3臺以上的機器存活,那麼集羣就能夠對外提供服務器。注意,對於 6 臺機器的集羣,也只容許最多 2 臺機器出現故障,當出現 3 臺機器故障時,集羣一樣不能對外提供服務。

設計特色

Zookeeper 的設計中有以下特色:
 

• 順序一致性

全局惟一的 ID,稱爲 zxid(」ZooKeeper Transaction ID」).ZooKeeper 要求的更新都是按照編
號並排序,決定了分佈式系統的執行順序。對某一個 znode 的更新,好比操做 a 執行先於操
做 b,那麼全部的客戶端只會出現先看到 a 再看到 b;反之不能。
 

• 原子性

一個更新做爲一個原子事務,要麼成功要麼失敗。若是失敗,任何客戶端不會看到更新的結
果。
 

• 單一系統映像

任何客戶端在鏈接到任何 zookeeper 服務器時,看到都是一樣的視圖。按順序鏈接到不一樣的
zookeeper 服務器,只會看到更新結果。好比,ClientA 前後登陸 ServerA 和 ServerB,那麼在
ClientA 在 ServerB 上看到的視圖老是比 ServerA 看到的更新。

 

• 持久性

一個更新一旦成功,結果就會永久寫入,並不能被撤銷。
 

• 及時性

任何客戶端看到的系統視圖均可能滯後的,可是滯後時間不能太長。若是一個服務器的系統
視圖太久,那還不如關閉此服務器,鏈接到一個系統視圖較新的服務器。

 

注意事項

 

• 機器列表

客戶端連接 Zookeeper 的機器列表、每一個 Zookeeper 服務器的機器列表必須保持一致。
若是客戶端包含列表少與服務端,雖然工做仍是正常的,可是損失了 Zookeeper 服務部分的高可用性。
若是客戶端的列表裏包含不一樣 Zookeeper 集羣的服務器,那麼有些工做可能將變得異常。固然同一集羣內的各個 Zookeeper 服務器的配置應該保持一致。

 

• 內存設置

你應該特別留心設置 Zookeeper 服務的 Java max heap size。
Zookeeper 中的 znode 數據都會存放在內存中,同時內存數據的快照會按期保存在磁盤上。
Zookeeper 須要足夠的內存,確保 zookeeper 不會使用 swap,確保 Zookeeper 分配的最大 heap size 不大於真正可用的內存。

 

• 日誌磁盤

Zookeeper 中影響性能最關鍵的部分在於 transaction log。Zookeeper 在作出響應以前會把事務日誌同步到存儲介質上。

一個獨立的日誌磁盤是維持優秀性能的關鍵。若是將日誌寫入一個繁忙的磁盤將致使惡劣的性能表現。