文章目錄
一、概述
在前面的博文中我們已經分別分析過了Zookeeper中的Zab協議和Fle算法，在這篇文章中我們將對兩者的執行流程進行總結，並通過流程圖的方式對FLe算法實現的整體流程進行梳理，最終探究Zab協議和Fle算法之間的關係。
博客內所有文章均爲 原創，所有示意圖均爲 原創，若轉載請附原文鏈接。
二、Zab 協議描述
2.1 前文回顧
三、Fle 算法描述
3.1 前文回顧
3.2 算法流程圖——網絡層
3.3 算法流程圖——應用層
四、Zab 協議與 Fle 算法
4.1 Zab 協議與 Fle 算法的關係
在分析Zab協議時我們曾明確Zab協議整體包括三個階段，即發現、同步和廣播，並且在發現之前還存在一個領導者選舉階段，只是Zab協議對這個選舉階段的算法沒有進行過多的限制，只要求其輸出一個合適的且能夠領導大多數節點的領導者即可，而這個選舉的算法落實到Zookeeper中正是我們一直分析的FastLeaderElection算法。
但經過前兩篇博文的分析後，我們可以發現其實Fle算法的實現是對Zab協議中的規範進行了一些優化，下面我們就來具體分析一下Fle算法對Zab協議規範做了哪些優化。
4.2 Fle 算法所做的優化
首先我們先回顧一下在Zab協議中第一個發現階段所做的操作。因爲Zab算法對選舉算法所輸出的領導者沒有要求，所以Zab協議不能保證選舉算法輸出的領導者具備整個集羣中 最新且最全 的數據。因此在第一個階段中所做的主要就是讓領導者開啓一個新的Epoch並將其發送給跟隨者，然後領導者會通過接收跟隨者所回覆的包含自身數據情況的ACK來補足所自身缺失的數據，從而使領導者自身成爲集羣中包含 最新且最全 數據的節點。
One interesting optimization is to use a leader election primitive that selects a leader that has the latest epoch and has accepted the transaction with highest zxid among a quorum of processes. Such a leader provides directly the initial history of the new epoch.
其實對於第一階段的優化在Zab協議的論文中也有提到過，正如上面截取的論文片段所述，對於Zab協議的一種優化方式就是讓選舉算法輸出的領導者自身就具有集羣中 最新且最全 數據，也就是說將第一階段的領導者數據更新工作的完全交給選舉算法來完成，讓選舉算法來保證領導者數據 最新且最全 的屬性。而落實到Fle選舉算法中就是在投票過程中對候選人數據的約束，具體體現在選舉過程中的totalOrderPredicate方法。
protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {
/*
* 1- 首先兩者中 Epoch 大者優先；
* 2- 其次當兩者的 Epoch 相等時，zxid 大者優先；
* 3- 最後當兩者的 Epoch 和 zxid 均相等時，myid 大者優先；
*/
return ((newEpoch > curEpoch) ||
((newEpoch == curEpoch) &&
((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))));
}
根據totalOrderPredicate方法中所列的投票規則即可保證只有當選票中候選人節點的數據比當前節點的數據 更新更全 時，當前節點纔會將選票投給它，從而保證了最終Fle算法輸出的領導者是一定具有集羣中 最新且最全 數據的節點。所以最後總結來說Fle算法完成了Zab協議中的 選舉 和 發現 兩個階段的工作。
五、參考文獻
- Zab: High-performance broadcast for primary-backup systems