10分钟入门Raft算法

Posted 2021-04-27 胖牛势

 

0 1

Raft算法的历史背景

在讲Raft算法之前，有必要提一下Paxos算法，Paxos算法是Leslie Lamport于1990年提出的基于消息传递的一致性算法。我们在一文中曾浅显地解读过。

然而，由于算法难以理解，刚开始并没有得到很多人的重视。其后，作者在八年后，也就是1998年在ACM上正式发表，然而由于算法难以理解还是没有得到重视。而作者之后用更容易接受的方法重新发表了一篇论文《Paxos Made Simple》。

可见，Paxos算法是有多难理解，即便现在放到很多高校，依然很多学生、教授都反馈Paxos算法难以理解。同时，Paxos算法在实际应用实现的时候也是比较困难的。这也是为什么会有后来Raft算法的提出。

0 2

Raft算法的概念

Raft是实现分布式共识的一种算法，主要用来管理日志复制的一致性。它和Paxos的功能是一样，但是相比于Paxos，Raft算法更容易理解、也更容易应用到实际的系统当中。而Raft算法也是联盟链采用比较多的共识算法。

斯坦福大学的Diego Ongaro和John Ousterhout在《In Search of an Understandable Consensus Algorithm》一文（提出Raft算法的论文）中，依据Raft学习难度的实验数据绘制过下图。实验对象是斯坦福大学和加州大学伯克利分校的高年级本科生和研究生。这些天才也觉得Paxos很难。所以对于大多数人看不懂Paxos算法是很正常的，看不懂Raft原理也不奇怪。

 

0 3

Raft算法

论文Raft算法介绍的章节包括6个部分，为了更好地理解，今天我们只讲解入门部分，不作深入探究。

1、Raft基础知识

Raft集群包含多个服务器，5个服务器是比较典型的，允许系统容忍两个故障。在任何给定时间，每个服务器都处于以下三种状态之一，领导者（Leader），追随者（Follower）或候选人（Candidate）。这几个状态间可以相互转换。

Leader：处理所有客户端交互，日志复制等，一般一次只有一个Leader

Follower：类似选民，完全被动

Candidate：类似Proposer律师，可以被选为一个新的领导人

 

2、选举Leader

Raft使用心跳机制来触发领导者选举。当服务器启动时，它们以Follower的身份开始。只要服务器从Leader或Candidate接收到有效的RPC请求，服务器就会保持Follower状态。Leader向所有Follower发送定期心跳（不带日志条目的AppendEntries RPC）以保持其权限。如果一个Follower在称为选举超时的一段时间内没有接到任何通信，该Follower认为没有可行的领导者并开始选举新的Leader。

3、日志复制

一旦Leader当选，它就开始为客户请求提供服务。每个客户端请求包含由复制状态机执行的命令。

Leader将命令作为新条目附加到其日志，然后并行地向每个其他服务器发出AppendEntries RPC以复制条目。当条目被安全地复制时，Leader将条目应用于其状态机并将该执行的结果返回给客户端。

如果Follower崩溃或运行缓慢，或者网络数据包丢失，Leader将无限期地重试AppendEntries RPC（即使它已经响应客户端），直到所有Follower最终存储所有日志条目。

4、时间和可用性

Raft 的特性之一就是不依赖时间，选举Leader只要系统满足下面的时间要求：

广播时间（broadcastTime） << 选举超时时间（electionTimeout） << 平均故障间隔时间（MTBF）

广播时间指的是从一个服务器并行的发送请求给集群中的其他服务器并接收响应的平均时间；

平均故障间隔时间就是对于一台服务器而言，两次故障之间的平均时间。

广播时间必须比选举超时时间小一个量级，这样Leader才能够发送稳定的心跳消息来阻止Follower开始进入选举状态。

选举超时时间应该要比平均故障间隔时间小上几个数量级，这样整个系统才能稳定的运行。

当Leader崩溃后，整个系统会大约相当于选举超时的时间里不可用。

5、Follower和Candidate崩溃

Follower和Candidate崩溃后的处理方式比Leader要简单的多，并且他们的处理方式是相同的。如果Follower或者Candidate崩溃了，那么后续发送给他们的 RPCs 都会失败。

Raft 中处理这种失败就是简单的通过无限的重试；如果崩溃的机器重启了，那么这些 RPC 就会完整的成功。如果一个服务器在完成了一个 RPC，但是还没有响应的时候崩溃了，那么在他重新启动之后就会再次收到同样的请求。

Raft 的 RPCs 都是幂等的，所以这样重试不会造成任何问题。例如一个Follower如果收到附加日志请求但是他已经包含了这一日志，那么他就会直接忽略这个新的请求。

6、安全性

到目前为止描述的机制并不能充分的保证每一个状态机会按照相同的顺序执行相同的指令。例如，一个Follower可能会进入不可用状态同时Leader已经提交了若干的日志条目，然后这个Follower可能会被选举为Leader并且覆盖这些日志条目；因此，不同的状态机可能会执行不同的指令序列。

这一节通过在Leader选举的时候增加一些限制来完善 Raft 算法。这一限制保证了任何的Leader对于给定的任期号，都拥有了之前任期的所有被提交的日志条目。增加这一选举时的限制，对于提交时的规则也更加清晰。

0 4

总结

Raft算法具备强一致、高可靠、高可用等优点，具体体现在：

强一致性：虽然所有节点的数据并非实时一致，但Raft算法保证Leader节点的数据最全，同时所有请求都由Leader处理，所以在客户端角度看是强一致性的。

高可靠性：Raft算法保证了Committed的日志不会被修改，State Matchine只应用Committed的日志，所以当客户端收到请求成功即代表数据不再改变。Committed日志在大多数节点上冗余存储，少于一半的磁盘故障数据不会丢失。

高可用性：从Raft算法原理可以看出，选举和日志同步都只需要大多数的节点正常互联即可，所以少量节点故障或网络异常不会影响系统的可用性。即使Leader故障，在选举超时到期后，集群自发选举新Leader，无需人工干预，不可用时间极小。但Leader故障时存在重复数据问题，需要业务去重或幂等性保证。

高性能：与必须将数据写到所有节点才能返回客户端成功的算法相比，Raft算法只需要大多数节点成功即可，少量节点处理缓慢不会延缓整体系统运行。

往期推荐

END

工作洽谈，商务合作，请联系我们

这是一个有温度的公众号

我就知道你“在看”