FLE（zab协议的具体实现）和raft的区别

FLE（zab协议的具体实现）和raft的区别

下面不管是zab中所说的事务还是raft中所说的log，都用记录代替。

1.相同点

都可以保证全序（total order）提交记录。

leader（不论是否是新选举出来的）包含集群中在任意节点上已提交的记录。即，一条记录在节点A上被提交了，即使节点A已经宕机，那么只有此时集群存在leader，该记录仍然在leader中。注意：2个算法都不能保证选举出来的新leader包含最多（最新）的记录，只能保证一定拥有已提交的所有记录。

leader只需要向follower同步记录，不需要从folower接受记录，此特点是因为上一条。

都可以强制follower删除leader没有的记录，因为已提交的记录leader肯定有，并且只有已提交的记录，用户才能感知到，因此删除leader没有的记录，不影响用户视图。

都是法定人数（quorum）机制。

2.不同点

epoch更新方式不同：在raft中，只要某一个节点（follower）timeout（长时间没有收到leader的消息），那么它就会自增自己的epoch发起新的选举；或者某一个节点（leader和follower）收到高epoch的消息，也会自增自己的epoch。在FLE中，节点（leader和follower）想要增加epoch，只有leader将之前leader的已提交记录全部同步给大部分follower，leader和follower才可以增加epoch。因此，在raft中，follower的epoch有时候会大于leader的，但是在FLE中，follower的epoch只能跟随leader一起改变，所以不论什么情况都不会大于系统此时leader的epoch。

选举成功的决定因素不同：在raft中决定因素是最后一条记录的(epoch,index)；

在FLE中决定因素是节点的epoch，sid和最后一条记录的zxid。

每一轮选举投票不同：在raft中，在同一个epoch，每一个节点只能投票给一个节点，如果此epoch没有选出leader，则只能等该节点的epoch改变后，才可以投票给其他节点；在FLE中，每一轮选举中，每一个节点可以投票给多个节点，直到该节点选出一个leader，此时投的票才固定为leader。

新leader发送它任期的记录的时机不同：在raft中，新产生的leader，即可以发送自己的记录给follower，尽管此时前任已提交的记录还没有同步给大多数节点；在FLE中，只有新leader将所有前任提交的记录同步给follower，才可以发送自己的记录。

同步数据的方式不同：raft是通过matchIndex，找到follower第一个能和leader匹配的记录的index，然后leader发送该index之后的记录给该follower，并且只有leader当前任期的记录提交时，才可以提交之前任期未提交的记录。zk使用三种不同的同步方式，DIFF,SNAP,TRUNC，而且zk可以在同步之前任期的已提交记录的时候就提交该记录。