從Paxos到zookeeper分散式一致性原理與實踐-Zookeeper與Paxos
從Paxos到zookeeper分散式一致性原理與實踐
Zookeeper與Paxos
Apache Zookeeper是有Apache Hadoop的子項目發展而來,於2010年11月正式成為了Apache頂級項目.Zookeeper為分散式應用提供了高效且可靠的分散式協調服務, 提供了諸如統一命名服務,配製管理和分散式鎖的基礎服務,在解決分散式一致性方面,Zookeeper並沒有直接採用Paxos演算法,而是採用了一種被稱為的一致性協議.
初識Zookeeper
Zookeeper是什麼
Zookeeper是一個典型的分散式數據一致性的解決方案,分散式應用程序可以基於它實現諸如數據的發布/訂閱,負載均衡,命名服務,分散式協調/通知,集群管理,Master選舉,分散式鎖和分散式隊列等功能.Zookeeper可以保證如下分散式一致性的特性:
順序一致性
從同一個客戶端發起的事務請求,最終將會嚴格地按照其發起的順序被應用到Zookeeper中去.
原子性
所有事務請求的處理結果在整個集群中所有機器上的應用情況是一致的,也就是說,要麼整個集群所有機器都成功應用了某一個事務, 要麼就都沒應用.
單一視圖
無論客戶端連接時哪個Zookeeper伺服器,其看到的服務端數據模型都是一致的.
可靠性
一旦服務端成功地應用了一個事務,並完成對客戶端的響應,name該事務所引起的服務端狀態變更將會一直被保留下來,除非有另一個事務又對其進行了變更.
實時性
Zookeeper僅僅保證在一定的時間內,客戶端最終一定能夠從服務端上讀取到最新數據.
Zookeeper的設計目標
目標一: 簡單的數據模型
Zookeeper使得分散式程序能夠通過一個共享的,樹型結構的名字空間進行互相協調,這裡所說的樹型結構的名字空間就是Zookeeper的數據模型,被稱為Znode,Zookeeper的數據模型類似一個文件系統,Znode之間層級就像文件系統中目錄結構一樣,Zookeeper將全量數據存儲在內存中,以此來實現提高伺服器吞吐,減少延遲的目的
目標二: 可以構建集群
Zookeeper提供集群機制,一般3~5台機器就可以組成一個可用的Zookeeper集群了.
?
組成Zookeeper集群的每台機器都會在內存中維護當前伺服器狀態,並且每台服機器之間保持通信,Zookeeper集群遵循, 只要集群中超過一半的機器正常工作,那麼整個集群就能夠正常對外提供服務.
Zookeeper的客戶端會選擇和集群中任意一台機器共同創建一個TCP連接,而一旦這個連接意外斷開後,客戶端會自動連接到集群中的其他機器.
目標三: 順序訪問
對於來自客戶端的每個更新請求,Zookeeper都會分配一個全局唯一的遞增編號.這個編號反映了所有事物操作的先後順序,應用程序可以使用Zookeeper的這個特性來實現更高層次的同步原語.
目標四: 高性能
由於Zookeeper將全量數據存儲在內存中,並直接服務於客戶端所有非事務請求,因此它尤其適合以讀操作為主的應用場景.
Zookeeper的基本概念
集群角色
Zookeeper中沒有傳統集群中,概念, 而是引入了,,三種角色,集群中所有機器通過Leader選舉來選定一台被稱為的機器,Leader機器為客戶端提供讀和寫服務.除Leader外,其他機器包括和,二者都提供讀服務,唯一區別在於Observer不參與選舉也不參與寫操作的策略,Observer在不影響寫性能的情況下提升集群的讀性能
會話(session)
Session是指客戶端會話,在Zookeeper中,客戶端通過TCP長連接通信,客戶端能夠通過心跳檢測與伺服器保持有效的會話,也能夠向Zookeeper伺服器發送請求並接受響應,同時還能通過該連接接收來自伺服器的Watch事件通知.Session的sessionTimeout值來設置一個客戶端會話超時時間, 當伺服器壓力太大,連接斷開時,只要在sessionTimeout規定的時間內能夠重新連接上集群中任意一台伺服器,name會話仍然有效
數據節點(Znode)
Zookeeper的節點不同於傳統集群節點(一台機器)概念,Zookeeper節點分為兩類,第一類是指構建集群的機器,稱之為,第二類是指數據模型中的數據單元,稱之為,Zookeeper將所有的數據村粗在內存中,數據模型是一棵樹(Znode Tree),由斜杠(/)進行分割路徑,就是一個Znode,例如/zookeeper/path1.每個Znode上都會保存自己的數據內容(元數據)和一些屬性信息.
Zookeeper中的數據節點分為和兩類.
持久節點就是一旦這個Znode被創建了,只要不是主動移除,這個節點會一直保存在Zookeeper上.
臨時節點是指在綁定在客戶端會話上,一旦客戶端會話失效,則節點就會被移除.
另外Zookeeper還允許用戶為每個節點添加一個特殊屬性,一旦節點標記了這個屬性,那麼節點創建時候會自動在節點名後面追加一個整形數字.
版本
Zookeeper會為每個Znode都維護一個叫做Stat的數據結構,Stat中記錄了這個Znode的三個數據版本,分別為,和`aversion(當前Znode的ACL版本)
Watcher
Watcher(事件監聽器)是Zookeeper中的一個重要特性.Zookeeper允許用戶在指定節點上註冊一些Watcher,並在觸發時通知到感興趣的客戶端上去,該機制是Zookeeper實現分散式協調服務的重要特性.
ACL
Zookeeper採用ACL(Access Control Lists)策略來進行許可權控制,類似於UNIX文件系統許可權控制,Zookeeper定義了5種許可權.
CREATE: 創建子節點的許可權
READ: 獲取節點數據和子節點列表的許可權
WRITE: 更新節點數據的許可權
DELETE: 刪除子節點的許可權
ADMIN: 設置節點ACL的許可權
Zookeeper的ZAB協議
ZAB協議
ZAB協議是為分散式協調服務Zookeeper專門設計的一種支持崩潰恢復的原子廣播協議.它是一種特別為Zookeeper設計的崩潰可恢復的源自消息廣播演算法.
ZAB協議的核心是定義了對於那些會改變Zookeeper伺服器狀態的事務請求的處理方式.即:
協議介紹
ZAB協議包括兩種基本模式,分別是和.
當整個服務框架在啟動過程中,或是Leader伺服器出現網路中斷,崩潰退出與重啟等異常情況時,ZAB協議就會進入恢復模式並選舉新的Leader伺服器.當選舉產生了新的Leader伺服器,同事集群中已經有過半的機器與該Leader伺服器完成了狀態同步之後,ZAB協議就會退出恢復模式.
當集群中已經有過半的Follower伺服器完成了和Leader伺服器狀態同步,那麼整個服務框架就進入了消息廣播模式了.
消息廣播
ZAB協議的消息廣播過程使用的是,類似於一個二階段提交過程.針對客戶端的事務請求,Leader伺服器會為其生成對應的事務Proposal,並將其發送給集群中其餘所有的機器,然後再分別收集各自的選票,最後進行事務提交
?
崩潰恢復
一旦Leader伺服器出現崩潰,或者由於網路的原因導致Leader伺服器失去過半的Follower的聯繫,那麼就會進入崩潰恢復模式,因此,ZAB協議需要一個高效且可靠的Leader選舉演算法從而保證能夠快速選舉出新的Leader,同時要讓Leader自己和集群中所有其他的機器能夠感知到選舉產生的心Leader伺服器.
基本特性
ZAB協議需要確保那些已經在leader伺服器上提交的事務最終被所有伺服器都提交
?
崩潰恢復過程需要確保已經被Leader提交的Proposal也能夠被所有Follower提交
ZAB協議需要確保丟棄那些只在Leader伺服器上被提出的事務
?
崩潰恢復過程需要跳過那些已經被丟棄的事務Proposal
數據同步
Leader伺服器需要確保所有的Follower伺服器能夠收到每一條事務Proposal,並能夠正確地將所有已經提交了的事務Proposal應用到內存資料庫中去.Leader伺服器會為每一個Follower伺服器準備一個隊列,並將那些沒有被各Follower伺服器同步的事務以Proposal消息的形式逐個發送給Follower伺服器,並在每一個Proposal消息後面緊接著再發送一個Commit消息,以表示該事務已經被提交.等到Follower伺服器將所有尚未同步的事務Proposal都從Leader伺服器上同步過來並成功應用到本地數據後,Leader伺服器就會將該Follower伺服器加入到真正可用Follower列表中並開始之後的流程.
在ZXID設計中,ZXID是一個64位的數字,其中低32位可以看做一個單調遞增計數器,Leader伺服器產生一個新的事務Proposal時候,都會對其進行加1操作,高32位代表了Leader周期epoch的編號,每當選舉產生一個新的Leader伺服器,就會從這個Leader伺服器上讀取出本地日誌中最大事務Proposal的ZXID,並從ZXID中解析出對應的epoch值,然後進行加1操作.之後就會以此編號作為新的epoch,並將低32位置0來開始生成新的ZXID.
深入ZAB協議
系統模型
ZAB協議需要構建的分散式系統模型，通常在一個由一組進程N=組成的分散式系統中，其中每一個進程都具有各自的存儲設備，各個進程之間通過相互通信來實現消息的傳遞
一個進程正常狀態稱為UP狀態。如果一個進程崩潰了，我們成為DOWN狀態。
事實上當集群中存在過半的處於UP狀態的進程組成了一個進程子集之後，就可以進行正常的消息廣播。我們將這樣的一個進程子集稱為Quorum(下文中使用Q來表示)
一個ZK集群必須滿足：Q屬於N的子集。Q1和Q2兩個子集的交集不是空。
?
我們使用Pi和Pj來分別表示進程集合N中的兩個不同進程，使用Cij來表示進程Pi和Pj之間的網路通信通道，其滿足如下兩個基本特性:
完整性(Integrity)
前置性(Prefix)
演算法描述
整個ZAB協議主要包括,,三個階段.組成ZAB協的沒一個分散式進程,會循環地執行這三個階段,沒一個循環稱為一個準進程周期
ZAB協議演算法表述術語介紹
?
階段一: 發現
階段一主要是Leader選舉過程,用於在多個分散式進程中選舉出主進程.准Leader L 和Follower F的工作流程分別如下:
階段二: 同步
在完成發現流程後,就進入了同步階段,在這一階段中,Leader L和Follower F的工作流程分別如下:?
?
階段三: 廣播
完成同步階段之後,ZAB協議就可以正式開始接收客戶端新的事務請求,並進行消息廣播流程.
?
ZAB協議演算法描述示意圖
運行分析
在ZAB協議的設計中,每一個進程都有可能處於一下三種狀態之一:
LOOKING: Leader選舉階段
FOLLOWING: Follower伺服器和Leader保持同步狀態
LEADING: Leader伺服器作為主進程領導狀態
ZAB與Paxos演算法的聯繫與區別
ZAB協議並不是Paxos演算法的典型實現, 在講解ZAB和Paxos之間的區別之間,先看下兩者聯繫:
兩者都存在一個類似於Leader進程的角色,由其負責協調多個Follower進程運行
Leader進程都會等待超半數的Follower做出正確的反饋後,才會講一個提案進行提交
在ZAB協議中,每個Proposal都包含了一個epoch值,用來代表當前的Leader周期,在Paxos演算法中,同樣存在這樣的標識,只是名字變成了Ballot.
兩者在本質上的區別在於,兩者的設計目標不太一樣,ZAB協議主要用於構建一個高可用的分散式數據主備系統,例如Zookeeper,而Paxos演算法則是用於構建一個分散式的一致性狀態機系統.
TAG:咖啡日記本 |