zookeeper入門系列-概述

轉自https://blog.csdn.net/liweisnake/article/details/63251252

 

zookeeper可謂是目前使用最普遍的分佈式組件了。其功能和職責單一，但卻很是重要。

在現今這個年代，介紹zookeeper的書和文章可謂多如牛毛，本人不才，試圖經過本身的理解來介紹zookeeper，但願經過一個初學者的視角來學習zookeeper，以期讓人更加深刻和平穩的理解zookeeper。其中參考了很多教程和書，相關書目列在文末，也感謝這些做者。

學習新的框架，先讓咱們搞清楚他是什麼，這是它的內涵，而後再介紹它能作什麼，這是它的外延，內涵和外延共同來定義框架自己，會對框架有較爲深入的理解，在應用層面上知道如何用。其次再搞清楚zookeeper相關的理論基礎，其目的是知道zookeeper是如何被髮明的，是否可以借鑑以便從此本身可以用到其餘地方。最後搞清楚zookeeper中一些設計的原理和細節，目的也是搞清前因後果，學會「術」從而應用到別的地方。固然了，加深的理解一樣可以幫助認識zookeeper自己，在使用時才知道爲何這樣用。

首先，

zookeeper究竟是什麼？

zookeeper其實是yahoo開發的，用於分佈式中一致性處理的框架。最初其做爲研發hadoop時的副產品。因爲分佈式系統中一致性處理較爲困難，其餘的分佈式系統沒有必要 費勁重複造輪子，故隨後的分佈式系統中大量應用了zookeeper，以致於zookeeper成爲了各類分佈式系統的基礎組件，其地位之重要，可想而知。著名的hadoop，kafka，dubbo 都是基於zookeeper而構建。

要想理解zookeeper究竟是作啥的，那首先得理解清楚，什麼是一致性。

所謂的一致性，實際上就是圍繞着「看見」來的。誰能看見？可否看見？何時看見？舉個例子：淘寶後臺賣家，在後臺上架一件大促的商品，經過服務器A提交到主數據庫，假設剛提交後立馬就有用戶去經過應用服務器B去從數據庫查詢該商品，就會出現一個現象，賣家已經更新成功了，然而買家卻看不到；而通過一段時間後，主數據庫的數據同步到了從數據庫，買家就能查到了。

假設賣家更新成功以後買家立馬就能看到賣家的更新，則稱爲強一致性；

若是賣家更新成功後買家不能看到賣家更新的內容，則稱爲弱一致性；

而賣家更新成功後，買家通過一段時間最終能看到賣家的更新，則稱爲最終一致性。

更多的一致性例子能夠參考文獻2，裏面列舉了10種一致性的例子，若是要給一致性下個定義，能夠是分佈式系統中狀態或數據保持同步和一致。特別須要注意一致性跟事務的區別，能夠記得學習數據庫時特別強調ACID，故而知足ACID的數據庫可以作事務，其中C便是一致性，所以，事務是一致性的一種特例，比起一致性更難達成。

如何保證在分佈式環境下數據的最終一致，這個就是zookeeper須要解決的問題。對於這些問題，有哪些挑戰，zookeeper又是如何解決這些挑戰的，下一篇文章將會主要涉及這個主題。

一些常見的解決一致性問題的方式：

1. 查詢重試補償。對於分佈式應用中不肯定的狀況，先使用查詢接口查詢到當前狀態，若是當前狀態不一致則採用補償接口對狀態進行重試推動，或者回滾接口對業務作回滾。典型的場景如銀行跟支付寶之間的交互。支付寶發送一個轉帳請求到銀行，如一直未收到響應，則能夠經過銀行的查詢接口查詢該筆交易的狀態，如該筆交易對方未收到，則採起補償的模式進行推送。

2. 定時任務推送。對於上面的狀況，有可能一次推送搞不定，因而須要2次，3次推送。不要懷疑，支付寶內最初掉單率很高，全靠後續不斷的定時任務推送增長成功率。

3. TCC。try-confirm-cancel。其實是兩階段協議，第二階段的能夠實現提交操做或是逆操做。

 

zookeeper到底能作什麼？

在業界的實際應用是什麼？瞭解這些應用，會對zookeeper可以作的事有更直觀的認識。

hadoop：

鼻祖級應用，ResourceManager在整個hadoop中算是單點，爲了實現其高可用，分爲主備ResourceManager，zookeeper在其中管理整個ResourceManager。

能夠想象，主備ResourceManager最初是主RM提供服務，若是一切安好，則zookeeper無用武之地。然而，總歸會出現主RM提供不了服務的狀況。因而會出現主備切換的狀況，而zookeeper正是爲主備切換保駕護航。

先來推理一下，主備切換會出現什麼問題。傳統的主備切換，可讓主備之間維持心跳鏈接，一旦備機發現主機心跳檢測不到了，則本身切換爲主機，原來的主機等待救援。這種方式有兩個問題，一是因爲網絡抖動，負載過大等問題，備機檢測不到心跳並不能說明主機必定掛了，有可能必定時間後主機或網絡恢復，這時候主機並不知道備機已經切換爲主機，2臺主機互相爭用，可能形成腦裂；二是若是一些數據集中在主機上面，則備機切換時因爲同步延時勢必會損失掉一部分的數據。

如何解決這些問題？早期的方式提供了很多解決方案，好比備機一旦切換爲主機，則經過電源控制直接切斷主機電源，簡單粗暴，可是此刻備機已是單點，若是主機是由於量撐不住而掛，那備機有可能會重蹈覆轍，最終致使整個服務不可用。

zookeeper又是如何解決這個問題的呢？

1. zookeeper做爲第三方集羣參與到主備節點中去，當主備啓動時會在zookeeper上競爭建立一個臨時鎖節點，爭用成功者則充當主機，其他備機

2. 全部備機會監聽該臨時鎖節點，一旦主機與zookeeper間session失效，則臨時節點被刪除

3. 一旦臨時節點被刪除，備機開始從新申請建立臨時鎖節點，從新爭用爲主機;

4. 用zookeeper如何解決腦裂？實際上主機爭用到節點後經過對根節點作一個ACL權限控制，則其餘搶佔的機器因爲沒法更新臨時鎖節點，只有放棄成爲備機。

zookeeper使用了很是簡單又現成的方式來解決的這個問題，比起其餘方案方便很多，這也是爲啥zookeeper流行的緣由。說白了，就是把複雜操做封裝化精簡化

 

dubbo：

做爲業界知名的分佈式soa框架，dubbo的主要的服務註冊發現功能即是由zookeeper來提供的。

對於一個服務框架，註冊中心是其核心中的核心，雖然暫時掛掉並不會致使整個服務出問題，可是一旦掛掉，總體風險就很高。考慮通常狀況，註冊中心就是單臺機器的時候，其實現很容易，全部機器起來都去註冊服務給它，而且全部調用方都跟它保持長鏈接，一旦服務有變，即經過長鏈接來通知到調用方。可是當服務集羣規模擴大時，這事情就不簡單了，單機保持鏈接數有限，並且容易故障。

做爲一個穩定的服務化框架，dubbo能夠選擇並推薦zookeeper做爲註冊中心。其底層將zookeeper經常使用的客戶端zkclient和curator封裝成爲ZookeeperClient。

1. 當服務提供者服務啓動時，向zookeeper註冊一個節點

2. 服務消費者則訂閱其父節點的變化，諸如啓動中止都可以經過節點建立刪除得知，異常狀況好比被調用方掉線也能夠經過臨時節點session 斷開自動刪除得知

3. 服務消費方同時也會將本身訂閱的服務以節點建立的方式放到zookeeper

4. 因而能夠獲得映射關係，諸如誰提供了服務，誰訂閱了誰提供的服務，基於這層關係再作監控，就能輕易得知整個系統狀況。

 

zookeeper的基本數據模型

一句話，相似linux文件系統的節點模型

其節點有以下有趣而又重要的特性：

1. 同一時刻多臺機器建立同一個節點，只有一個會爭搶成功。利用這個特性能夠作分佈式鎖。

2. 臨時節點的生命週期與會話一致，會話關閉則臨時節點刪除。這個特性常常用來作心跳，動態監控，負載等動做

3. 順序節點保證節點名全局惟一。這個特性能夠用來生成分佈式環境下的全局自增加id

 

經過zookeeper提供的原語服務，能夠對zookeeper能作的事情有個精確和直觀的認識

zookeeper提供的原語服務

1. 建立節點。

2. 刪除節點

3. 更新節點

4. 獲取節點信息

5. 權限控制

6. 事件監聽

實際上，就是對節點的增刪查改加上權限控制與事件監聽，可是經過對這些原語的組合以及不一樣場景的使用，能夠實現不少用法。參考文獻5

1. 數據發佈訂閱。即註冊中心，見上面dubbo用法。主要經過對節點管理作到發佈以及事件監聽作到訂閱

2. 負載均衡。見上面kafka用法

3. 命名服務。zookeeper的節點結構自然支持命名服務，即把信息集中存儲，並以樹狀管理，方便統一查閱

4. 分佈式協調通知。協調通知實際上與發佈訂閱相似，因爲引入的第三方的zookeeper，實際上對不少種協調通知作了解耦，好比參考文獻4中提到的消息推送，心跳檢測等

5. 集羣管理與master選舉。經過上面的第二點特性，能夠輕易得知集羣機器存活情況，從而輕鬆管理集羣；經過上面第一點特性，能夠作出master爭搶。

6. 分佈式鎖。實際上就是第一點特性的應用。

7. 分佈式隊列。實際上就是第三點特性的應用。

8. 分佈式的併發等待。相似於多線程的join問題，主任務的執行依賴於其餘子任務所有執行完畢，在單機多線程裏能夠用join，可是分佈式環境下如何實現呢。利用zookeeper，能夠建立一個主任務節點，旗下子任務一旦執行完畢，則在主任務節點下掛一個子任務節點，等節點數量足夠，則認爲主任務能夠開始執行。

能夠發現，全部的原語就是zookeeper的基礎，而其餘的用法總結無非是將原語放到不一樣場景下的歸類罷了。

 

相信到這裏你對zookeeper應該有個初步的瞭解和大體的印象了。

本系列文章分爲：

zookeeper入門系列-概述

zookeeper入門系列-理論基礎-分佈式事務

zookeeper入門系列-理論基礎-paxos協議

zookeeper入門系列-理論基礎-zab協議

zookeeper入門系列-理論基礎-raft協議

zookeeper入門系列-設計細節

 

參考文獻：

保證分佈式系統數據一致性的6種方案 http://weibo.com/ttarticle/p/show?id=2309403965965003062676

解決分佈式系統的一致性問題，咱們須要瞭解哪些理論？ http://mp.weixin.qq.com/s/hGnpHfn7a7yxjPBP78i4bg

分佈式系統的事務處理  http://coolshell.cn/articles/10910.html

ZooKeeper典型應用場景一覽 http://jm.taobao.org/2011/10/08/1232/

zookeeper中的基本概念 http://www.hollischuang.com/archives/1280

zookeeper入門使用 http://www.importnew.com/23025.html