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

YZF_Kevin

已于 2023-03-06 20:38:46 修改

阅读量786

点赞数 1

分类专栏：一致性算法文章标签：一致性算法一致性算法总结

于 2022-10-04 22:23:22 首次发布

本文链接：https://blog.csdn.net/yzf279533105/article/details/127163022

版权

一致性算法专栏收录该内容

9 篇文章 0 订阅

订阅专栏

阅读本篇博客前，希望各位对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：不会主动发送消息，只响应来自Leader与Candidate的请求；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) 相同之处：选举时的算法（超过一半即可），日志的复制等