Raft vs ZAB

Leader Election

问题	Raft	ZAB
检测Leader宕机	Raft是由follower进行检测,follower在一定的时间内收不到Leader的心跳就会任务Leader宕机,follower自己会变成candidate.	ZAB的检测是Leader和follower仪器检测;Leader维护了Q的集合,当多数派集合不在超过半数的时候,Leader自动进入选举状态; follower和Leader之间有单独的tcp连接,如果超时收不到Leader的心跳也会进入选举状态.
过期Leader的屏蔽	Raft通过term来识别	ZAB通过epoch来实现
Leader选举的投票过程	Raft每个选举周期每个节点只能投一票,选举失败后进入下一个投票周期;	ZAB在选举的时候会首先都选举自己,然后通过不停的更新投票的信息最终选出Leader

Leader Election

问题	Raft	ZAB
选取Leader后的数据同步	Raft通过AppendEntry RPC进行同步	ZAB通过一个专门的Recovery Phase来做这个事情
新Leader对老Leader未commit数据的处理	ZAB在Recovery Phase直接commit老Leader的数据
对于新加入节点的数据同步	Raft对这种情况,不会影响client的写请求;	ZAB对于新加入的节点要走一个Recovery Phase的流程,会影响client的写入

Client read

问题	Raft	ZAB
stale read	Raft严禁stale read	Zk 默认情况下会出现 stale read，如果想避免 stale read 必须使用 sync() + read()