ZAB協議全程ZOOKEEPER AUTOMIC BROADCAST算法
zab協議相似於Paxos,可是paxos協議不能保證先提交的Proposer會被執行,同事也有可能會出現活鎖的狀況,zab協議改進了Paxos協議,Elect出Leader,只有Leader才能提交Proposer,同事集羣內部Leader負責寫請求,讀操做會被負載到PC上,並且zab協議保證了若是Leader 掛掉以後可以快速保證選舉出最新的Leader,並且最新的Leader是zk集羣內部proposer zxid最大的那臺pc,這樣保證集羣內部恢復的時候能夠最快,同事保證了丟棄只有在Leader上提交的Proposer。服務器
相好比Paxos協議,zab協議少了Prepare階段,圖中Follower對應Paxos中的Acceptor,Observers對應Paxos中的Learner網絡
ZAB協議下面zk集羣內部角色性能
設計特色:學習
1:最終一致性,client不管鏈接那個Server,展現給他的都是同一個試圖,這也是zk最重要的一個特性設計
2 .可靠性:具備簡單、健壯、良好的性能,若是消息m被到一臺服務器接受,那麼它將被全部的服務器接受。server
3 .實時性:Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息,或者服務器失效的信息。但因爲網絡延時等緣由,Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據,若是須要最新數據,應該在讀數據以前調用sync()接口。blog
4 .等待無關(wait-free):慢的或者失效的client不得干預快速的client的請求,使得每一個client都能有效的等待。接口
5.原子性:更新只能成功或者失敗,沒有中間狀態。事務
6 .順序性:包括全局有序和偏序兩種:全局有序是指若是在一臺服務器上消息a在消息b前發佈,則在全部Server上消息a都將在消息b前被髮布;偏序是指若是一個消息b在消息a後被同一個發送者發佈,a必將排在b前面。
ZAB協議:
主要分爲原子廣播和崩潰恢復階段
原子廣播階段:
就是zk對外提供服務的時候,Leader負責接收client的請求,廣播給Follower,Observer負責學習,此處再也不作贅述
崩潰恢復階段:
zk中規定了節點的狀態,又是那種Leading,Following,Looking三種,Leading就是Leader,Following就是Follower,Looking就是在Leader掛掉以後集羣內部Server的狀態,下面是一個狀態切換圖:
當節點處於Looking的時候就開始進行選舉,具體的選舉流程此處再也不贅述,ZK中採用的FastLeaderElection算法
上面也說到了,在選舉的時候,只有事務ID最高的那臺server才能成爲Leader
在選舉出Leader以後,leader服務器會把以前的zxid解析出來,前32位加一做爲新事務的前32位,後32位從0開始;
新的Leader會經過zxid和Follower進行對於,來達到數據同步的狀態,當恢復到一致的時候,集羣開始進入原子廣播狀態,其實這個過程很複雜,我這裏只是很簡單的說一下,有興趣的能夠自行百度