10分钟弄懂Raft算法

分布式系统在极大提高可用性、容错性的同时，带来了一致性问题（CAP理论）。Raft算法能够解决分布式系统环境下的一致性问题。

我们熟悉的ETCD注册中心就采用了这个算法；你现在看的这篇微信公众号文章，也是保存在基于Raft算法的高可用存储服务器中。

没有耐心看文字，就直接拉到第四章。

一、Raft算法是什么？

过去，Paxos一直是分布式协议的标准，但是Paxos难于理解，更难以实现，Google的分布式锁系统Chubby作为Paxos实现曾经遭遇到很多坑。后来斯坦福大学提出了Raft算法。

Raft是用于管理复制日志的一致性算法。它的效果相当于(multi-)Paxos，跟Paxos一样高效，但结构与Paxos不同。这使得Raft比Paxos更容易理解，也为构建实用系统提供了更好的基础。

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

二、什么是一致性（Consensus）

一致性是分布式系统容错的基本问题。一致性涉及多个服务器状态（Values）达成一致。一旦他们就状态做出决定，该决定就是最终决定。当大多数服务器可用时，典型的一致性算法会取得进展。例如，即使2台服务器发生故障，5台服务器的集群也可以继续运行。如果更多服务器失败，它们将停止进展（但永远不会返回错误的结果）。

三、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最终存储所有日志条目。（后边游戏中有个request命令菜单，就是模仿客户端请求的）

除了以上3点，文章还重点描述了安全、Follower和Candidate崩溃、时间和可用性三个方面。

四、可视化的Raft算法

github上有一个帮助大家理解算法的页面，地址是https://raft.github.io/raftscope/index.html

建议用电脑浏览器打开，如果在手机微信里打开，需要选择“访问原网页”

我截了一个运行状态的截图，左侧显示五台服务器，右侧显示日志。