學習之前,讓我們帶着幾個問題進入,Zookeeper的數據結構是什麼樣的?如何實現分佈式一致性?都有哪些應用場景呢?
zookeeper 簡介
Zookeeper 是一個開放源碼的分佈式應用程序協調服務,它包含一個簡單的原語集,分佈式應用程序可以基於它實現同步服務、配置維護和命名服務等等。
Zookeeper特性
ZooKeeper非常快速且非常簡單。但是,由於其目標是構建更復雜的服務(如同步)的基礎,因此它提供了一系列保證。這些是:
- 順序一致性 - 客戶端的更新將按發送順序應用。
- 原子性 - 更新成功或失敗。沒有部分結果。
- 單系統映像 - 無論服務器連接到哪個服務器,客戶端都將看到相同的服務視圖。
- 可靠性 - 一旦應用了更新,它將從那時起持續到客戶端覆蓋更新。
- 及時性 - 系統的客戶視圖保證在特定時間範圍內是最新的。
Zookeeper的數據模型
它很像數據結構當中的樹,也很像文件系統的目錄。
樹是由節點所組成,Zookeeper的數據存儲也同樣是基於節點,這種節點叫做Znode。
但是,不同於樹的節點,Znode的引用方式是路徑引用,類似於文件路徑:
/ 動物 / 倉鼠
/ 植物 / 荷花
這樣的層級結構,讓每一個Znode節點擁有唯一的路徑,就像命名空間一樣對不同信息作出清晰的隔離。
那麼,Znode裏又有些什麼呢?
Znode包含了數據、子節點引用、訪問權限等等,我們來看看下面這張圖:
- data:Znode存儲的數據信息。
- ACL:記錄Znode的訪問權限,即哪些人或哪些IP可以訪問本節點。
- stat:包含Znode的各種元數據,比如事務ID、版本號、時間戳、大小等等。
- child:當前節點的子節點引用,類似於二叉樹的左孩子右孩子。
這裏需要注意一點,Zookeeper是爲讀多寫少的場景所設計。Znode並不是用來存儲大規模業務數據,而是用於存儲少量的狀態和配置信息,每個節點的數據最大不能超過1MB。
Zookeeper的基本操作和事件通知
Zookeeper包含了哪些基本操作呢?
這裏列舉出比較常用的API:
create:創建節點
delete:刪除節點
exists:判斷節點是否存在
get data:獲得一個節點的數據
set data:設置一個節點的數據
get children:獲取節點下的所有子節點
這其中,exists,getData,getChildren屬於讀操作。Zookeeper客戶端在請求讀操作的時候,可以選擇是否設置Watch。
Watch是什麼意思呢?
我們可以理解成是註冊在特定Znode上的觸發器。當這個Znode發生改變,也就是調用了create,delete,setData方法的時候,將會觸發Znode上註冊的對應事件,請求Watch的客戶端會接收到異步通知。
具體交互過程如下:
1.客戶端調用getData方法,watch參數是true。服務端接到請求,返回節點數據,並且在對應的哈希表裏插入被Watch的Znode路徑,以及Watcher列表。
2.當被Watch的Znode已刪除,服務端會查找哈希表,找到該Znode對應的所有Watcher,異步通知客戶端,並且刪除哈希表中對應的Key-Value。
Zookeepr的一致性
Zookeeper身爲分佈式系統的協調服務,當然需要確保自身不掛掉。
爲了防止單機掛掉的情況,Zookeeper維護了一個集羣。
Zookeeper的集羣長成什麼樣呢?就像下圖這樣:
Zookeeper Service集羣是一主多從結構。
在更新數據時,首先更新到主節點(這裏的節點是指服務器,不是Znode),再同步到從節點。
在讀取數據時,直接讀取任意從節點。
爲了保證主從節點的數據一致性,Zookeeper採用了ZAB協議,這種協議非常類似於一致性算法Paxos和Raft。
ZAB協議
ZAB即Zookeeper Atomic Broadcast 有效的解決了Zookeeper集羣崩潰恢復,以及主從同步數據的問題。
在學習ZAB之前,我們需要首先了解ZAB協議所定義的三種節點狀態:
Looking :選舉狀態。
Following :Follower節點(從節點)所處的狀態。
Leading :Leader節點(主節點)所處狀態。
我們還需要知道最大ZXID的概念:
最大ZXID也就是節點本地的最新事務編號,包含epoch和計數兩部分。epoch是紀元的意思,相當於Raft算法選主時候的term。
每次對Zookeeper的狀態的改變都會產生一個zxid(ZooKeeper Transaction Id),zxid是全局有序的,如果zxid1小於zxid2,則zxid1在zxid2之前發生。
假如Zookeeper當前的主節點掛掉了,集羣會進行崩潰恢復。ZAB的崩潰恢復分成三個階段:
1.Leader election
選舉階段,此時集羣中的節點處於Looking狀態。它們會各自向其他節點發起投票,投票當中包含自己的服務器ID和最新事務ID(ZXID)。
接下來,節點會用自身的ZXID和從其他節點接收到的ZXID做比較,如果發現別人家的ZXID比自己大,也就是數據比自己新,那麼就重新發起投票,投票給目前已知最大的ZXID所屬節點。
每次投票後,服務器都會統計投票數量,判斷是否有某個節點得到半數以上的投票。如果存在這樣的節點,該節點將會成爲準Leader,狀態變爲Leading。其他節點的狀態變爲Following。
這就相當於,一羣武林高手經過激烈的競爭,選出了武林盟主。
2.Discovery
發現階段,用於在從節點中發現最新的ZXID和事務日誌。或許有人會問:既然Leader被選爲主節點,已經是集羣裏數據最新的了,爲什麼還要從節點中尋找最新事務呢?
這是爲了防止某些意外情況,比如因網絡原因在上一階段產生多個Leader的情況。
所以這一階段,Leader集思廣益,接收所有Follower發來各自的最新epoch值。Leader從中選出最大的epoch,基於此值加1,生成新的epoch分發給各個Follower。
各個Follower收到全新的epoch後,返回ACK給Leader,帶上各自最大的ZXID和歷史事務日誌。Leader選出最大的ZXID,並更新自身歷史日誌。
3.Synchronization
同步階段,把Leader剛纔收集得到的最新歷史事務日誌,同步給集羣中所有的Follower。只有當半數Follower同步成功,這個準Leader才能成爲正式的Leader。
自此,故障恢復正式完成。
那麼,ZAB又是如何寫入數據的?寫入數據,涉及到了ZAB協議的Broadcast階段。
什麼是Broadcast呢?
簡單來說,就是Zookeeper常規情況下更新數據的時候,由Leader廣播到所有的Follower。其過程如下:
1.客戶端發出寫入數據請求給任意Follower。
2.Follower把寫入數據請求轉發給Leader。
3.Leader採用二階段提交方式,先發送Propose廣播給Follower。
4.Follower接到Propose消息,寫入日誌成功後,返回ACK消息給Leader。
5.Leader接到半數以上ACK消息,返回成功給客戶端,並且廣播Commit請求給Follower。
Zab協議既不是強一致性,也不是弱一致性,而是處於兩者之間的單調一致性。它依靠事務ID和版本號,保證了數據的更新和讀取是有序的。
Zookeeper的應用場景
1.分佈式鎖
這是雅虎研究員設計Zookeeper的初衷。利用Zookeeper的臨時順序節點,可以輕鬆實
現分佈式鎖。
2.服務註冊和發現
利用Znode和Watcher,可以實現分佈式服務的註冊和發現。最著名的應用就是阿里的分佈式RPC框架Dubbo。
3.共享配置和狀態信息
Redis的分佈式解決方案Codis,就利用了Zookeeper來存放數據路由表和 codis-proxy 節點的元信息。同時 codis-config 發起的命令都會通過 ZooKeeper 同步到各個存活的 codis-proxy。
此外,Kafka、HBase、Hadoop,也都依靠Zookeeper同步節點信息,實現高可用。
參考鏈接:
https://juejin.im/post/5b037d5c518825426e024473