分布式

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

什么是Zookeeper

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

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

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

Zookeeper的基本概念

集群角色：

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

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

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

會話：

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

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

節(jié)點有兩類

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

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

版本：

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

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

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

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

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

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

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

watcher：

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

ACL權限控制：

可以對節(jié)點設置權限控制

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

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

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

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

• ADMIN：設置節(jié)點ACL的權限

ZAB協(xié)議

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

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

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

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

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

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

消息廣播：

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

崩潰恢復：

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

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

轉載于:https://blog.51cto.com/littledevil/1983260

總結

以上是生活随笔為你收集整理的Zookeeper详解（一）：分布式与Zookeeper的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。