共识算法系列：Raft算法关键点综述、优缺点总结

2018-12-06 | 阅读：次

本文参考：

The Raft Consensus Algorithm
Raft实现指南
OceanBase-基于Raft分布式一致性协议实现的局限及其对数据库的风险

如果了解Paxos的人，去学习Raft的应该不难，还不了解Paxos的同学可以看看我的上一篇文章共识算法系列：Paxos/Multi-Paxos算法关键点综述、优缺点总结。Google的粗粒度锁服务Chubby的设计开发者Burrows曾经说过：“所有一致性协议本质上要么是Paxos要么是其变体”，Raft就是非常有代表性的Paxos的变体。

直奔主题：

首先我们可以看看Raft的可视化Raft Visualization。跟着操作一遍下来，Raft的整个流程甚至是Raft对各种情况的处理应该也很清楚了。

单纯学习Raft算法，可以直接看论文（中英都有）Raft一致性算法论文的中文翻译。也有总结好的算法Raft算法详解，以及实现Raft实现指南。

如果了解Multi-Paxos，那我们直接用Multi-Paxos和Raft来对比：

• 首先，Multi-Paxos可以没有Leader（这里注意的Leader不是指Master，Multi-Paxos中的Master是通过强一致性算法选出来的，与Leader有本质上的不同），但是Raft必须有Leader。

• Raft的Leader相当于Multi-Paxos当中的当了Leader的Proposer。Raft达到一致性的原理和Multi-Paxos的原理本质上是相同的，只是Raft不允许并发提交proposals，而是只能由Leader来提交。Raft在接收到Requset之后的行为与Multi-Paxos几乎是一致的，Raft的操作可以看成是Multi-Paxos中的：（假设进行完了第一个Promise）直接发送“Accept”给非Leader节点，收集“Accept”请求的Responses，最后进行“Learn”。

• Raft是Multi-Paxos的悲观版本，Multi-Paxos其实是可以并行提交的，虽然效率会退化为Paxos，但它愿意去乐观解决冲突，对所有的请求来之不拒。而Raft相对来说比较“悲观”。这种“悲观”的意思是会认为会存在很多冲突，所以在算法上我选择主动大多都避免冲突。直接选择了Leader的方式，并用Term和成员管理去消除很多冲突。

对于Raft和Paxos的使用场景问题，可以参考这个raft算法与paxos算法相比有什么优势，使用场景有什么差异？。

总结

特征/优点:

• 比Paxos算法更容易理解，⽽且更容易工程化实现。

• Raft与Paxos一样高效，效率上Raft等价于(multi-)Paxos。

• 适⽤用于permissioned systems(私有链)，只能容纳故障节点，不⽀持作恶节点。最⼤的容错故障节点 是(N-1)/2，其中 N 为集群中总的节点数量。 强化了leader的地位，整个协议可以分割成两个部分:

  • Leader在时。由Leader向Follower同步⽇志，
  • Leader失效了，选一个新Leader。

• 强调合法leader的唯一性协议，它们直接从leader的⻆度描述协议的流程，也从leader的角度出发论证正 确性。但是实际上它们使用了了和Paxos完全⼀样的原理来保证协议的安全性。

缺点:

• 只适用于permissioned systems (私有链)，只能容纳故障节点，不容纳作恶节点。

• 对于OceanBase为什么不使用Raft而是Paxos的问题，知乎有人提问：OceanBase的一致性协议为什么选择 paxos而不是raft?。 对于点赞最多的答案，我的认同@LynnCui的看法：“日志是否有顺序要求完全取决于状态机。如果状态机顺序无关，raft为何不能分裂成多个group？如果状态机顺序有关，paxos又如何能无序提交？对于无序要求的状态机，raft和multi-paxos都可以多group化。raft根本就是paxos的一个实现，两者的性能上其实是没有区别的，paxos只是在允许非leader进行提交这么一个点上享受了一丝的便利。”。总的来说Raft只是Paxos实现的一种，但是很明显，Raft身上的限制比较多，而Paxos在算法层面上更通用，所以相比于Raft，在Paxos的基础上进行优化，上限应该会更高。

总结完毕，如文中出现错误或歧义，欢迎指正！如有不全面的地方也欢迎补充！