《In Search of an Understandable Consensus Algorithm》翻译

Abstract

Raft是一种用于管理replicated log的consensus algorithm。它能和Paxos产生同样的结果，有着和Paxos同样的性能，但是结构却不同于Paxos；它让Raft比Paxos更易于理解，并且也为用它构建实际的系统提供了更好的基础。为了增强可理解性，Raft将例如leader election, log replication以及safety等共识的关键元素进行了分离，并且提供了更强的一致性用于减少必须考虑的状态。从用户调查的结果来看，Raft比Paxos更易于学生学习。Raft包含了一种新的机制用于改变cluster membership，并通过overlapping majority来保证安全性。

1 Introduction

Consensus algorithm允许一群机器像一个整体一样工作，即使其中的一些成员发生故障也不会出现问题。正因为这一点，它在构建可靠的大规模软件系统的过程中起着关键的作用。Paxos一直主导着过去十年对consensus algorithm的讨论：许多共识的实现都基于Paxos或者受到它的影响，并且Paxos已经成为了用来教授学生关于共识的主要工具。

不幸的是，Paxos太难以理解了，尽管已经做了很多尝试想使它变得更加平易近人。另外，为了支持实际的系统，它的结构需要做非常复杂的改变。因此，系统架构师和学生都对Paxos感到很痛苦。

在我们自己和Paxos经历了一番痛苦挣扎之后，我们决定发明一种新的consensus algorithm来为系统的构建和教学提供更好的基础。我们的主要目标有点特别，是为了让它更加易于理解：我们是否能为实际的系统定义一个consensus algorithm，并且描述它的方式能比Paxos更加易于理解？此外，我们想要该算法有利于the development of intuitions，而这对系统构建者是必不可少的。算法能工作很重要，但是能清楚地显示它为什么能工作同样非常重要。

这项工作的结果就是一个叫做Raft的consensus algorithm。在设计Raft的时候，我们使用了一些额外的技术用于提供可理解性，包括decomposition（Raft分离了leader election, log replication和safety）以及状态空间的减少（和Paxos相比，Raft降低了不确定性以及sever之间能达到一致的方法）。一个由来自两个大学的43位学生组成的用户调查显示Raft要比Paxos易于理解的多；在同时学习了两种方法之后，其中的33名学生回答Raft的问题要比回答Paxos更好。

Raft在很多方面和现存的consensus algorithm类似，但是它有以下这些独特的特性：

• Strong leader：Raft比其他consensus algorithm使用了更强形式的leadership。比如，log entry只能从leader流向其他server。这简化了对于replicated log的管理并且使Raft更加易于理解。
• Leader election：Raft使用随机的时钟来选举leader。这只是在原来所有的consensus algorithm都需要的heartbeats的基础上增加了小小的一点东西，但是却简单快速地解决了冲突。
• Membership changes：Raft通过一种新的joint consensus的方法来实现server集合的改变，其中两个不同配置下的majority在过度阶段会发生重合。这能让集群在配置改变时也能继续正常运行。

我们相信不论对于教学还是用于真实系统实现的基础，Raft都要优于Paxos和其他的共识算法。它比其他算法更简答也更加易于理解；它能完全满足实际系统的需求；它有很多开源的实现并且被很多公司使用；它的安全性已经被完全证实了；并且它的效率也完全可以和其他算法相媲美。

论文的剩余部分介绍了replicated state machine问题（Section 2），讨论了Paxos的优缺点（Section 3），描述了可理解性的一般方法（Section 4），描述了Raft consensus algorithm（Section 5-7），评估Raft（Section 8），并且讨论了相关工作（Section 9）。Raft中的一小部分元素在这里因为篇幅的原因省略了，但是它们可以在一份扩展的技术报告里找到。其余的内容描述了client怎么和系统进行交互以及Raft log的空间怎么被回收。

2 Replicated state machines

consensus algorithm通常在replicated state machine的上下文中出现。在这种方法中，一群server上的state machine对同一个状态的拷贝进行计算，即使其中一些server宕机了也能正常运行。Replicated state machine通常用于解决分布式系统中的容错问题。例如，拥有单一的cluster leader的大规模系统，例如GFS，HDFS和RAMCloud通常会用一个单独的replicated state machine来管理leader的选举以及存储一些在拯救leader崩溃的配置信息。Replicated state machine典型的例子包括Chubby和ZooKeeper。

Replicated state machine通常用一个replicated log来实现，如Figure 1所示。每一个server存储了一个包含一系列命令的log，而它的state machine顺序执行这些命令。每一个log以同样的顺序包含了同样的指令，所以每一个state machine都会处理相同的命令。因为每一个state machine都是确定性的，因此计算将得到同样的状态和输出结果。

Consensus algorithm的作用是保证replicated log的一致性。server中的consensus module用于从client处接受命令并且将它们加入log。它会和其他serer的consensus module进行通信，从而确保每一个log都以相同的顺序包含相同的请求，每一个server的state machine都按顺序处理它们的log，并且将输出返回给client。最终，这些server呈现出的是一个单一的，高度可靠的state machine。

用于实际系统的consensus algorithm通常具有以下特性：

• 在所有的non-Byzantine条件下要确保正确性（从不返回一个错误的结果），包括网络延迟，分区以及网络包的丢失，重复和乱序。
• 只要majority of servers是可操作的并且能相互之间进行通信，以及和client进行通信，那么系统必须是可用的。因此，一个由五台server组成的集群必须能忍受两台server的故障。Server发生故障时，可以认为是暂停了；它们可能稍后会从恢复到存储在stable storage中的状态并且重新加入集群。
• 它们不依赖于时间来确保log的一致性：fault clocks和extreme message delays在最差的情况下也只能导致系统不可用的问题。
• 通常情况下，当集群中的大多数server已经对单一的RPC做出相应时，可以认为一个命令完成了。少数慢的server不应该影响整个系统的性能。

3 What's wrong with Paxos?

在过去的十年中，Leslie Lamport的Paxos协议几乎成了consensus的同义词：它是在课程中最常被教授的协议，并且很多consensus的实现都以它作为起点。Paxos首先定义了一个在单一的decision上能达到agreement的协议，例如一个单一的replicated log entry。我们将这样的一个子集称之为single-decree Paxos。之后Paxos可以将该协议的多个实例组合在一起去形成一系列的decision作为log（multi-Paxos）。Paxos保证了safety和liveness，并且它支持cluster membership的改变。它的正确性已经被证明了并且在一般的情况下也被证明是高效的。

不幸的是，Paxos有两个重要的缺陷。第一个缺陷是Paxos太难以理解了。它的完整描述是出了名的晦涩；很少有人能成功理解它，即使能也是花了很大的功夫。因此，已经做了很多尝试，试图用一个更简单的版本解释Paxos。虽然它们都着力于single-decree版本，但是仍然非常具有挑战性。在一项针对NSDI 2012与会者的调查中，我们发现很少有人对Paxos感到舒服，即使是那些经验丰富的研究人员。我们自己也对Paxos感到非常痛苦，我们在不能理解完整的协议，直到我们阅读了几个简化版的描述以及设计了我们自己的替代协议，而这整个过程持续了将近一年。

我们认为Paxos的晦涩来源于它将single-decree subset作为自己的基础。Single-decree Paxos被认为是微妙的：它被划分为两个不能用直觉来显示的阶段并且不能单独理解。因此，这就导致了很难对single-decree protocol是如何工作的建立起直觉。而multi-Paxos的composition rule则更加添加了复杂性。我们坚信对于在multiple decision的情况下到达consensus这个问题肯定能以其他更直接，更明显的方式被分解。

Paxos的第二个问题是它并没有为实际的实现提供一个很好的基础。一大原因是对于multi-Paxos没有一个广受认可的算法。Lamport的描述主要针对的是single-decree Paxos；它为multi-Paxos提供了一个大概的框架，但是很多细节并没有提及。对于充实以及优化Paxos已经做了很多努力，但是它们各自之间，以及和Lamport的概述都不相同。像Chubby这样的系统已经实现了类Paxos算法，但是它的很多细节并没有公开。

另外，Paxos的架构也不利于构建实际系统；这是它按single-decree分解的另一个后果。例如，独立地选取一系列的log entry并且将它们融合成一个顺序的log并没有太多好处，仅仅只是增加了复杂度。相反，构建一个围绕按顺序扩展log的系统是更简单和高效的。Paxos的另一个问题是它将对称的peer-to-peer作为核心（虽然在最后为了优化性能建议了一种弱形式的leadership）。这在只需要做一个decision的简单场景中是可行的，但是很少有实际的系统会使用这种方法。如果要有一系列的decision要决定，那么先选择一个leader，然后再让leader去协调decision。

因此，实际系统很少和Paxos类似。各种实现都以Paxos开始，然后发现实现起来很困难，于是最后开发出了一个完全不同的架构。这是极其费时并且容易出错的，而Paxos的难以理解则更加加剧了这个问题。Paxos的正确性理论很好证明，但是实际的实现和Paxos太过不同，因此这些证明就没什么价值了。接下来这段来自Chubby的评论是非常典型的：

Paxos算法的描述和现实世界的系统的需求之间有巨大的矛盾....而最终的系统都将建立在一个未经证明的协议之上

因为这些问题的存在，我们得出这样的结论，Paxos并没有为实际系统的构建或者是教学提供一个很好的基础。基于在大规模软件系统中consensus的重要性，我们决定尝试能否设计出另外一种比Paxos有着更好性质的consensus algorithm。而Raft就是我们实验得到的结果。

4 Designing for understandability

我们在设计Raft的时候有以下几个目标：它必须为系统的构建提供完整并且实际有效的基础，而这能极大地减少开发者的设计工作；它必须在所有条件下都是安全的，在典型的操作条件下是可用的，在通常的操作中是高效的。但我们最重要的目标，也是最大的挑战，就是可理解性。我们必须让广大的读者能比较容易地理解这个算法。并且要能够建立对这个算法的直觉，从而让系统构建者能做一些实际实现中必要的扩展。在设计Raft的很多节点上，我们要在很多可选方法之间做出选择。在这些情况下，我们基于可理解性对这些方法进行评估：对于每一个可选方案的描述是否困难（比如，它的状态空间的复杂度是多少，以及它是否有subtle implication？）以及读者是否能轻松地完全理解这种方法。

后来我们意识到这种分析方法具有很强的主观性；于是我们使用了两种方法让分析变得更具通用性。第一种是关于问题分解的众所周知的方法：是否有可能，我们可以将问题分解为可以被相对独立地解释，理解并且被解决的几部分。例如，在Raft中，我们分解了leader election, log replication, safety和membership changes这几部分。

我们的第二种方法是通过减少需要考虑的状态数，尽量让系统更一致以及尽可能地减少非确定性，来简化state space。另外，log不允许存在hole，Raft限制了log之间存在不一致的可能。虽然在大多数情况下，我们都要减少不确定性，但是在某些情况下，不确定性确实提高了可理解性。特别地，随机化的方法会引入不确定性，但是通过以相同的方式处理所有可能的选择（choose any; it doesn't matter），确实减少了state space。我们就使用了随机化来减少了Raft的leader election algorithm。

5 The Raft consensus algorithm

Raft是一种用于管理Section 2中所描述的形式的replicated log的算法。Figure 2以精简的形式概述了这一算法，而Figure 3列出了该算法的关键特性，而这些特性将在本节的剩余部分分别进行讨论。

Raft首先通过选举一个distinguished leader来实现consensus，然后将管理replicated log的责任全部给予这个leader。leader从client处接收log entry，再将它备份到其他server中，接着告诉server什么时候能安全地将log entry加入state machine中。leader的存在简化了replicated log的管理。比如，leader可以在不询问其他leader的情况下决定将新的entry存放在log的什么位置并且数据简单地从leader流向其他server。leader可能会发生故障或者和其他server断开，在这种情况下，会有新的leader被选举出来。

通过选举leader，Raft将consesus problem分解成三个相对独立的子问题，它们会在接下来的子章节中讨论：

• Leader election：在一个已有的leader故障之后，必须要有一个新的leader被选举出来（Section 5.2）
• Log replication：leader必须从client处接收log entry并且将它们在集群中进行备份，强制使其他log与它自己一致（Section 5.3）
• Safety：Raft中最关键的safety property就是Figure 3所示的State Machine Safety Property：如果有任何的server已经将一个特定的log entry加入它的state machine中，那么其他的server对于同一个log index的log entry必须相同

在展示了consensus algorithm之后，本节将讨论可用性以及时间在系统中扮演的角色

5.1 Raft basics

一个Raft集群包含多个server；一般都是五个，因此系统能忍受两台机器的故障。在任意给定时刻，每个server都处于以下三个状态中的一个：leader，follower，或者candidate。在正常情况下，只有一个leader，其他都是follower。follower是很被动的，它们不会自己发送请求，只是简单地对来自leader和candidate的请求进行回复。leader对所有来自client的请求进行处理（如果一个client和follower进行交互，follower会将它重定向给leader），第三种状态，candidate，是用来选举Section 5.2中描述的新的leader。Figure 4显示了各种状态以及它们之间的转换；关于转换将在下文进行讨论。

 

Raft将时间划分成任意长度的term，如Figure 5所示。Term以连续的整数进行编号。每个term以一个election开始，这个阶段会有一个或多个candidate竞选leader，如Section 5.2所示。 如果一个candidate竞选成功，那么它将在term剩下的时间里作为leader。在有些情况下，一个election可能导致一个split vote。在这种情况下，term将以一种没有leader的状态结束；而一个新的term（伴随着一个新的选举）将马上开始。Raft将保证在给定的一个term中，总是最多只有一个leader。

不同的server可能在不同的时间观察到term的转换，而在有些情况下，一个server可能会观察不到election甚至是一个完整的term。term在Raft中扮演的是一个logical clock的角色，它能够让server去检测那些需要淘汰的信息，例如过时的leader。每个server都存储了一个current term number，它会随着时间单调递增。current term会随着server之间的交互而改变；如果一个server的current term比其他的小，那么它就会将自己的current term更新到更大的值。如果一个candidate或者leader发现它的term已经过时了，那么它就会立即恢复到follower state。如果一个server接收到一个来自过时的term的请求，那么拒绝它。

Raft servers之间通过RPC进行通信，而consensus algorithm需要两种类型的RPC。RequestVote RPC由candidate在election期间发起（Section 5.2），AppendEntries RPC由leader发起，用于备份log entry和提供heartbeat（Section 5.3）。如果一个server没有收到回复，那么它会及时重发RPC，并且它们会并行发送RPC用于提高性能。

5.2 Leader election

Raft使用一种heartbeat mechanism 来触发leader election。当server启动的时候，默认作为follower。server如果能持续地从leader或者candidate处获取合法的RPC，那么它将始终保持follower状态。为了保持自己的权威性，leader会阶段性地发送heartbeats(不带有log entry的AppendEntry RPC)给所有的follower。如果一个server在一个叫做election timeout的时间段中没有收到交互信息，那么它就会认为不存在一个viable leader，并且开始一轮新的election选出新的leader。

为了开始一个election，follower会增加它的current term并且转换为candidate state。接着它会投票给自己，并且并行地给集群中的其他server发送RequestVote RPC。candidate将持续保持这种状态，直到以下三个条件中的一个被触发：(a) 它赢得了选举，(b) 另一个server宣布它自己是leader，或者(c) 过了一段时间之后也没有winner。这些情况将在接下来分别进行讨论。

如果一个candidate收到了来自集群中的majority个server对于同一个term的投票，那么它将赢得election。每一个server在给定的term中都最多只会投票给一个candidate，并且基于first-come-first-serverd原则（Section 5.4中将对于投票添加一个额外的约束）。majority原则确保了在一个给定的term中最多只有一个candidate可以赢得election（Figure 3中的Election Safety Property）。一旦一个candidate赢得了election，它将成为leader。之后它将向所有其他的server发送hearbeat用以确保自己的权威并且防止新一轮的election。

当在等待投票时，一个candidate可能会收到来自另一个server的AppendEntry RPC声称自己是leader。如果该leader的term（包含在该RPC中）至少和candidate的current term一样大，那么candiate认为该leader是合法的并且返回到follower的状态。如果RPC中的term比candidate的current term要小，那么candidate会拒绝该RPC并且依然保持为candidate状态。

第三种可能的情况是一个candidate在election中既没有赢也没有输：如果在同一时刻有很多follower成为了candidate，投票将会分裂因此没有candidate会获得majority。当这种情况发生时，每个candidate都会timeout并且通过增加term和发送新一轮的RequestVote RPC来开始新的election。然而，如果没有额外的措施，splite vote可能会一直重复下去。

 Raft使用随机的election timeout来确保split vote很少会发生并且保证即使发生了也很快会被解决。为了在一开始就避免split ovte，election timeout会在一个固定区间内随机选择（e.g., 150-300ms）。这就将server铺散开来从而保证在大多数情况下只有一个server会timeout；它将赢得election并且在其他的server timeout之前发送heartbeat。同样的机制也被用在处理split vote上。每个candidate在election开始的时候重新随机确定一个election timeout并在下一次election开始前静静等待timeout的到来；这就减少了在下一个新的election的时候发生split vote的可能。Section 8.3展示了使用这种方法快速选择一个leader的过程。

Election是一个展示可理解性作为指导我们做出设计选择的一个很好的例子。一开始我们计划使用一个rank system：每个candidate都会赋予一个唯一的rank，它会被用来在相互竞争的candidate之中做出选择。当一个candidate发现另一个candidate有更高的rank，那么它就会退回到follower的状态，从而让有更高rank的candidate能更容易赢得下一轮election。但我们发现这种方法会在可用性方面产生一些微妙的问题（如果有着更高rank的server发生了故障，一个低rank的server可能需要timeout并且重新成为candidate，但是这个过程发生地太快，则会引发新的leader选择过程）。我们对这一算法做了多次调整，但是每次调整之后都有新的corner cases产生。最后我们得出结论，随机重试的方法是更明显也更易理解的方法。

5.3 Log replication

一旦一个leader被选择出来以后，它开始处理client request。每个client request都包含了需要由replicated state machine执行的command。leader用command扩展log，作为新的entry，接着并行地给其他server发生AppendEntry RPC来备份entry。当该entry被安全地备份之后（如下所述），leader会让它的state machine执行该entry，并且将执行结果返回给client。如果follower崩溃了或者运行很慢，抑或是丢包了，leader会不停地重发AppendEntry RPC直到所有的follower最终都保存了所有的log entry。

Log以Figure 6中的形式被组织。当一个entry被leader接收的时候，每个log entry都会包含一个state machine command和term number。log entry中的term number是用来检测log之间的不一致性并且确保Figure 3中的一些特性的。同时，每个log entry都有一个整数的index用于标示它在log中的位置。

leader决定何时让state machine执行log entry是安全的，而这样的entry叫做committed。Raft保证所有committed entry都是durable并且最终会被所有可用的state machine执行。一旦创建它的leader已经将它备份到majority个server中，log entry就会被committed（e.g., Figure 6中的entry 7）。同时它也会commit leader的log中所有前缀的entry，包括那些由之前的leader创建的entry。Section 5.4中会讨论在leader改变之后应用这条规则会产生的一些微妙的问题，同时它也会展示这样的关于的commitment的定义是安全的。leader会追踪它已知被committed最高的index，并且会在之后的AppendEntry RPC（包括heartbeat）包含这个index从而让其他server能发现它。一旦follower知道了一个log entry被committed，它最终会让本地的state machine运行这个entry（以log的顺序）。

我们设计了Raft log mechanism来保持不同server的log之间的高度一致性。这不仅简化了系统行为让它们变得可预测，并且这也是确保安全性的重要组件。Raft维护了以下特性，它们合起来构成了Figure 3所示的Log Matching Property：

• 如果不同的log中的两个entry有相同的index和term，那么它们存储相同的command
• 如果不同的log中的两个entry有相同的index和term，那么它们前缀的entry都是相同的

第一个特性确保了leader对于给定的log index和term，它最多产生一个entry,并且log entry永远不会改变它在log中的位置。第二个特性则由AppendEntry一个简单的一致性检查来保证。在发送一个AppendEntry RPC的时候，leader会在其中包含新的entry之前的那个entry的index和term。如果follower没有在log中有同样index和term的entry，那么它就会拒绝新的entry。一致性检查扮演了induction step：log的initial empty state是满足Log Matching Property的，而一致性检查则在log扩展的时候保证了Log Matching Property。因此，当AppendEntry成功返回的时候，leader就知道该follower的log和它自己是一致的。

在进行正常操作的时候，leader和follower的操作始终是一致的，因此AppendEntry的一致性检查用于不会失败。但是，leader崩溃会导致log处于不一致的状态（老的leader可能还没有将它log中的所有entry完全备份）。而这些不一致性可能随着一系列的leader和follower的崩溃而叠加。Figure 7说明了follower的log可能和新的leader不一致的情况。follower中可能会遗漏一些leader中的entry，同时它里面也可能有一些leader中没有的额外的entry，或者两者都有。log中遗失的或者额外的entry中可能跨越多个term。

为了让follower的log和自己保持一致，leader必须找到两个log一致的最远的entry，并且删除follower该entry之后所有的entry。所有这些操作都用于回应AppendEntry RPC的一致性检查。leader为每一个follower维护了一个nextIndex，它代表了leader将会发送给follower的下一个log entry。当一个leader刚刚开始执行的时候，它会将所有的nextIndex都初始化为它自己log的最后一个entry的index加一（Figure 7中的11）。如果follower和leader的log不一致，AppendEntry RPC的一致性检查会在下一个AppendEntry RPC的时候失败。在收到一个rejection之后，leader会减小它的nextIndex并且重发AppendEntry RPC。最终nextIndex会达到leader和follower的log匹配的状态。此时，AppendEntry会成功返回，移除了follower的log中冲突的entry并且会根据leader的log进行扩展（如果有的话）。一旦AppendEntry成功，follower已经和leader的log一致了，而且将在term的接下来部分保持。该协议可以通过减少rejected AppendEntry RPC的数目来优化。

在这种机制下，leader不用在它刚刚成为leader的时候执行任何额外的动作用于恢复log的一致性。它只是正常地开始执行，并且log会随着AppendEntry一致性检查的失败而不断收敛。leader从来不会覆写或者删除它自己log的entry（Figure 3中的Leader Append-Only Property）。

该log replication mechanism展示了Section 2中想要达到的consensus property：Raft可以接收，备份，并且执行新的log entry只要有majority个server活着；在正常情况下，一个新的entry会在单一的一轮RPC中被备份到cluster的一个majority中；因此一个运行较慢的follower并不会影响性能。

5.4 Safety

在前面的章节中描述了Raft如何选举leader以及备份log entry。但是之前描述的机制并不足以保证每个state machine以同样的顺序执行同样的command。比如，follower可能在leader commit多个log entry的时候一直处于不可用的状态，而之后它可能被选作leader并且用新的entry覆写这些entry；因此，不同的state machine可能会执行不同的command sequences。

本节中我们通过给哪些server能被选举为leader增加约束来完善Raft算法。该约束确保任何给定的term的leader会包含之前term所有commit的entry（Figure 3中的Leader Completeness Property）。通过增加election restriction，我们更加细化了commitment的规则。最后，我们展示了Leader Completeness Property的证明草图并且展示了它如何能让replicated state machine正确操作。

5.4.2 Election restriction

任何leader-based consensus algorithm，leader最终都必须存储所有的committed log entry。在一些consensus algorithm中，例如Viewstamped Replication，即使一开始没有包含全部的committed entry也能被选为leader。这些算法都会包含额外的机制用于识别遗失的entry并且将它们传输给新的leader，要么在election期间，要么在这不久之后。不幸的是，这需要额外的机制以及复杂度。Raft使用了一种更简单的方法，它保证在选举期间每个新的leader都包含了之前term都包含的所有entry，从而不需要将这些entry传输到leader。这意味着log entry的流动是单方向的，只从leader流向follower，而leader从不会覆写log中已有的entry。

Raft使用voting process来防止那些log不包含全部committed entry的candidate赢得election。candidate为了赢得选举必须和cluster的majority进行交互，这意味着每个committed entry必须都在其中的一个majority存在。如果一个candidate的log至少和任何majority中的log保持up-to-date（"up-to-date"将在下文精确定义），那么它就包含了所有committed entry。RequestVote RPC实现了这一约束：RPC中包含了candidate的log信息，voter会拒绝投票，如果它自己的log比该candidate的log更up-to-date。

Raft通过比较log中last entry的index和term来确定两个log哪个更up-to-date。如果两个log的last entry有不同的term，那么拥有较大term的那个log更up-to-date。如果两个log以相同的term结束，那么哪个log更长就更up-to-date。

5.4.2 Committing entries from previous terms

如Section 5.3中所述，leader知道current term中的entry已经被提交了，一旦该term已经被majority个server存储了。如果一个leader在committing an entry之前就崩溃了，那么未来的leader就会试着完成该entry的备份。但是leader很难马上确认之前term的entry已经commited一旦它被存储于majority个server中。Figure 8展示了这样一种情况，一个old log entry已经被存储在majority个server中，但是它仍然可以被future leader覆写。

为了防止Figure 8中这样问题的发生，Raft从不会通过计算备份的数目来提交之前term的log entry。只有leader的当前term的log entry才通过计算备份数committed；一旦当前term的entry以这种方式被committed了，那么之前的所有entry都将因为Log Matching Property而被间接committed。其实在很多情况下，leader可以非常安全地确定一个old entry已经被committed了（比如，如果该entry已经被存储在所有server中了），但是Raft为了简单起见使用了一种更保守的方法。

因为leader从之前的term备份entry时，log要保留之前的term number，这会让Raft在commitment rule中引入额外的复杂度。在其他consensus algorithm中，如果一个新的leader从之前的term备份entry时，它必须使用它自己的新的term number。因为log entry的term number不随时间和log的不同而改变，这就能让Raft更加容易地进行推导。另外，Raft中的新的leader与其他算法相比只需要从之前的term传输更少的log entry（其他的算法必须传输备份的log entry进行重新编号在它们被committed之前）。

5.4.3 Safety argument

给出了完整的Raft算法之后，我们可以进一步论证Leader Completeness Property成立（该论据基于safety proof；参见Section 8.2）。我们假设Leader Completeness Property是不成立的，接着推出矛盾。假设term T的leader(leader_T) commit了一个该term的log entry，但是该log entry并没有被未来的term的leader存储。考虑满足大于T的最小的term U，它的leader(leader_U)没有存储该entry。

1、该committed entry在leader_U选举期间一定不存在于它的log中（leader从不删除或者覆写entry）。

2、leader_T将entry备份到了集群的majority中，并且leader_U获取了来自集群的majority的投票，如Figure 9所示。而voter是达到矛盾的关键。

3、voter一定在投票给leader_U之前已经接受了来自leader_T的committed entry；否则它将拒绝来自leader_T的AppendEntry request（因为它的current term高于T）。

4、当voter投票给leader_U的时候它依然保有该entry，因为每个intervening leader都包含该entry(根据假设)，leader从不删除entry，而follower只删除它们和leader矛盾的entry。

5、voter投票给leader_U，因此leader_U的log一定和voter的log一样up-to-date。这就导致了两个矛盾中的其中一个矛盾。

6、首先，如果voter和leader_U共享同一个last log term，那么leader_u的log至少要和voter的log一样长，因此它的log包含了voter的log中的每一个entry。这是一个矛盾，因为voter包含了committed entry而leader_U假设是不包含的。

7、除非，leader_U的last log term必须比voter的大。进一步说，它必须大于T，因为voter的last log term至少是T（它包含了term T的committed entry）。之前创建leader_U的last log entry的leader必须在它的log中包含了committed entry（根据假设）。那么，根据Log Matching Property，leader_U的log必须包含committed entry，这也是一个矛盾。

8、这完成了矛盾。因此，所有term大于T的leader必须包含所有来自于T并且在term T提交的entry。

9、Log Matching Property确保了future leader也会包含那些间接committed的entry，例如Figure 8(d)中的index 2。

给定Leader Completeness Property，证明Figure 3中的State Machine Safety Property就比较容易，即让所有的state machine以相同的顺序执行同样的log entry。

5.5 Follower and candidate crashes

直到现在我们一直关注leader failures。follower和candidate的崩溃比起leader的崩溃要容易处理得多，而且它们的处理方式是相同的。如果一个follower或者candidate崩溃了，那么之后发送给它的RequestVote和AppendEntry RPC都会失败。Raft通过不断地重试来处理这些故障；如果崩溃的服务器重启了，之后RPC就会成功完成。如果server在完成了RPC但是在回复之前崩溃了，那么它会在重启之后收到一个同样的RPC。但是Raft的RPC是幂等的，因此不会造成什么问题。比如一个follower接收了包含一个已经在log中存在的entry的AppendEntry request，它会直接忽略。

5.6 Timing and availability

我们对于Raft的一个要求是，它的安全性不能依赖于时间：系统不会因为有些事件发生地比预期慢了或快了而产生错误的结果。然而，可用性（系统及时响应client的能力）将不可避免地依赖于时间。比如，因为server崩溃造成的信息交换的时间比通常情况下来得长，candidate就不能停留足够长的时间来赢得election；而没有一个稳定的leader，Raft将不能进一步执行。

leader election是Raft中时间起最重要作用的地方。当系统满足以下的timing requirement的时候，Raft就能够选举并且维护一个稳定的leader：

broadcastTime << electionTimeout << MTBF

在这个不等式中，broadcastTime是server并行地向集群中的每个server发送RPC并且收到回复的平均时间；electionTimeout就是如Section 5.2中描述的选举超时；MTBF是单个server发生故障的时间间隔。broadcastTime必须比electionTimeout小几个数量级，这样leader就能可靠地发送heartbeat message从而防止follower开始选举；通过随机化的方法确定electionTimeout，该不等式又让split vote不太可能出现。electionTimeout必须比MTBF小几个数量级，从而让系统能稳定运行。当leader崩溃时，系统会在大概一个electionTimeout里不可用；我们希望这只占整个时间的很小一部分。

broadcastTime和MTBF都是底层系统的特性，而electionTimeout是我们必须选择的。Raft的RPC通常要求接收者持久化信息到stable storage，因此broadcastTime的范围在0.5ms到20ms之间，这取决于存储技术。因此，electionTimeout可以取10ms到500ms。通常，server的MTBF是几个月或者更多，因此很容易满足timing requirement。

6 Cluster membership changes

 直到现在为止，我们都假设集群的configuration(参与consensus algorithm的server集合)是固定的。但实际上，偶尔改变configuration是必要的，比如在server发生故障时将其移除或者改变the degree of replication。虽然这可以通过停止整个集群，更新configuration file，再重启集群实现，但是这会让集群在转换期间变得不可用。另外，如果这其中存在手动操作的话，还会有操作失误的风险。为了防止这些情况的发生，我们决定自动化configuration change并且将它们和Raft consensus algorithm结合起来。

为了保证configuration change mechanism的安全，在转换期间不能有任意时刻对于同一个term有两个leader。不幸的是，任何从old configuration转换到new configuration的方法都是不安全的。不可能一次性对所有server进行自动转换，所以在转换期间集群会被潜在地分隔为两个独立的majority（见Figure 10）。

为了保证安全性，configuration change必须使用two-phase的方法。有很多种方法实现two-phase，比如有些系统使用first phase来禁用old configuration，从而不能处理client request；然后在second phase中使用new configuration。在Raft中，集群首先转换到一个transitional configuration，我们称作joint consensus；一旦joint consensus被committed之后，系统就过渡到new configuration。joint consensus 同时结合了old configuration和new configuration。

• log entry会被备份到两个configuration的所有server中
• 来自任意一个configuration的server都可能会成为leader
• Agreement（election和entry的commitment）需要同时得到old configuration和new configuration的majority

joint consensus允许单个的server在不妥协安全性的情况下，在不同的时间对进行configuration的过渡。另外，joint consensus允许集群在configuration转换期间依旧能够处理来自client的请求。

集群的configuration被存储在replicated log的special entry中，并且通过它来通信；Figure 11说明了configuration改变的过程。当leader收到了一个将configuration从C_old转换到C_new请求，它会将joint consensus的configuration（figure中的C_old,new）作为一个log entry存储并且使用上文描述的机制进行备份。一旦一个给定的server将一个new configuration entry加入它的log中，它就会在以后所有的decision中使用该configuration（server总是使用它log中的latest configuration，而不管该entry是否被committed）。这意味着leader会使用C_old,new来决定何时C_old,new被committed。如果该leader崩溃了，一个新的leader可能使用C_old或者C_old,new，这取决于winning candidate是否收到了C_old,new。在任何情况下，C_new都不能在这个阶段做单方面的决定。

 一旦C_old,new被committed，C_old或者C_new就不能在没有对方同意的情况下单独做decision了，而Leader Completeness Property则确保了C_old,new的log entry的server才能被选作leader。现在leader创建一个描述C_new的log entry并且将它备份到整个集群是安全的。同样，这个configuration只要server看到它就会生效。当新的configuration在C_new的规则被committed时，old configuration就不再有效了，而那些不在new configuration中的server就会被关闭。如Figure 11所示，没有一个时刻，C_old或者C_new会单方面做决定；这就保证了安全性。

对于reconfiguration还有三个问题需要处理。第一个问题是新加入的server可能初始的时候没有存储任何log entry。如果它们以这种状态直接添加进集群，可能会花费相当多的时间让它们赶上来，而在这期间就不能commit新的log entry了。为了避免availability gaps，Raft在configuration change之前引入了一个additional phase，在这期间新的server作为non-voting member（leader将log entry向它们备份，但是在计算majority时，并不考虑它们）加入集群。一旦新加入的server赶上了集群中的其他server之后，reconfiguration就会按照上面描述的步骤进行。

第二个问题是集群的leader可能并不包含在new configuration中。在这种情况下，leader一旦commit了C_new log entry之后leader就会step down(返回follower的状态)。这意味着会有这样一段时间（当在commit C_new）时，leader可能会管理一个并不包含它自己的集群；它备份log entry，但是并不把它自己考虑在majority的计算中。leader的转换会在C_new被committed之后发生，因为这是第一次new configuration可以独立运行（总是可以在C_new中选出一个leader）。在这之前，只有C_old中的server能被选为leader。

第三个问题是removed server（那些不在C_new中的server）可能会破坏集群。这些server不会收到heartbeats，所以它们会timeout并且开始new election。于是它们会用新的term number发送RequestVote RPC，这会导致current leader恢复到follower的状态。一个新的leader最终会被选举出来，但是removed server还会再次timeout，而这个过程会不断重复，最终导致可用性非常差。

为了防止这样的情况发生，server会无视RequestVote RPC，如果它们认为current leader依旧存在的话。特别地，如果一个server在election timeout内收到了一个RequestVote RPC，它不会更新它的term或者进行投票。这不会影响正常的election，在开始election之前每个server都至少等待一个最小的election timeout。然而，这避免了removed server带来的破坏；如果一个leader能够从它的集群中得到heartbeat，那么它就不会受到更大的term number的影响。

7 Clients and log compaction

由于篇幅的原因本章就略过了，但是相关的资料在本论文的扩展版中可以获得。其中描述了client如何和Raft进行交互，包括client怎么找到cluster leader以及Raft如何支持linearizable semantics。扩展版本中还描述了如何利用snapshotting的方法回收replicated log的空间。这些问题在所有consensus-based system中都会出现，Raft的解决方案和它们是类似的。

8 Implementation and evalution

我们已经将Raft作为存储RAMCloud配置信息的replicated state machine实现并且协助RAMCloud coordinator的故障转移。Raft的实现大概包含2000行C++代码，不包括测试，注释以及空白行。源代码可以自由获取。同时还有25个基于本论文的关于Raft的独立第三方开源实现。同时，还有各种公司在部署Raft-based systems。本节的剩余部分将从可理解性，正确性以及性能三个标准来评估Raft。

....

10 Conclusion

算法的设计通常以正确性，效率以及简洁作为主要目标。虽然这些目标都是非常有意义的，但是我们认为可理解性同样重要。在开发者将算法实际实现以前，这一切都不可能实现，而这些实现往往都会偏离或者扩展算法的本意。除非开发者对算法有了深刻的理解并且能够对它建立直觉，否则将很难从它们的实现中获得想要的特性。

一个被普遍接收但是难以理解的算法Paxos已经困扰了学生和开发者很多年了，而在本篇论文中，我们解决了distributed consensus的这个问题。我们开发了一种新的算法，Raft，就像上面展示的，它比Paxos更加易于理解。我们同样相信Raft为实际系统的构建提供了一个更好的基础。以可理解性作为主要目标改变了我们对Raft的设计；随着设计的进行我们发现我们在不断重用一些技术，例如解构问题，以及简化状态空间。这些技术不仅提高了Raft的可理解性，同时也更让我们相信它的正确性。