basic-paxos、 multi-paxos、 raft 、redis的raft 一致性算法总结

阅读本篇博客前,希望各位对basic-paxos、multi-paxos、raft算法有基本的了解

不清楚的请参考我的这几篇博客

Paxos第一篇 - 使用Basic-Paxos协议的日志同步与恢复_YZF_Kevin的博客-CSDN博客

Paxos第二篇 - 使用Multi-Paxos协议的日志同步与恢复_YZF_Kevin的博客-CSDN博客

Paxos第三篇 - Paxos成员组变更_YZF_Kevin的博客-CSDN博客

分布式系列文章——Paxos算法原理与推导_YZF_Kevin的博客-CSDN博客

一步一步理解Paxos算法_YZF_Kevin的博客-CSDN博客

raft算法动画演示_YZF_Kevin的博客-CSDN博客_raft算法动图

raft算法总结_YZF_Kevin的博客-CSDN博客

总结

basic-paxos算法,也就是经典的paxos算法

1)    2PC(2 phase commit,也就是2阶段提交),分为 prepare(准备)阶段:proposer产生perposeID,发给各个accepter。accept(接受)阶段:proposer根据准备阶段的结果最终提出commit,accepter决定接受还是不接受。至少三次网络交互的延迟(1. 产生logID;2. prepare阶段;3. accept阶段),所以效率很低

2)    没有leader概念,各个进程之间是完全平等的

3)    一个进程可能既是proposer,又是accepter

multi-paxos算法

1)    有leader概念,先根据basic-paxos算法选举一个proposer为leader,其他proposer不再发起提案,这样就进入了一个leader任期,只能由leader发起提案,后续不再需要产生proposeID,也不必执行prepare阶段,直接执行accept阶段,所以冲突的可能性很低,效率比较高。我们可以将leader选举过程中的prepare操作,视为该leader任期内所有日志的一次性prepare操作,实际上acceptor应答选举的prepare成功的消息之前要先将这次prepare请求所携带的proposalID持久化到本地

2)    后续的日志仍然要经过所有accepter的大多数(超过1/2)同意,即仍然有accept阶段

3)    confirm日志的优化,之前的basic-paxos读取日志时,仍要执行一轮Paxos过程,效率低下,所以multi-paxos算法引入了confirm日志的优化,对于有confirm日志的日志不再执行paxos过程。对于没有confirm日志的日志,才会重新执行一遍paxos过程,即重确认

4)    日志可能不连续,所以新leader需要对空洞的日志都进行一轮paxos

raft算法

1)    有leader概念,且日志条目(log entries)只从 leader 流向其他follower服务器。leader有任期(term)限制,当leader失联时,其各个follower使用随机计时器进行 leader 选举,经过其他follower节点的大多数同意可当选为leader。

2)      分三中角色,Leader,Follower,Candidate 这三种角色相互独立,也就是服务器在同一时间内只可能扮演其中一种角色。Leader:用于对所有用户的请求进行处理以及日志的复制等等;Follower:不会主动发送消息,只响应来自LeaderCandidate的请求;Candidate:用于选举新的Leader

3)    有任期(term)概念,用一个数字表示,每一个任期的开始都是一次选举,一个或多个Candidate会试图称为Leader,但同一任期内只有获得超过一半的票数才能称为Leader,该机制保证了在给定的一个任期最多只有一个Leader

4)    日志中包含的内容(任期号,日志包含的命令,索引号),如果 2 个节点日志的相同的索引位置的日志条目的任期号相同,那么 Raft 就认为这个日志从头到这个索引之间的所有日志全部相同。所以当 leader 和 follower 日志冲突的时候,leader 将校验 follower 最后一条日志是否和 leader 匹配,如果不匹配,将递减查询,直到匹配,匹配后,follower删除冲突的日志。这样就实现了主从日志的一致性

redis的raft

redis虽然用的raft算法,但是做了修改,并非原始的raft算法

1)    不同之处:raft算法中发生选举时是某个leader的所有follower内部进行选举出一个新leader。但redis中是某个leader的所有follower向其他的所有leader发起选举投票,计票数从而产生新leader

raft中的follower投票时并不是无脑地投给第一个发来请求的,而是会比较其附带的最后日志索引,只有对方的索引日志比自己大时才会投赞同票,若比自己的日志索引号小,则拒绝。

redis中因为是其他leader节点投票,他们自己本地没有对应的日志索引号,所以会无脑投票给第一个发来请求的节点

2)    相同之处:选举时的算法(超过一半即可),日志的复制等

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值