zookeeper入門系列：概述

（點選上方公眾號，可快速關註）

來源：笨狐狸，

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又是如何解決這個問題的呢？

zookeeper作為第三方叢集參與到主備節點中去，當主備啟動時會在zookeeper上競爭建立一個臨時鎖節點，爭用成功者則充當主機，其餘備機；

所有備機會監聽該臨時鎖節點，一旦主機與zookeeper間session失效，則臨時節點被刪除；

一旦臨時節點被刪除，備機開始重新申請建立臨時鎖節點，重新爭用為主機；

用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

• 分散式系統的事務處理

  分散式系統的事務處理

• ZooKeeper典型應用場景一覽

  http://jm.taobao.org/2011/10/08/1232/

• zookeeper中的基本概念

  Zookeeper介紹（四）——Zookeeper中的基本概念

• zookeeper入門使用

  http://www.importnew.com/23025.html

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

看完本文有收穫？請轉發分享給更多人

關註「ImportNew」，提升Java技能