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

分布式

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

什么是Zookeeper

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

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

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

Zookeeper的基本概念

集群角色：

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

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

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

會話：

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

數據節點：

節點有兩類

• 集群中的一臺機器就叫做一個節點

• 還有就是樹形數據單元中的Znode也叫一個節點，有持久節點和臨時節點
  

版本：

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

• version：當前數據節點數據內容的版本號

• cversion：當前數據節點子節點的版本號

• aversion：當前數據節點ACL變更版本號

可以利用這個版本實現分布式的鎖服務

悲觀鎖：悲觀并發鎖，也叫做排他鎖，避免不同事務對對同一數據并發更新操作數據不一致

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

watcher：

ZK允許用戶在節點上注冊watcher，當數據發生變化時，ZK會把這個變化通知發送給客戶端。

ACL權限控制：

可以對節點設置權限控制

• CREATE：創建子節點的讀權限

• READ：獲取節點數據和子節點列表的權限

• WRITE：更新節點數據的權限

• DELET：刪除子節點的權限

• ADMIN：設置節點ACL的權限

ZAB協議

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

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

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

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

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

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

消息廣播：

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

崩潰恢復：

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

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