6.4 Raft 算法

不可否认，Paxos 是一个划时代的共识算法。在 Raft 出现之前，绝大多数共识算法的实现都是基于 Paxos 或者受其影响，同时 Paxos 也成为了教学领域里讲解共识问题时的示例。

但不幸的是 Paxos 理解起来非常晦涩，虽然论文中定义了可能实现 Multi Paxos 的方法，但缺少实现细节，这些都导致了工业界和学术界都对 Paxos 算法感到十分头疼。在很长时间的一段时间内，并没有一个被大众所认同的 Multi Paxos 算法。

在那段时期，虽然所有的共识系统都是从 Paxos 开始的，但工程师在实现过程中发现有很多难以逾越的难题，往往不得已又开发出一种与 Paxos 完全不一样的架构，这就导致 Lamport 的证明并没有太大价值。笔者借用 Chubby 作者的一句话:

Chubby 作者评论 Paxos

Paxos 算法描述与工程实现之间存在巨大的鸿沟，最终实现的系统往往建立在一个还未被证明的算法之上。

考虑到共识问题在大规模分布式系统的重要性，同时也为了再共识问题上提供更好的教学方法，斯坦福大学的学者们决定设计一个完全可以替代 Paxos 的共识算法，该算法的首要目的是能够被多数人理解，当然，容错和高效也是必备条件。

2013 年，斯坦福的 Diego Ongaro 和 John Ousterhout 发表了论文 《In Search of an Understandable Consensus Algorithm》提出了 Raft 算法，并给出了详细的实现细节，此后 Raft 算法成为分布式系统开发的首选共识算法。

额外知识

Raft 的本意是 R{eliable|plicated|dundant} And Fault-Tolerant（可靠、复制、冗余和容错），组合起来的单词 raft 有筏的含义，隐喻这是一艘可以帮助你逃离 Paxos 小岛的救生筏（Raft）。

如果一句话总结 Raft，笔者觉得可以这样定义：从本质上说，Raft 是通过实现以强 Leader 为准的方式实现的一系列值的共识和各个节点日志的一致。Raft 算法的所有节点中会有一个节点作为领导者（Leader），其他非 Leader 节点被称为跟随者（follower）。leader 负责接收客户端的请求，根据请求生成日志并把日志复制到所有的节点中，这个过程我们称为复制过程。

除了复制过程，如果 Leader 发生宕机等异常情况，其他节点需要成为新的 Leader，继续履行 Leader 的职责，我们将这个过程称为选举过程。

此外，在选举