个人网站设计策划,企业网站流量预估,黄冈建设培训中心网站,石家庄现状首先#xff0c;二者都是通过选举一个 Leader 来简化复杂度#xff0c;后续的工作都是由 Leader 来做。
投票的时候#xff0c;二者都需要定义一个轮次
Raft 定义了 term 来表示选举轮次 ZooKeeper 定义了 electionEpoch 来表示 同步数据的时候#xff0c;都希望选举出来…首先二者都是通过选举一个 Leader 来简化复杂度后续的工作都是由 Leader 来做。
投票的时候二者都需要定义一个轮次
Raft 定义了 term 来表示选举轮次 ZooKeeper 定义了 electionEpoch 来表示 同步数据的时候都希望选举出来的 Leader 至少包含之前全部已提交的日志。
那如何能包含之前的全部日志我们可以通过判断 Leader 节点中日志的逻辑时间序列包含越新、越多日志的节点越有可能包含之前全部的已提交日志。对于两种协议
Raftterm 大的优先然后 entry 的 index 大的优先 ZooKeeperpeerEpoch 大的优先然后 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 发起新一轮的投票。 ZooKeeperLeader 和 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会不会有乱序的问题
RaftRaft 对于之前 term 的 entry 被过半复制暂不提交只有当本 term 的数据提交了才能将之前 term 的数据一起提交也是能保证顺序的 ZooKeeperZooKeepe r每次 Leader 选举之后都会进行数据同步不会有乱序问题 在出现网络分区情况下的应对措施二者都是相同的
目前 ZooKeeper 和 Raft 都是过半即可所以对于分区是容忍的。如5台机器分区发生后分成 2 部分一部分 3 台另一部分 2 台这 2 部分之间无法相互通信。
其中含有 3 台的那部分仍然可以凑成一个过半仍然可以对外提供服务但是它不允许有节点再挂了一旦再挂一台则就全部不可用了。
含有 2 台的那部分则无法提供服务即只要连接的是这 2 台机器都无法执行相关请求。 参考 分布式系统协议Paxos、Raft和ZAB
