先一句話概括下zookeeper：zookeeper可謂是目前使用最廣泛的分布式組件了。其功能和職責(zé)單一，但卻非常重要。

[[208846]]

zookeeper到底是什么？（技術(shù)文）

1）zookeeper實際上是yahoo開發(fā)的，用于分布式中一致性處理的框架。

2）背景介紹：最初其作為研發(fā)Hadoop時的副產(chǎn)品。由于分布式系統(tǒng)中一致性處理較為困難，其他的分布式系統(tǒng)沒有必要 費勁重復(fù)造輪子，故隨后的分布式系統(tǒng)中大量應(yīng)用了zookeeper。故隨后的大部分分布式系統(tǒng)中大量應(yīng)用了zookeeper，以至于zookeeper成為了各種分布式系統(tǒng)的基礎(chǔ)組件，其地位之重要，可想而知。（類比下之前學(xué)習(xí)過的netty，netty是對 socket 網(wǎng)絡(luò)編程的優(yōu)秀包裝，是一個通訊組件框架。不了解netty的可以先收藏本文，再花五分鐘學(xué)習(xí)下這么說吧,Netty很簡單，其實就是個Jar包，是作為通訊組件用的）

3 ) 具體應(yīng)用場景：著名的hadoop、kafka、dubbo 都是基于zookeeper而構(gòu)建。

4）好處：保證在分布式環(huán)境下數(shù)據(jù)的最終一致性，這個就是zookeeper能解決的問題。

5）上面提到了很多次一致性，那么究竟什么是一致性，給大家補充下這個概念：

所謂的一致性，實際上就是圍繞著“看見”來的。誰能看見？能否看見？什么時候看見？舉個例子：淘寶后臺賣家，在后臺上架一件大促的商品，通過服務(wù)器A提交到主數(shù)據(jù)庫，假設(shè)剛提交后立馬就有用戶去通過應(yīng)用服務(wù)器B去從數(shù)據(jù)庫查詢該商品，就會出現(xiàn)一個現(xiàn)象，賣家已經(jīng)更新成功了，然而買家卻看不到；而經(jīng)過一段時間后，主數(shù)據(jù)庫的數(shù)據(jù)同步到了從數(shù)據(jù)庫，買家才能查到。（真技術(shù)文）

假設(shè)賣家更新成功之后買家立馬就能看到賣家的更新，則稱為強一致性；

如果賣家更新成功后買家不能看到賣家更新的內(nèi)容，則稱為弱一致性；

而賣家更新成功后，買家經(jīng)過一段時間最終能看到賣家的更新，則稱為最終一致性。

6）再補充一些常見的解決一致性問題的方式：

1. 查詢重試補償。對于分布式應(yīng)用中不確定的情況，先使用查詢接口查詢到當(dāng)前狀態(tài)，如果當(dāng)前狀態(tài)不一致則采用補償接口對狀態(tài)進行重試推進，或者回滾接口對業(yè)務(wù)做回滾。典型的場景如銀行跟支付寶之間的交互。支付寶發(fā)送一個轉(zhuǎn)賬請求到銀行，如一直未收到響應(yīng)，則可以通過銀行的查詢接口查詢該筆交易的狀態(tài)，如該筆交易對方未收到，則采取補償?shù)哪Ｊ竭M行推送。

2. 定時任務(wù)推送。對于上面的情況，有可能一次推送搞不定，于是需要2次，3次推送。不要懷疑，支付寶內(nèi)最初掉單率很高，全靠后續(xù)不斷的定時任務(wù)推送增加成功率。

3. TCC。try-confirm-cancel。實際上是兩階段協(xié)議，第二階段的可以實現(xiàn)提交操作或是逆操作。

7）zookeeper到底能做什么？前面提到hadoop、kafka、dubbo 都是基于zookeeper而構(gòu)建，這里，我就以dubbo來具體闡述zookeeper。（真真技術(shù)文）

作為業(yè)界知名的分布式SOA框架，dubbo的主要的服務(wù)注冊發(fā)現(xiàn)功能便是由zookeeper來提供的。

對于一個服務(wù)框架，注冊中心是其核心中的核心，雖然暫時掛掉并不會導(dǎo)致整個服務(wù)出問題，但是一旦掛掉，整體風(fēng)險就很高?？紤]一般情況，注冊中心就是單臺機器的時候，其實現(xiàn)很容易，所有機器起來都去注冊服務(wù)給它，并且所有調(diào)用方都跟它保持長連接，一旦服務(wù)有變，即通過長連接來通知到調(diào)用方。但是當(dāng)服務(wù)集群規(guī)模擴大時，這事情就不簡單了，單機保持連接數(shù)有限，而且容易故障。

作為一個穩(wěn)定的服務(wù)化框架，dubbo可以選擇并推薦zookeeper作為注冊中心。其底層將zookeeper常用的客戶端zkclient和curator封裝成為ZookeeperClient。

1. 當(dāng)服務(wù)提供者服務(wù)啟動時，向zookeeper注冊一個節(jié)點；

2. 服務(wù)消費者則訂閱其父節(jié)點的變化，諸如啟動停止都能夠通過節(jié)點創(chuàng)建刪除得知，異常情況比如被調(diào)用方掉線也可以通過臨時節(jié)點session 斷開自動刪除得知；

3. 服務(wù)消費方同時也會將自己訂閱的服務(wù)以節(jié)點創(chuàng)建的方式放到zookeeper；

4. 于是可以得到映射關(guān)系，諸如誰提供了服務(wù)，誰訂閱了誰提供的服務(wù)，基于這層關(guān)系再做監(jiān)控，就能輕易得知整個系統(tǒng)情況。

zookeeper的基本數(shù)據(jù)模型（技術(shù)好文）：

一句話，類似Linux文件系統(tǒng)的節(jié)點模型

其節(jié)點有如下有趣而又重要的特性：

1. 同一時刻多臺機器創(chuàng)建同一個節(jié)點，只有一個會爭搶成功。利用這個特性可以做分布式鎖。

2. 臨時節(jié)點的生命周期與會話一致，會話關(guān)閉則臨時節(jié)點刪除。這個特性經(jīng)常用來做心跳，動態(tài)監(jiān)控，負(fù)載等動作。

3. 順序節(jié)點保證節(jié)點名全局***。這個特性可以用來生成分布式環(huán)境下的全局自增長id。

通過zookeeper提供的原語服務(wù)，可以對zookeeper能做的事情有個精確和直觀的認(rèn)識。

zookeeper提供的原語服務(wù)：

1. 創(chuàng)建節(jié)點

2. 刪除節(jié)點

3. 更新節(jié)點

4. 獲取節(jié)點信息

5. 權(quán)限控制

6. 事件監(jiān)聽

實際上，就是對節(jié)點的增刪查改加上權(quán)限控制與事件監(jiān)聽，但是通過對這些原語的組合以及不同場景的使用，可以實現(xiàn)很多用法。

1. 數(shù)據(jù)發(fā)布訂閱。即注冊中心，見上面dubbo用法。主要通過對節(jié)點管理做到發(fā)布以及事件監(jiān)聽做到訂閱。

2. 負(fù)載均衡。見上面kafka用法。

3. 命名服務(wù)。zookeeper的節(jié)點結(jié)構(gòu)天然支持命名服務(wù)，即把信息集中存儲，并以樹狀管理，方便統(tǒng)一查閱。

4. 分布式協(xié)調(diào)通知。協(xié)調(diào)通知實際上與發(fā)布訂閱類似，由于引入的第三方的zookeeper，實際上對很多種協(xié)調(diào)通知做了解耦。

5. 集群管理與master選舉。通過上面的第二點特性，可以輕易得知集群機器存活狀況，從而輕松管理集群；通過上面***點特性，可以做出master爭搶。

6. 分布式鎖。實際上就是***點特性的應(yīng)用。

7. 分布式隊列。實際上就是第三點特性的應(yīng)用。

8. 分布式的并發(fā)等待。類似于多線程的join問題，主任務(wù)的執(zhí)行依賴于其他子任務(wù)全部執(zhí)行完畢，在單機多線程里可以用join，但是分布式環(huán)境下如何實現(xiàn)呢。利用zookeeper，可以創(chuàng)建一個主任務(wù)節(jié)點，旗下子任務(wù)一旦執(zhí)行完畢，則在主任務(wù)節(jié)點下掛一個子任務(wù)節(jié)點，等節(jié)點數(shù)量足夠，則認(rèn)為主任務(wù)可以開始執(zhí)行。

可以發(fā)現(xiàn)，所有的原語就是zookeeper的基礎(chǔ)，而其他的用法總結(jié)無非是將原語放到不同場景下的歸類罷了。