Raft是一个用于管理复制日志的一致性算法它和Paxos算法产生的结果一样，和Paxos一样高效但是它的结构和Paxos不一样；导致了Raft比Paxos更好的理解并且还提供了一个更好的基础用于建设实鼡的系统。为了提高Raft的可理解性Raft分解成了几个关键过程，例如leader选举日志复制，和安全它加强了一致性以减少中间必须考虑的状态。來自一位用户的研究表面对于学生来说Raft比Paxos更加容易学习Raft还包含一种新的机制用于改变集群的状态，这种机制使用多数重叠来保证安全（這句不是很理解）

一致性算法允许一系列机器作为一相关的一组工作，这组机器即便其中有几台机器异常依然可以达成一致提供正常垺务。因为这些在构建大型可用软件系统中，它扮演了一个重要的角色在过去十年中，关于一致性算法的讨论Paxos占主导地位：大部分┅致性算法的实现是基于Paxos或者被它影响，并且Paxos已经成为了主要媒介物用于教学生学习一致性算法

不幸的是，Paxos仍然难以理解尽管有大量嘚尝试以使它更容易理解。此外它的架构设计要求复杂的改变来支撑实用的系统。导致了一个结果包括系统建设者和学生在理解Paxos的过程中痛苦挣扎。

当我们亲身经历理解Paxos的挣扎后我们着手寻找一个新的一致性算法，这种新的算法可以为系统建设和学习提供一个更好的基础我们的方法是很特别的因为我们的主要目标是这种算法的可理解性：是否我们可以为一个实用系统设计一种一致性算法，并且可以鼡一种比学习Paxos更明显容易的方式来描述它此外，我们想要这个算法来促进一种直觉的发展这种直觉就是这种算法对开发人员是非常必偠的。重要的是不仅是这种算法能起作用更重要的是知道它为什么能起作用。

这项工作的结果是一种称为raft的一致性算法在设计Raft的过程Φ我们应用了特别的技术来提高raft算法的可理解性， 包括分解（Raft把leader选举log复制，安全分解成不同的过程）同时减少中间状态（相对与paxosraft减少叻不确定性的程度和服务器之间互相不一致的方式），一项用户调研在两所大学的43名学生表明相对Paxosraft更容易理解：学习了两种算法以后，這些学生中的33人回答raft 相关的问题比Paxos要更好

Raft 在很多方面和现存的一致性算法很相似，但是它还有几个新奇的特征：

健壮的leader：Raft的leader使用了一种哽强的领导方式相较于其它一致性算法举例，log entry（数据） 只能从leader服务器同步过来这就简化了复制日志的管理，也让Raft更容易理解

Leader选举：Raft使用随机算法来选举leader。对于任何一致性算法1??要求的心跳仅仅增加了少量机制同时可以更加简单和迅速的解决冲突。

成员身份变更：妀变集群中服务器身份的机制使用了一种新联合一致性方法这种方法就是拥有两种不同配置的大多数服务器会重叠在服务器身份改变期間（不太懂，感觉是在身份改变期间依然提供服务但是可能会出现数据不一致）。

这就允许集群在配置更改期间依然可以正常运行

我們相信无论是在教学领域还是作为一个易于可实现的基础，Raft相较于Paxos和其它一致性算法是有优势的相较于其它算法它是简单和更加可以理解的；它被描述的足够完整完全可以满足实用系统的建设需求；它还有很多开源的实现并且很多

公司应在使用它；它的安全性能已经被实鼡证明；其效率也可以和其它算法媲美。

这篇论文的剩余部分介绍了复制状态机问题（第二部分）讨论了Raft的长处和Paxos的弱点（第三部分），描述了我们理解的一般方法（第四部分）介绍了Raft 一致性算法（5-7部分），评估Raft的价值（第八部分）讨论机器之间协同工作（第九部分）。由于篇幅的限制Raft算法很少的一部份被省略了但是可以在扩展的计数报告中找到【29】。这篇额外的扩展材料描述了客户端和系统如何嘚交互Raft 日志如何被回收。

一致性算法通常出现在复制状态机（我的理解是每个机器的状态流转都是一样的比如start开始end结束）的上下文中【33】。用这种方式拥有相同状态的并且在一系列拥有相同算法服务器上的状态机拷贝可以继续正常运行即便其中有其它服务器挂掉。复淛状态机用于解决一系列容错问题在分布式系统中举例，大型系统有一个集群leader比如GFS【7】，HDFS【34】和RAAMCloud【30】，大型系统通常用一个分割的複制状态机来管理leader选举和存储配置信息即便在leader挂掉还能自动恢复运行采用复制状态机中间件还有Chubby【2】和Zookeeper【9】。

图形1:复制状态机架构一致性算法管理一条可复制的日志，这条日志来自客户端的状态机命令每个服务器状态机按日志中的同一种序列处理，所以他们都能产生┅样的结果

复制状态机通常实用一种可复制的日志来实现，像图形1.每个服务器存储一条包含一系列命令的日志服务器上的状态按顺序處理这些日志中的命令。每条日志的命令次序和内容都相同所以每个状态机处理相同的命令序列。由于状态机都是确定的

每个状态机計算相同的状态和相同的输出序列。

（问题：是不是只能leader处理）

保证可复制日志的一致性是一致性算法的任务。在服务器上的共识模块接收来客户端的命令然后把这些命令加到日志中共识模块和其它服务器上的共识模块交互以确保条日志都包含相同顺序的请求，即使一些服务器执行失败了一旦命令被正确复制

，每个服务器的的状态机开始处理这些日志然后返回客户端。结果是这些服务器构成了一個简单，高可用的状态机

实用系统的一致性算法通常有下面几个属性：

• 在所有非拜占庭条件（为什么是非拜占庭条件，意思是如果遇到拜占庭问题就不能解决）下确保系统的安全，这些条件包括网络延迟分区，包丢失系统宕机，和重排序（重排序不是很理解）

• 只要夶部分的服务器可以正常运行并且可以和其它服务器和客户端通信服务就是起作用的（可用的）。因此一个通用的有五个服务器的集群可以容忍其中两台服务器出现问题。假设其中一些服务器由于重启停止服务；它们可以过后很快从

  稳定存储中恢复并加入到集群

• 不能依靠时间来确保这些日志数据的一致性（我的理解是更新时间最近的日志来作为最新的日志）：错误的时钟和极端的消息延迟（我的理解昰：服务器之间时间不一致，消息延迟本来是最新的消息，但是很晚才来到服务器）在最坏的情况下，可以引起可用性问题

• 在通常凊况下，只要这个集群中的大部分机器已经回复一轮远程调用这个命令就已经完成；很少的慢服务器不影响整体系统性能。

过去10年里 Leslie Lamport嘚Paxos协议几乎已经变成一致性算法的代名词：这是一种在课堂上经常教授的协议，大部分一致性算法的实现就是使用它作为起点Paxos 首先定义┅种对一个单个的决策能够达成一致的协议，例如一个单独复制日志

我们指定paxos的子集来作为单一指令。Paxos联合了实现了这个协议的多个实唎来促进一系列决策落地比如日志（大多数-paxos）Paxos既能保证正确又能保证可用，并且它能支持集群中成员状态的改变它已经被证明是正确嘚，在通常情况下它是有效率的

不幸的是，Paxos有两个重大的缺陷第一个缺陷是Paxos特别难理解。完整的解释【13】众所周知不透明；很少有人鈳以成功的理解它并且要付出很大的努力。结果有几种尝试用简单的语言来解释Paxos。这些解释聚焦于独立指令子集

但是仍然很有挑战。在2012 年的顶级学术期刊NSDI一份针对出席者的非正式调查我们发现很少有人 适应Paxos， 尽管其中有经验丰富的研究人员我们在学习Paxos过程非常的掙扎和痛苦；我们不能完全明白整个完整额协议直到阅读了一些简化

版的解释然后设计了我们自己协议，这个过程花了一年的时间

我们假设Paxos的不透明性是来自独立指令子集的选择来作为基础（不明白这句话）。独立指令Paxos是复杂和微妙的：它被分割成两个阶段这个两个阶段没有简单直观的解释并且不能独立理解。由于这些原因很难产生感觉关于独立指令协议如何工作。为mutilPaxos组成规则增加额外的复杂性和微妙性我们相信在多个决策上达成一致的全部问题可以分解成另外几种方式来解决。并且这些方式是直接和清晰的

Paxos的第二个问题是它不能提供一个很好的基础来引导实现。一个原因是 multi-Paxos没有一个广泛认可的算法Lamport的描述是关于Paxos独立指令协议；Lamport勾画了可能的方式来描述mutil-Paxos，但是佷多细节已经丢失了

这里有一些尝试用来充实和优化paxos，例如【23】【35】和【11】但是这些互相不一样和Lamport的设计思想也不一样。像google的Chubby【4】系統已经实现了Paxos-like（我的理解是类似paxos）算法但是大多数情况下这些细节并

此外，Paxos架构是一个糟糕的设计用来建设实用的系统；这是single-decree分解带来嘚另外一个结果举一个例子，选择一系列独立的日志然后合并他们成为一条顺序日志没有任何好处；这只会增加复杂性围绕日志构建┅个系统是简单和高效的

，这里新的entry按到顺序依次叠加另外一个问题Paxos使用一种对等点对点方式通信（服务器之间关系更加平等）方式在咜的核心中（尽管它最终建议为了优化性能降低leader 节点的领导力）。在简化的世界里这很有意义，在这里仅仅只有一个决定将被作出但昰很少的实用系统使用这种方式。如果一系列决策必须作出首先选举一个leader是简单和快速的，然后这个leader来协调这些决策（我的理解是paxos选舉leader过于复杂，不适合对一系列决策作出决定只适合对一个决策作出决定）。

一个结果是：实用系统采用的算法和Paxos相似度很少每个由Paxos开始的实现，发现非常困难去实现它然后设计一个和paxos明显不同的架构。这样就很浪费时间有容易出错并且paxos理解起来非常困难又加剧了问題的严重性。

paxos公式可能是用于证明这个定理正确性很好的公式但是真实的实现和paxos又如此的不同，就显得这个证明没有任何价值下面来洎Chubby的实现者的评论非常典型：

paxos算法的描述和真实世界的需求还有很大的距离...最终的系统可能会基于一个未经验证的协议【4】。

由于这些存茬的问题我们总结出Paxos不能提供一个很好的基础在系统建设和教学中。基于大型软件系统中一致性算法的重要性我们决定是否可以设计┅个相对paxos更好的一致性算法。Raft就是这个实验的结果

设计Raft时我们有几个目标：它必须提供一个为建设系统提供一个完整和实用的基础，以便它可可以显著为开发人员的需求减少设计工作；在所有可能存在异常条件下它必须是安全的在典型的操作条件下它也必须保证可用；茬通常的操作下它

也必须是有效率的。但是我们大多数重要的目标-也是大多数困难的挑战也是容易理解的对于大多数的人可以很舒适的悝解这个算法。此外它必须为开发者产生很好直觉，以至于系统建设者可以实用它来做出一些扩展这些扩展必然适应我们真实的世界。

在设计raft 中有很多要点我们不得不在其中选择可替代的方法（不是太理解，我的理解是设计raft有很多要点不能全部都兼顾，只能选择其Φ几个要点满足）在这些情况下基于可理解性我们评估这些可替代的方法：（它的状态空间有多复杂，

是否有细微的影响），对于一個读者完全明白这个方法和它的含义有多容易

我们认识到这种分析有很高的主观性；尽管如此，我们使用的两个技术是很实用的第一個技术是众所周知的问题分解技术：尽可能，我们把问题分解成可以解决解释，相互独立理解的几部分举例，我们把raft分解成leader选举日誌复制，安全成员身份改变。

第二个方法是简化状态空间依靠减少要考虑的状态数量确保系统的连贯性并且减少系统的不确定性。特別强调日志不允许有漏洞存在，并且Raft限制了这些方式就是防止logs变得互相不一致（我的理解所有服务器的日志结构都是一样的）

，尽管茬大多数情况下我们尝试减少不确定性可是在一些情况中不确定性事实上提高了可理解性（这句不太理解）。 特别是随机方式产生了不確定性（随机方式指的leader的产生是随机的）但是他们倾向于依靠用相似的方式处理所有可能的选择

来减少中间状态（不太理解）（任何选擇，都没关系是不是任何节点做leader都没关系，所有的节点的处理都是一样的）。我们实用随机来简化Raft的leader选举算法（这句话应该是这段話的精髓）。

Raft是一种用于管理可复制的表格日志算法在第二节中有描述。图二实用简介的形式总结了这个算法用于参考图三列出了这個算法的所有关键属性；这些图的元素在余下的章节中分段讨论。

Raft一致性算法实现依靠首选选举一个杰出的leader赋予leader管理可复制日志的全部責任。这个leader接收来客户端的请求日志然后复制这些日志到其它服务器上，然后告诉这些服务器什么时候可以安全的把这些日志应用于它們的状态机

拥有一个leader简化了可复制日志的管理。举例这个leader可以决定在日志中在哪里放这个新的数据而不用考虑其它服务器，然后数据鼡一中简单的方式从leader流向其它服务器leader可能宕机或者和其它服务器网络不通，在这种情况下一个

新的leader将会被选举出来

在考虑这种leader方式中，Raft把一致性问题分解成三个相互独立的子问题这些子问题在下面讨论：

leader选举：当一个存在的leader失败宕机了，一个新的leader才会被选举出来 （在5.2節中）

日志复制：这个leader必须接收来客户端的日志数据然后复制到集群中的其它服务器，强制其它服务器上的日志同意接收（5.3节）

安全：Raft關键的安全属性是这个状态机属性在图三中：如果任何服务器接收了一个具体的日志数据到它的状态机就不可能有其它服务器在同一条ㄖ志索引中接收一个不同的的日志数据。章节5.4中描述了Raft如何确保这个属性；问题解决方案

涉及一个额外的限制关于选举机制在5.2章节有描述。

图形2:一个Raft一致性算法的简要摘要（不包括成员状态变更和日志压缩）左上角框中的服务器行为被描述为一组规则，这些规则独立且重复触发5.2章节指出特萣功能被讨论的位置。正式规范[28]更精确地描述了该算法

图形三：Raft保证每个属性的值在任何时候都是true。每个属性在指定的章节进行讨论

茬图形3中的安全属性：如果任何一个服务器节点接收了一个特定的log entry 到它的状态机，其它服务器就不会在日志集合中同一个索引位置接收一個不同的命令5.4章节描述了Raft如何确保

这个属性；关于选举机制解决方案还额外涉及一个限制在5.2章节中有描述。

在呈现一致性算法后这个嶂节讨论可用性问题和系统中的时间扮演一个什么角色。

一个raft集群包含一系列服务器；5是一个典型的数字它允许系统可以容忍两个服务器宕机。在任何时间每个服务器只会是三个状态中的一个（领导跟随者，或者候选者）在正常的情况下，集群中仅仅只有一个leader其它服務器就是跟随者这些跟随者自己不发出请求但是他们回复来自leader和候选人的请求。这个领导者处理所有的客户端请求（如果一个客户端服務和一个跟随连接发出请求，这个跟随者会转发这个请求给leader）第三种状态，候选者被用于选举一个新的leader会在4.2章节中被描述。图形四展示了这些状态和状态之间的转移；状态之间的转移会在下面讨论

Raft把时间拆分成任意长度的项，在图形5有描述这些项由连续的整数数芓构成。每个项开始于一次选举在这次选举中一个或者多个候选者尝试变成leader在5.2章节中描述。如果一个候选者赢得了这次选举它就会在餘下的项中作为leader。在有有些情况一场选举会在一个分裂的投票中产生结果在这中情况下这期选举不会产生leader；会开始一场新的选举。Raft保证朂多只有一个leader在一期选举中

图形四：服务器状态。跟随者仅仅回复来自其它服务器的请求如果一个跟随者没有收到通讯信息，它就会變成一个候选者然后初始化一轮选举一个候选者收到集群中大部分服务器的选票就会变成一个leader。领导者通常运行到他们失败

图形5:时间被分割程多个轮次，每个轮次从一个选举开始在一次成功的选举后，一个单个的leader管理这个集群一直到这个轮次的结束有一些选举失败嘚场景，在这种情况下的轮次结束时不会选举出一个leader轮次之间的转移可以在不同的服务器不同的时间被观察到。

不同的服务器在不同的時间可以观察到轮次之间的转移在一些情况种，一个服务器可能没有观察到一次选举或者整个选举的轮次图形四：服务器状态。Followers 仅仅囙答来自其他服务器的请求

如果一个follower没有收到通讯，这个follower就会变成一个候选人然后开始一轮选举一个候选者如果收到其他服务器的大蔀分选票就会在这个集群种变成一个leader。Leaders通常运行到他们失败

图形5:时间被分割程多个轮次，每个轮次从一个选举开始在一次成功的选举後，一个单个的leader管理这个集群一直到这个轮次的结束有一些选举失败的场景，在这种情况下的轮次结束时不会选举出一个leader轮次之间的轉移可以在不同的服务器不同的时间被观察到。

act在raft中扮演一个逻辑时钟它们允许服务器检查过时的信息例如过时的leader。每个服务器保存一個当前的term随着时间的推移自动增加。每当服务器通讯Current terms 进行替换；如果一个服务器的当前term小于其他服务器，它就会把当前的term更新成其他垺务器的term如果一个候选者或者leader发现它的term过时了，它会立即变成fllower状态如果一个服务器收到的请求中是一个过时的term，它会拒绝这次请求

Raft垺务器远程通讯，一致性算法仅仅要求两种类型的远程调用请求选票远程调用被候选者发起在选举期间（5.2节），AppendEntries 远程调用被leader发起用于复淛日志entries和提供心跳的形式（

5.3节）服务节点如果在一个时钟周期没有收到回复会重试，它们并行远程调用以获得最佳的性能

5.2 leader选举 Raft使用一種心跳机制来触发leader选举。当服务节点启动它们的状态是follower。一个服务节点保持follower状态直到它收到来自leader或者candidate的远程调用leader周期性的

发送心跳给所有的follower是来保持它的权威性。如果一个follower在一个周期中没有收到通信请求它就会假设这里没有可用的leader，然后开始一轮选举来选择一个新的leader

为了开始一轮选举，follower增加它的轮次然后变成candidate状态它先选择自己然后并行发出选举请求给集群中的所有的服务节点。一个candidate继续保持它的狀态直到下面三种情形的一种发生：

b：其它服务器节点确认它作为leader

c：一个周期过去没有胜出者

这些结果将在下面段落中单独讨论。

如果┅个候选者在同一个选举轮次中赢得了集群中服务节点的大部分选票它就赢到了这次选举成为leader每个服务节点在给定轮次中最多选举一名candidate，按先到先得的原则（note：5.4节加了

额外的限制关于选票）大多数确保最多只有一名candidate赢得这次选举在制定的选举轮次中（图形三选举安全属性）。一旦一个candidate赢得了这次选举它就变成leader。然后它就会发送心跳

消息给所有其它服务节点来确保它的权威性阻止新的选举

第三个可能嘚结果是这个candidate既没有赢得选举也没有输掉选举：如果许多followers在同一时间变成candidate，选票就可能被分散以至于没有candidate获得大多数选票在这种情况发苼时，

每个candidate会超时然后开始一轮新的选举依靠增加选举的轮次和启动另外一轮远程选举然后，没有额外措施选票分散可能导致选举无限期举行。

Raft使用随机的选举超时来确保选票分散是很少发生并且可以快速解决为了防止选票分散，首先选举超时时间设置在一个时间區间的随机数据（比如 150-300ms之间随机）。这扩散到其它服务器

以至于在大多数情况下仅仅只有一台服务器会超时；它赢得这次选举然后在其它垺务器超时之前发送心跳同样的机制用于处理选票分散。每个candidate重新设置它的随机超时时间在选举开始的时候并且等到超时时间过去后財开始下一次选举；这样减小了在新一轮选举中票据分散的可能性。8.3节展示了 快速选举一个leader的方法

选举是一个在不同设计中指导我们选擇可理解的一个举例。最初我们计划使用一个排名系统：每个candidate被分配了一个唯一的排名这个排名用于在竞争的candidate之间进行选择。如果一个candidate發现其它candidate拥有更高的排名它就会返回follower状态以至于拥有更高排名的candidate可以轻而易举的赢得选举。我们发现这个方法导致一些细微的问题在可鼡性方面（如果级别较高的服务器发生故障级别较低的服务器则可能由于超时而再次变成一个候选者但是如果发生得太快，它会重置选舉leader的进度）对这个算发我们做了很多调整，但是每次调整后新的异常情况又会发生最终我们得出结论随机重试方法更加的明显和易于悝解。

图形6:Logs由一系列entry构成并且顺序编号。每个entry包含轮次（box中数字）和状态机的命令如果entry可以安全的适应状态机，这个entry才可以提交

一旦一个leader被选举成功，这个集群才开始对外服务每个客户端请求包含一个可以被可复制状态机执行的命令。这个leader把这个命令封装成一个新嘚entry来追加到他的log中然后对其它服务节点并行发出复制entry的请求。当这个entry安全的被其它服务节点复制完成以后这个leader再把这个entry适配到自己的狀态机最后再向客户端返回调用结果。如果followers崩溃或者运行缓慢又或者网络数据丢失，这个leader会无限重试追加entry远程调用（尽管它已经回复了愙户端）直到所有的follower完全存储了所有的log entry 问题：如果网络超时，数据丢包给客户端返回成功还是失败？

图形6展示了logs的机构当entry被leader收到，烸个log entry存储了一个状态机命令伴随轮次编号一起log entry中轮次用于检查logs中冲突并保留一些属性（图形三）。每个log entry都要一个整形数字标识在log中的位置

leader决定什么时候可以安全的把log entry应用于状态机；这样的entry被称为已提交。Raft保证被提交的entry是持久化的并且最终会被所有可用的状态机执行一旦创建了entry的leader已经复制entry到大部分其它服务节点，这个log entry就是已提交状态（比如 图形6中entry 7）这个leader还会提交log中先前entry，包括被其它leader创建的entry5.4节讨论了茬leader改变后，应用规则时的一些细微之处它还展示了提交的定义是安全。leader跟踪被提交的log entry的最大索引log index并且还包含以后远程调用的index以至于其咜服务器完全可以发现。一旦一个follower学习了log entry被提交它就会应用这个entry到本地状态机。

我们设计raft log机制来保持不同服务器之间log数据的强一致性鈈仅仅是简化系统的行为并且让它可预测，并且它是确保安全的重要组成部分raft维护下面这些属性，它们共同构成了图形三中log

如果在不同logΦ的两个entry有同样的index和轮次则它们存储的数据也是一样的。

如果在不同log中的两个entry有同样的index和轮次则这个entry的先前entries也是相同的。

第一个属性形成了一个事实一个leader在相同log index和轮次的条件下最多只会创建一个entry并且log entry永远不会改变它在log的位置index。第二个属性保证由AppendEntries执行简单的一致性检查來保证当发起了一项AppendEntries RPC，在log中包含index和轮次的entry会立即优先于新的entry。如果这个follower 在它的日志log中没有发现一个有相同index和term的entry它就拒绝这个新的entry （鈈理解？）一致性检查作为一个归纳步骤：初始化的日志空状态满足log matching属性，当日志扩展一致性检查保留log matching属性结果，当AppendEntries返回成功leader就知噵

在正常运行期间，leader和followers的log是保持一致的所以AppendEntries一致性检查不会失败。然后leader崩溃能导致失去log的一致性（旧的leader没有把log的entry完全复制到其它服务節点）。这些不一致会加剧一系列的leader和followers崩溃图形7说明follower的日志不同于新leader的方式。一个follower可能丢失entry而这些entry存在于leader上，还可能存在额外的entry而這些entry在leader上并不存在，或者两者皆有丢失和多出entry在一个log中可能跨越多个轮次。

5.4节将展示再加上一个或多个限制条件这就是非常安全的。

兩者都存在（e-f）举例，如果f这个服务器是第二轮选举的leader（term=2）然后接收了一系列entry到它的log，提交这些entry之前崩溃了；但是很快重启恢复并洅次成为了第三轮选举的leader，并再次接收客户端的请求；在第二轮和第三轮接收的日志entry提交之前再一次崩溃，并在其后的选举中不再参与選举就成为f这样的情况

为了让follower的日志和leader的日志保持一致，leader必须找到和follower日志一样最新位置然后删除掉follower log中这个点以后的日志，然后发送leader log这個位置以后所有的日志到follower

log一致的点。当这种情况发生AppendEntries就成功了，它会删出follower这个点以后冲突的entry然后追加上leader log中这个点以后的日志。一旦AppendEntries荿功follower和leader的日志就达到了一致性，它会保持这个方式到后来的选举轮次

这个协议被优化用于减少AppendEntries rpc调用的拒绝数量，详情见【29】

依靠这種机制，leader不需要采取任何特被的动作来恢复日志的一致性当leader启动时它仅仅需要正常启动，并且在回复AppendEntries 一致性检查失败中日志会自动汇匼。一个leader永远不会覆盖或者删除它的日志（图形三中leader append-only 属性）

日志复制机制展示了理想的一致性属性在第二节中有这样的描述：Raft可以接收，复制并且应用新的log entry，只要大部分的服务器在运行状态；在通常情况下一个新的entry可以在一轮RPC调用中复制到其它大部分服务器；并且一个慢的follower不会影响性能

前面的章节描述了raft怎样选举leader和复制log。然而目前位置这个机制还不能够确保每个状态机以相同的顺序执行同样的命令。举例当leader提交一系列log entry时一个follower变得不可用，然后它被选举成leader然后用新的entry覆盖了这些entry；结果就导致，不同的状态机可能执行不同的命令序列

这节完善了raft算法依靠添加了一个限制，这个限制制约了那些服务器可以被选举成leader这个限制确保选举出的leader包含以前所有轮次中提交的entry（the Leader Completeness 属性来源于图形三）。给定选举限制我们让提交的规则更加的完善和准备。最终我们呈现了一个证明草图关于 Leader Completeness属性，然后展示了它洳何导致复制状态机的正确行为

在任何基于leader的一致性算法中，leader最终必须存储所有的提交log entries在一些一致性算法中，例如 Viewstamped 复制【20】一个leader可鉯被选举即使这个leader最初没有包含所有被提交的enties。这些算法包含其它机制来鉴别丢失的entries然后转移entries到新的leader中在选举过程中或者过后不久。不圉的是结果要考虑大量的额外机制和复杂性。Raft使用了一个简单的方式来保证所有来自以前轮次提交的entries都存在在新的leader选举出来的这一时刻。不需要转移entiries到这个新的leader这意味者log

Raft使用投票程序来防止一个候选者赢得一次选举，除非它的logs包含所有已经提交的entries一个候选者必须和夶部分服务保持通信才有机会被选上当leader，意味着每条被提交的entry必须存在于这些服务器中一个如果一个候选者的log至少和其它服务器最新log一樣最新，然后它就会保存所有的提交entries投票选举RPC实现了这个限制：这个PRC包含候选人的log信息，如果投票者自己的日志比候选人的log要新则投票者拒绝投票。

Raft通过比较index和term来确定两个logs哪一个是最新的如果logs中最后一条entry拥有不同term，更大的term是更新的如果logs中term是相同的，则更长的log是更新嘚

图形8:一个时间序列展示了为什么一个leader不能确定提交点用老的轮次的log entries。

（b）中 s1崩溃；s5被选举成第三轮中的leader通过s3，s4和它自己的选票然後接收了一个不同的entry，在log index2.

（c）中s5崩溃；s1恢复并被重新选举成leader，然后继续复制entry在这时间点，来自第二轮选举接收的entry已经被复制到大部分嘚服务节点但是还没有提交。

如果s1崩溃在（d）中s5可能再次被选举成leader（来自s2，s3s4的选票），然后就会使用它自己的第三轮的entry去覆盖其它節点的entry

然而，如果s1在崩溃前复制了一个entry到大部分的服务器上，例如（e）中然后这个entry被提交了（s5就不会赢得这次选举）。所有以前提茭的entry都可以正常提交

在5.3节中有描述，一个leader知道一个来自当前term的entry一旦被提交这个entry就保存到大部分的服务器上。如果一个leader在提交一个entry之前崩溃了未来的leader会尝试完成复制这个entry。然而一个leader不能立刻断定一个来自以前轮次的entry一旦被提交，它就会立刻被存储到大部分的服务器上图形8说明了一种情形一个老的entry被存储到大部分的服务器上，依然可以被未来的leader覆盖

为了消除在图形8中的一个问题，raft不会依靠计算副本嘚数量来提交来自以前轮次的log entries仅仅来自leader当前轮次的entry依靠计算副本数量来提交；一旦来自当前轮次的entry被提交，所以以前的entry也被间接提交這里有一些情形leader可以安全的下结论一个老的log entry一旦被提交（举例，如果这个entry被保存到每个服务器上）但是raft采用了一个更保守的方式来简化。

使用这样的提交规则raft导致了浴血额外的复杂性因为当leader复制以前轮次的entries时log entry保留了以前的轮次编号在其它一致性算法中，如果一个新的leader复淛以前轮次的entry它必须使用新的轮次编号。raft的方法更加的合理和容易

因为它们随着时间的推移保持相同的轮次编号。另外在raft中新的leader发送更少的来自以前轮次的log entry相比其它一致性算法（其它一致性算法必须发送多余的log entry来重新设置number在它们可以被提交前）。

图形9: 如果s1提交了一个噺的entry在它的轮次中然后s5在轮次u中被选举成leader，然后这里必须有一台接收了轮次t的log entry来给s5投递选票