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服務器被提出的事務。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章