Zookeeper詳解（一）：分布式與Zookeeper

分布式

在分布式框架中，分布式應(yīng)用面臨的最大的問題就是數(shù)據(jù)一致性。那么Zookeeper就是一個比較好的解決方案。在分布式框架中起到協(xié)調(diào)作用。

什么是Zookeeper

zookeeper是高性能的分布式協(xié)作服務(wù)和分布式數(shù)據(jù)一致性解決方案，由雅虎創(chuàng)建，是Goole Chubby的開源實現(xiàn)，所以你就自然明白Zookeeper和Chubby的關(guān)系了。Chubby是一個分布式鎖服務(wù)，GFS和Big Table都是用它來解決分布式協(xié)作的一些問題，其底層一致性實現(xiàn)就是以Paxos算法為基礎(chǔ)的。

zookeeper可以保證分布式一致性特性，包括順序一致性、原子性、單一視圖（無論客戶端連接哪一個ZK服務(wù)器看到的都是一樣的數(shù)據(jù)模型）、可靠性、實時性（在一定時間內(nèi)客戶端可以讀取到最新數(shù)據(jù)狀態(tài)而不是提交后所有服務(wù)器馬上就全部更新。）

zookeeper的數(shù)據(jù)模型是一個樹形節(jié)點，服務(wù)啟動后，所有數(shù)據(jù)加載到內(nèi)存中這樣來提高服務(wù)器吞吐并減少延遲。

Zookeeper的基本概念

集群角色：

• Leader：ZK集群的核心角色，通過選舉產(chǎn)生，為客戶端提供讀寫服務(wù)，也就是處理事務(wù)請求

• Follower：集群狀態(tài)的跟隨者，參加選舉，沒有被選上就是這個角色，提供讀取服務(wù)，也就是處理非事務(wù)請求，對于收到的事務(wù)請求會轉(zhuǎn)發(fā)給Leader服務(wù)器

• Observer：觀察者角色，不參加選舉，但是提供數(shù)據(jù)讀取服務(wù)，提供讀取服務(wù)，也就是處理非事務(wù)請求，對于收到的事務(wù)請求會轉(zhuǎn)發(fā)給Leader服務(wù)器
  

會話：

客戶端和ZK的連接，客戶端與ZK連接一個TCP的長連接來維持會話，通過這個連接可以檢測心跳與服務(wù)器保存會話，也可以發(fā)送請求并接受服務(wù)器響應(yīng)，也可以接受WATCH事件。

數(shù)據(jù)節(jié)點：

節(jié)點有兩類

• 集群中的一臺機器就叫做一個節(jié)點

• 還有就是樹形數(shù)據(jù)單元中的Znode也叫一個節(jié)點，有持久節(jié)點和臨時節(jié)點
  

版本：

ZK的版本和我們常規(guī)理解的版本不太一樣，它是記錄節(jié)點數(shù)據(jù)或者節(jié)點子節(jié)點的類別或者ACL的修改次數(shù)。有一個叫做STAT的數(shù)據(jù)結(jié)構(gòu)這里面就記錄了下面的版本信息。

• version：當前數(shù)據(jù)節(jié)點數(shù)據(jù)內(nèi)容的版本號

• cversion：當前數(shù)據(jù)節(jié)點子節(jié)點的版本號

• aversion：當前數(shù)據(jù)節(jié)點ACL變更版本號

可以利用這個版本實現(xiàn)分布式的鎖服務(wù)

悲觀鎖：悲觀并發(fā)鎖，也叫做排他鎖，避免不同事務(wù)對對同一數(shù)據(jù)并發(fā)更新操作數(shù)據(jù)不一致

樂觀鎖：認為不同事務(wù)訪問相同數(shù)據(jù)很少出現(xiàn)相互干擾的情況，所以不需要做嚴格的并發(fā)控制，但是它也是鎖。比如對每個數(shù)據(jù)庫表增加一個版本號，修改數(shù)據(jù)之前讀取數(shù)據(jù)自然也會把版本號讀取出來，更新的時候就使用這個版本號，如果版本號為1，更新的時候就使用1，如果更新失敗則表示其他事物已經(jīng)對數(shù)據(jù)做了修改，這時候就需要其他后續(xù)處理。

watcher：

ZK允許用戶在節(jié)點上注冊watcher，當數(shù)據(jù)發(fā)生變化時，ZK會把這個變化通知發(fā)送給客戶端。

ACL權(quán)限控制：

可以對節(jié)點設(shè)置權(quán)限控制

• CREATE：創(chuàng)建子節(jié)點的讀權(quán)限

• READ：獲取節(jié)點數(shù)據(jù)和子節(jié)點列表的權(quán)限

• WRITE：更新節(jié)點數(shù)據(jù)的權(quán)限

• DELET：刪除子節(jié)點的權(quán)限

• ADMIN：設(shè)置節(jié)點ACL的權(quán)限

ZAB協(xié)議

zookeeper是基于PAXOS算法，但是它自己也有一套核心算法就是ZAB，原子消息廣播協(xié)議。這個協(xié)議是為Zookeeper單獨設(shè)計的，是崩潰可恢復的的原子消息廣播算法。

Zookeeper使用一個單一的主進程來接收并處理客戶端所有請求，將服務(wù)器的狀態(tài)以事務(wù)的形式廣播到所有副本進程中。

ZAB協(xié)議包括兩種基本模式，崩潰恢復和消息廣播。

集群啟動過程中，Leader斷開、崩潰退出或重啟等異常情況，ZAB會進入恢復模式并選舉新的Leader，當產(chǎn)生了新的Leader后并集群中過半腐惡去完成了與Leader的狀態(tài)同步（數(shù)據(jù)同步），那么ZAB協(xié)議退出恢復模式，進入消息廣播模式。

如果在當前集群中新加入一臺服務(wù)器，那么這臺新服務(wù)器會自動進入恢復模式，待完成與集群Leader的同步之后就進入消息廣播模式。

Leader服務(wù)器收到客戶端的事務(wù)請求會生成一個事務(wù)提案并發(fā)起廣播；如果非Leader服務(wù)器收到客戶端請求后它會把請求轉(zhuǎn)發(fā)給Leader服務(wù)器。

消息廣播：

在廣播事務(wù)之前Leader服務(wù)器會先給這個事務(wù)分配一個全局單調(diào)遞增的唯一ID，也就是事務(wù)ID（ZXID），每一個事務(wù)必須按照ZXID的先后順序進行處理。而且Leader服務(wù)器會為每一個Follower分配一個單獨的隊列，然后將需要廣播的事務(wù)放到隊列中。每個Follower服務(wù)器再接收到這個事務(wù)之后，都會將其以事務(wù)日志的形式寫入到本地磁盤中，成功寫入后反饋給Leader一個ACK，當Leader收到半數(shù)ACK響應(yīng)之后，就會廣播一個Commit消息給所有Follower，通知它們進行提交，同時Leader也會完成自身的提交。

崩潰恢復：

其目的就是保證盡快選舉出一個新的Leader并通知給其他Follower，同時保證整個集群中的數(shù)據(jù)狀態(tài)是一致的。

ZAB協(xié)議丟棄那些只有在Leader服務(wù)器被提出的事務(wù)。