文章目录
一、概述
在前面的博文中我们已经分别分析过了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
