raft和zab算法的区别_raft和zab日志复制对比

首先，二者都是通过选举一个 Leader 来简化复杂度，后续的工作都是由 Leader 来做。

投票的时候，二者都需要定义一个轮次

Raft 定义了 term 来表示选举轮次
ZooKeeper 定义了 electionEpoch 来表示
同步数据的时候，都希望选举出来的 Leader 至少包含之前全部已提交的日志。

那如何能包含之前的全部日志？我们可以通过判断 Leader 节点中日志的逻辑时间序列，包含越新、越多日志的节点，越有可能包含之前全部的已提交日志。对于两种协议：

Raft：term 大的优先，然后 entry 的 index 大的优先
ZooKeeper：peerEpoch 大的优先，然后 zxid 大的优先
ZooKeeper 有 2 个轮次，一个是选举轮次 electionEpoch，另一个是日志的轮次 peerEpoch（即表示这个日志是哪个轮次产生的）。而 Raft 则是只有一个轮次，相当于日志轮次和选举轮次共用了。

但是有一个问题，日志越新越大的比较方式能满足我们“Leader 至少包含之前全部已提交的日志”的愿望吗？

对于 Raft 协议，特殊情况下不能。对于 Raft 协议，通过两个约束来保证一致性：

当前 term 的 Leader 不能“直接”提交之前 term 的 entries。
必须要等到当前 term 有 entry 过半了，才顺便一起将之前 term 的 entries 进行提交。
至于为什么必须这样，在什么特殊情况下会出问题，这篇文章中给了详细说明：Raft算法赏析建议直接看里面的例子，有点长我就不抄过来了。

但是对于 ZooKeeper 是不会出现这种情况的，因为 ZooKeeper 在每次 Leader 选举完成之后，都会进行数据之间的同步纠正，所以每一个轮次，大家都日志内容都是统一的。

继续对比，二者的选举效率也不同：

Raft 中的每个节点在某个 term 轮次内只能投一次票，哪个 Candidate 先请求投票谁就可能先获得投票，这样就可能造成分区，即各个 Candidate 都没有收到过半的投票，Raft 通过 Candidate 设置不同的超时时间，来快速解决这个问题，使得先超时的Candidate（在其他人还未超时时）优先请求来获得过半投票。
ZooKeeper 中的每个节点，在某个 electionEpoch 轮次内，可以投多次票，只要遇到更大的票就更新，然后分发新的投票给所有人。这种情况下不存在分区现象，同时有利于选出含有更新更多的日志的 Server，但是选举时间理论上相对 Raft 要花费的多。
在一个节点启动后，如何加入一个集群（这里是说本来就在集群配置内的一个节点）：

Raft：比较简单，该节点启动后，会收到 Leader 的 AppendEntries RPC，在这个 RPC 里面包含 Leader 信息，可以直接识别。
ZooKeeper：启动后，会向所有的其他节点发送投票通知，然后收到其他节点的投票。该节点只需要判断上述投票是否过半，过半则可以确认 Leader。
关于 Leader 选举的触发：

首先集群启动的时候，二者肯定都要先进行选举。

如果选举完成后，发生了超时：

Raft：目前只是 Follower 在检测。如过 Follower 在倒计时时间内未收到 Leader 的心跳信息，则 Follower 转变成 Candidate，自增 term 发起新一轮的投票。
ZooKeeper：Leader 和 Follower 都有各自的检测超时方式，Leader 是检测是否过半 Follower 心跳回复了，Follower 检测 Leader 是否发送心跳了。一旦 Leader 检测失败，则 Leader 进入 Looking 状态，其他 Follower 过一段时间因收不到 Leader 心跳也会进入 Looking 状态，从而出发新的 Leader 选举。一旦 Follower 检测失败了，则该 Follower 进入 Looking 状态，此时 Leader 和其他 Follower 仍然保持良好，则该 Follower 仍然是去学习上述 Leader 的投票，而不是触发新一轮的 Leader 选举。
关于上一轮次 Leader 残存的数据怎么处理：

包括两种数据：

已过半复制的日志
未过半复制的日志
Raft：对于之前 term 的过半或未过半复制的日志采取的是保守的策略，全部判定为未提交，只有当前 term 的日志过半了，才会顺便将之前 term 的日志进行提交
ZooKeeper：采取激进的策略，对于所有过半还是未过半的日志都判定为提交，都将其应用到状态机中
Raft 的保守策略更多是因为 Raft 在 Leader 选举完成之后，没有同步更新过程来保持和 Leader 一致（在可以对外处理请求之前的这一同步过程）。而 ZooKeeper 是有该过程的。

在对正常请求的处理方式上，二者都是基本相同的，大致过程都是过半复制。

对于正常请求的消息顺序保证：

Raft：对请求先转换成 entry，复制时，也是按照 Leader 中 log 的顺序复制给 Follower 的，对 entry 的提交是按 index 进行顺序提交的，是可以保证顺序的
ZooKeeper：在提交议案的时候也是按顺序写入各个 Follower 对应在 Leader 中的队列，然后 Follower 必然是按照顺序来接收到议案的，对于议案的过半提交也都是一个个来进行的
如果是 Leader 挂了之后，重新选举出 Leader，会不会有乱序的问题？

Raft：Raft 对于之前 term 的 entry 被过半复制暂不提交，只有当本 term 的数据提交了才能将之前 term 的数据一起提交，也是能保证顺序的
ZooKeeper：ZooKeepe r每次 Leader 选举之后都会进行数据同步，不会有乱序问题
在出现网络分区情况下的应对措施，二者都是相同的：

目前 ZooKeeper 和 Raft 都是过半即可，所以对于分区是容忍的。如5台机器，分区发生后分成 2 部分，一部分 3 台，另一部分 2 台，这 2 部分之间无法相互通信。

其中，含有 3 台的那部分，仍然可以凑成一个过半，仍然可以对外提供服务，但是它不允许有节点再挂了，一旦再挂一台则就全部不可用了。

含有 2 台的那部分，则无法提供服务，即只要连接的是这 2 台机器，都无法执行相关请求。
参考 分布式系统协议Paxos、Raft和ZAB