zookeepr--概覽

zk 一個分佈式應用協調服務

zk是一個分佈式，開源的，分佈式協調服務，他提供了一組簡單的原生接口，分佈式應用能夠基於它實現，高水準的同步，集羣，配置管理和命名服務。它基於開發，使用簡單的原則而設計。使用相似於文件系統目錄樹結構的數據模型。它基於java實現，能夠爲c和java應用服務。

協調是個臭名昭著的活兒。很容易產生資源競爭和死鎖的問題。zk的實現動機就是緩解分佈式應用在解決彼此斜體問題而產生的抓狂行爲。

zk的設計目標

zk 是個簡單的玩意兒。zk經過分佈式的處理流程來協調應用彼此，它是使用的是一種相似文件系統的分層名字空間。這些名字空間裏，包含了數據的註冊者，用zk的叫法，稱之爲znodes.它相似於文件和目錄。不像傳統的文件系統，是用來存儲的，zk的數據都在內存中，因此意味着，zk的高吞吐量和底延時。zk 實現了一個優質的，高新能，高可用，嚴格訪問順序的服務。從zk的表現來看，它徹底可使用，大型，分佈式系統。在可用上，也使它不會碰到單點故障的問題，嚴格的順序性，也意味着能夠在客戶單實現很是複雜的同步操做。

zk 是可複製的。像它協調的應用同樣，zk自身也複製到一系列主機上。他們是一個總體。如圖 zk server

全部組成zk server的 severs 必須彼此能感知對方。他們在內存裏維護一個全部機器的狀態圖，在磁盤裏保存有實務日誌和快照。只要大多數服務器可用。zk服務就可用。

客戶端鏈接到單一的服務器，經過tcp協議，發送請求，得到反饋，得到監聽事件，發送心跳包。若是鏈接的服務器掛掉，客戶端會鏈接其餘的服務機器。

zk 是順序的。zk的每次更新都會用一個數字作標籤，這個數字，表明了所有的zk事務順序，接下來的操做用這個順序來實現高水平的抽象，好比同步操做。

zk 是快速的。zk 在讀爲主的操做中，顯得特別的快。zk 運行在上千臺機器上，當讀操做爲主的請求中，表現會更好。讀寫比爲10:1。

數據模型和命名層次

zk 提供的命名空間像一個標準的文件系統。一個名字，就是它的路徑以（/）分隔的組合，在zk中每一個節點，都已路徑來惟一標識。zk的層次命名結構如圖

Nodes 和短命的nodes

不像傳統的文件系統，在zk裏每一個node和它的孩子node，都有數據和他們關聯。他們像個這樣一個文件系統，即每一個文件也是目錄。（zk節點裏存儲的數據，包括狀態信息，配置，本地信息等，因此數據量都不大一般只有幾字節或者幾千字節），爲了說清楚zk node.咱們把它稱做znode，znode 維護這一個數據結構，包括狀態更改的版本號，acl 更改的信息和時間戳去用和套東西區驗證和協調的更新。若是以個node的數據發生變化，它的版本號也會變化。好比一個客戶端讀取一個node數據，也會獲得它的版本號。存儲在node裏的數據讀寫都是原子的。讀會讀全部關聯的數據，寫也會替換全部的數據，不會半途而廢。每一個節點都有個訪問控制列表（acl）,嚴格限制誰能幹什麼！

zk裏還有個短命node的概念。這些node和建立這個節點的session生命同樣長。當這個session關閉時，這個node也就自動刪除了。短命node在你開發實現 【tbd】是很重要。

有條件的更新和監控

 zk 支持監控的概念，客戶端能夠對一個節點進行監控，當這個節點發生變化時，監控被觸發同時被刪除，當監控被觸發，客戶端收到一個數據更改的數據包。還有當客戶端和服務端鏈接斷開，客戶端也會收到一個通知。這個在【tbd】中頗有用。

保證

zk 簡單快速，就像他的開始的目標同樣，是構造複雜系統的基礎，好比，同步系統。實際上它有一下保證:

時序一致性：更新操做會以客戶端發送的順序被執行。

原子性：更新要麼失敗，要麼成功沒有部分紅功的狀態。

狀態圖統一：一個客戶端不管它鏈接到哪一個機器，全部機器圖譜一致。

可靠性：一個更新被應用，就會一直有效，直到有新的數據覆蓋。

時間線：客戶端某個時間段內看到的系統狀態圖，保證是最新的。

更多這些方面的應用，能夠參看【tbd】

簡單的api

zk設計之初就是提供簡單的程序接口，因此，它僅僅支持一下操做：

create :在節點樹上，建立一個節點

delete:刪除一個節點

exists:檢查一個節點是否存在

get data:從一個節點獲取數據

set data：向一個節點寫數據

get children:獲取一個節點的孩子節點

sync:等待數據傳播同步

關於這方面的更深的技術討論，和在構建高水平應用方面的實踐，能夠參考【tbd】

技術實現

下面是zk 服務組件圖，處理請求處理器外，每一個zk組件都有複製的多份。

每一個機器上的內存數據庫，都包含整個數據，更新日誌記錄到磁盤，寫操做被序列化到磁盤在它擴散同步到其餘內存數據庫以前。

每一個zk 主機都對外提供服務，客戶端鏈接某一個主機請求服務。讀的服務從客戶鏈接的機器自己內存裏獲取，寫服務和改變服務狀態的請求經過一個一致的協議處理。

這個一致的協議要求，全部寫請求都統一發送到一個叫leader的主機。剩下的被稱做followers的zk主機,經過leader 接收數據消息，消息層負責leaders的失敗替換和leaders和followers之間的同步。

zk使用的是原子性的消息協議，由於消息是原子性的，因此能保證本地的信息與其餘主機信息是一致沒有分歧的。當leader收到一個寫請求後，它會評估服務器狀態，決定何時寫，而後啓動寫事務，最後獲取服務請的新狀態。

應用

zk的使用接口尤爲的簡單，你能夠經過他實現，順序操做，好比同步，羣組管理等，許多分佈式應有使用它，想了解更多，關注【tbd】。

表現

zk被設計成高可用，是否是這樣呢？在yahoo的開發組的調查說明了它是的。當讀遠大於寫操做的時候，它表現的尤爲的高性能，由於寫操做要同步全部的服務器狀態。（讀遠大於寫是經典的協調服務案例），下圖是zk讀寫比率變化的測試結果圖表

這個圖表的測試數據是，3.2版本的zk 運行在雙核2Ghz Xeon處理器和兩個15k轉速的sata設備上的測試數據，一個磁盤專門作zk日誌，一個寫寫數據快照，讀寫操做都是1k大小，servers 表示zk服務，組成主機數目，接近30個其餘主機模擬客戶機，zk服務被配置成，leader不容許從客戶端鏈接。另外說明下，3.2讀寫性能是3.1版本的兩倍。

測試結果也說明了zk的可靠性，下圖顯示了在各類錯誤下服務器的表現，這些錯誤包含如下幾種:

1,follower 機器的當掉和恢復。

2,另一個follower的當掉和恢復。

3,leader的當掉。

4,兩個follower同時當掉。

5,另一個leader的當掉。

可用性

這個圖裏顯示了，咱們有7個主機組成的zk服務器，在一段時間內咱們注入錯誤的系統表現。此次測試咱們和之前跑一樣的訪問飽和度，有一點們把寫的比率維持在30%，這也是咱們比較保守負載比例。

從張圖裏，能夠看出一下重要的幾點，當followers 掛掉並很快恢復是，zk能保持很高的吞吐量。更重要是，leader選舉算法能讓系統很快恢復，以保持它的高吞吐量。能夠看到zk花了不到200ms選舉新的leader.第三點，當follower恢復處理能力是，zk的吞吐量又開始維持在高水平。

zookeepr 項目

zk 已經成功的在多個工業系統中應用。好比在yahoo.它負責協調yahoo的失敗恢復。上千個主題訂閱高擴展的信使服務，和數據傳輸。yahoo的獲取服務，crawler,也負責它的失敗恢復協調。做爲yahoo的一員，廣告也是經過zk實現高可用性。

zk 社區歡迎所用的用戶和開發者討論和貢獻他們的技能。參看 zookeeper.apahce.org