zab協議
協議介紹
關鍵字：過半數節點
訊息廣播
順序性保證
奔潰恢復
基本特性
leader選舉
資料同步
丟棄資料 結論
深入zab協議
系統模型
//存在任意q q是 ∏ 的子集
∧ ∀q，q ⊆ ∏
//存在任意時候的q1 q2，他們的交集不等於空集合（此處的意義在於q1或q2 任意乙個都超過半數，應此不管如何去交集都能得到乙個子集合，極端情況是正好半數多乙個元素的情況）
∧ ∀q1和q2， q1∩q2≠∅
前置性問題描述
主程序週期 事物
演算法描述
術語名說明f.p
follower f處理過的最後乙個事務proposal
f.zxid
follower f處理過的歷史事務proposal中最後乙個proposal的事務表示zxid
h_f每乙個follower f通常都已經處理（接受）了不少事務proposal，並且會有乙個針對已經處理過的事務的集合，將其表示為hf，表示follower f已經處理過的事務的序列
i_e初始化歷史記錄，在某個主程序週期epoch中，當準leader完成階段一之後，此時他的h_f就被標記為i_e
階段一：發現
當leader l接受到來自過半follower的確認訊息ack後，leader l就會從這過半伺服器中選取出乙個follower f，使用他的i_e最為初始化事務結婚i_e』
關於這個follower f的選取對於quorum中其他任意乙個follower f』 ，f需要滿足以下兩個條件中的乙個：
//任意follower f'的epoch主節點週期值小於 follower f主節點週期值（主節點週期值也就是leader節點序列號每次選舉+1這個）
cepoch
(f'.p)
<
cepoch
(f.p)
//如果兩節點follower f與follower f'的epoch值相同也就是在同乙個主節點週期，那麼我們比較follower f'處理的最後乙個事務的zxid要小於 選出來的follower f處理的最後乙個事務的zxid，也就是我們選出來的必然是up集合中擁有最大zxid事務的follower節點，或者兩個都相同則都可以是leader列表的備選
(cepoch
(f'.p) = cepoch(f.p)) & ( f'
.zxid < f.zxid 或 f'.zxid = f.zxid)
階段三：廣播 總結
如下圖是以上三個流程總結，各個訊息說明如下：
Zookeeper原子廣播Zab
zookeeper的原子廣播 zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做zab協議。zab協議有兩種模式，它們分別是恢復模式 選主 和廣播模式 同步 當服務啟動或者在領導者崩潰後，zab就進入了恢復模式，當領導者被選舉出來，且大多數serve...
Zookeeper集群搭建以及zab協議
單機環境下,jdk zookeeper安裝完畢,基於一台虛擬機器,進行zookeeper的偽集群搭建,zookeeper集群中包含三個節點,節點對外提供服務埠號分別為2181,2182,2183 基於zookeeper 3.4.10複製三份zookeeper安裝好的伺服器檔案,目錄名稱分別為zook...
怎麼理解 ZAB 協議？
zab協議是為分布式協調服務 zookeeper 專門設計的一種支援崩潰恢復的原子廣播協議。zab 協議包括兩種基本的模式 崩潰恢復 和 訊息廣播。當整個 zookeeper 集群 剛剛啟動或者 leader 伺服器宕機 重啟或者網路故障導致不存在過半的伺服器與 leader 伺服器保持正常通訊時，...