《In Search of an Understandable Consensus Algorithm》论文阅读

前言

一致性算法Raft,久闻大名，今天拜读一下论文。
论文地址：link
一致性算法支撑了大规模可靠软件系统，Paxos是主导算法，但是它太难理解。raft是简化版的Paxos。raft有几个主要部分：领导选举/日志复制/安全性。

raft的特性有

• 强领导者（Strong Leader）：Raft 使用一种比其他算法更强的领导形式。例如，日志条目只从领导者发送向其他服务器。这样就简化了对日志复制的管理，使得 Raft 更易于理解。

• 领导选取（Leader Selection）：Raft 使用随机定时器来选取领导者。这种方式仅仅是在所有算法都需要实现的心跳机制上增加了一点变化，它使得在解决冲突时更简单和快速。

• 成员变化（Membership Change）：Raft 为了调整集群中成员关系使用了新的联合一致性（joint consensus）的方法，这种方法中大多数不同配置的机器在转换关系的时候会交迭（overlap）。这使得在配置改变的时候，集群能够继续操作。

1.复制状态机

一致性算法是在复制状态机的背景下提出来的。在这个方法中，在一组服务器的状态机产生同样的状态的副本因此即使有一些服务器崩溃了这组服务器也还能继续执行。复制状态机在分布式系统中被用于解决许多有关容错的问题。例如，GFS，HDFS还有 RAMCloud 这些大规模的系统都是用一个单独的集群领导者，使用一个单独的复制状态机来进行领导选取和存储配置信息来应对领导者的崩溃。使用复制状态机的例子有 Chubby 和 ZooKeeper。

2.Raft算法概述

2.1 state

(响应rpc之前稳定存储的)

• currentTerm 服务器最后知道的任期号
• votedFor 在当前任期内收到选票的candidateId
• log[] 状态机的命令和从leader收到的任期号

(不稳定存在的)

• commitIndex 已知被提交的最大日志条目索引(从0递增)
• lastApplied 被状态机执行的最大日志索引(从0递增)

(在leader上不稳定存在的，选举之后初始化的)

• nextIndex[] 对于每一个服务器，记录需要发给他的下一个日志条目索引(初始化为leader上一条日志的索引值+1)
• matchIndex[] 对于每一个服务器，记录已经复制到改服务器日志的最高索引值(从0递增)

2.2 日志远程append的rpc

leader复制日志，也用于心跳

(参数)

• term leader任期
• leaderId leaderid
• prevLogIndex 最新日志之前的索引值
• prevLogTerm 最新日志之前的leaderId
• entries[] 要存储的日志条目(表示heartbeat时候为空)
• leaderCommit leader提交的日志条目索引

(返回值)

• term 当前任期号
• success 当其他服务器prevLogIndex 和 prevLogTerm 的日志对的上时为true

(接收者实现的方法)

• 如果接收到的term < currentTerm，返回false
• prevLogIndex位置的日志记载的任期号和prevLogTerm不匹配，返回false
• 已存在的日志与新的冲突(index相同，任期不同)，则删除已经存在日志后面所有节点
• 已存在日志没有就添加
• 如果leaderCommit > commitIndex 将commitIndex设为（commitIndex和最新日志索引）中最小的一个

2.3 投票请求的rpc

(参数)

• term candidate的任期号
• candidateId 候选人id
• lastLogIndex 候选人最新日志条目索引
• lastLogTerm 候选人最新条目对应的任期号

(返回值)

• term 目前任期号，用于candidate更新自己

• voteGranted 如果候选人收到选票就是true

(接收者实现的方法)

• 如果接收到的term < currentTerm，返回false
• 如果votedFor为空或者与candidateId相同，并且候选人的日志和自己的日志一样新，则给candidate投票（5.2节 和 5.4节）

2.4 服务器的规则

(all)

• 如果commitIndex > lastApplied，lastApplied自增，将log[lastApplied]应用到状态机

• 如果 RPC 的请求或者响应中包含一个 term T 大于自己已知的currentTerm，则currentTerm = T，并切换状态为追随者（Follower）

(follower)

• 响应leader和candidate的rpc

• 如果在超过选取某个时间之前没有收到来自当前leader的AppendEntries RPC或者没有收到候选人的投票请求，则自己转换状态为候选人

(candidate)

• 如果收到超过半数的投票，成为leader
• 如果收到新的leader的rpc,变成follower
• 选举超时就开始新一轮选举
• 转变成candidate后 currentTerm自增，给自己投票，重置选举计时器，向其他server发起投票请求的rpc

(leader)

• 一旦成为leader：向其他所有服务器发送空的AppendEntries RPC（heartbeat）;在空闲时间重复发送以防止选举超时
• 收到客户端的请求后，向本地增加日志，应用到状态机后响应客户
• 对于follower，上一次收到的日志索引 > nextIndex,通过AppendEntries RPC将 nextIndex 之后的所有日志条目发送出去,成功的话更新将follower的 nextIndex和matchIndex，如果由于日志不一致导致AppendEntries RPC失败：nextIndex递减并且重新发送
• 如果存在一个满足N > commitIndex和matchIndex[i] >= N并且log[N].term == currentTerm的 N，则将commitIndex赋值为 N

Raft 算法保证这些特性任何时刻都成立

性质 描述
选举安全原则（Election Safety） 一个任期（term）内最多允许有一个leader被选上
leader只增加原则（Leader Append-Only） leader永远不会覆盖或者删除自己的日志，它只会增加条目
日志匹配原则（Log Matching） 如果两个日志在相同的索引位置上的日志条目的任期号相同，那么我们就认为这个日志从头到这个索引位置之间的条目完全相同
leader完全原则（Leader Completeness) 如果一个日志条目在一个给定任期内被提交，那么这个条目一定会出现在所有任期号更大的leader中
状态机安全原则（State Machine Safety） 如果一个服务器已经将给定索引位置的日志条目应用到状态机中，则所有其他服务器不会在该索引位置应用不同的条目

因此 raft 将一致性问题分成了三个问题

leader选取（Leader election）： 在一个leader宕机之后必须要选取一个新的leader
日志复制（Log replication）： leader必须从客户端接收日志然后复制到集群中的其他服务器，并且强制要求其他服务器的日志保持和自己相同
安全性（Safety）： Raft 的关键的安全特性是状态机安全原则（State Machine Safety）:如果一个服务器已经将给定索引位置的日志条目应用到状态机中，则所有其他服务器不会在该索引位置应用不同的条目。

3.Raft算法基础

3.1 任期

如果raft集群有五台机器，那么能容忍2台机器失效。机器是三种角色中的一种：leader, follower,candidate

如下的三个角色的转换，里面的转换条件在上面其实都写过

任期时间线示意，每个任期开始都是领导选举，然后是管理集群。如果选举失败，该任期就会因为没有领带人而结束。

任期在 Raft 中充当逻辑时钟的角色，并且它们允许服务器检测过期的信息，比如过时的领导人。每一台服务器都存储着一个当前任期的数字，这个数字会单调的增加。当服务器之间进行通信时，会互相交换当前任期号；如果一台服务器的当前任期号比其它服务器的小，则更新为较大的任期号。如果一个候选人或者领导人意识到它的任期号过时了，它会立刻转换为追随者状态。如果一台服务器收到的请求的任期号是过时的，那么它会拒绝此次请求。Raft 中的服务器通过远程过程调用（RPC）来通信，基本的 Raft 一致性算法仅需要 2 种 RPC。RequestVote RPC 是候选人在选举过程中触发的（5.2节），AppendEntries RPC 是leader触发的，为的是复制日志条目和提供一种心跳（heartbeat）机制。

3.2 leader选举细节

raft用心跳出发选举。当服务器启动时会初始化为follower。只要它们能够收到来自leader或者candidate的有效 RPC，服务器会一直保持follower的状态。leader会向所有follower周期性发送心跳（heartbeat，不带有任何日志条目的 AppendEntries RPC）来保证leader地位。如果一个追随者在一个周期内没有收到心跳信息，就叫做选举超时（election timeout）,然后它就会假定没有可用的领导人并且开始一次选举来选出一个新的leader。

为了开始选举，follower会自增它的当前任期并且转换状态为candidate，给自己投票并且给集群中的其他服务器发送 RequestVote RPC。一个候选人会一直处于该状态，直到下列三种情形之一发生：

• 赢得了选举；
• 另一台服务器赢得了选举；
• 一段时间后没有任何一台服务器赢得了选举

(赢得了选举)
一个candidate在任期内收到了来自集群中大多数服务器的投票就会赢得选举。然后它会像其他服务器发送心跳信息来建立自己的领导地位并且阻止新的选举。

（另一台服务器宣称胜选）
当一个candidate等待别人的选票时，它有可能会收到来自其他服务器发来的声明其为领导人的 AppendEntries RPC。如果这个领导人的任期（包含在它的 RPC 中）比当前候选人的当前任期要大，则候选人认为该领导人合法，并且转换自己的状态为追随者。如果在这个 RPC 中的任期小于候选人的当前任期，则候选人会拒绝此次 RPC， 继续保持候选人状态。

(一段时间后没有任何一台服务器赢得了选举)
如果许多追随者在同一时刻都成为了候选人，选票会被分散，可能没有候选人能获得大多数的选票。当这种情形发生时，每一个候选人都会超时，并且通过自增任期号和发起另一轮 RequestVote RPC 来开始新的选举。然而，如果没有其它手段来分配选票的话，这种情形可能会无限的重复下去。Raft 使用随机的选举超时时间来确保这情况很少发生，并且能够快速解决。为了防止在一开始是选票就被瓜分，选举超时时间是在一个固定的间隔内随机出来的（例如，150~300ms）。这种机制使得在大多数情况下只有一个服务器会率先超时，它会在其它服务器超时之前赢得选举并且向其它服务器发送心跳信息。

3.3 日志复制细节

一旦选出了leader，它就开始接收客户端的请求。每一个客户端请求都包含一条需要被复制状态机执行的命令。领导人把这条命令作为新的日志条目加入到它的日志中去，然后并行的向其他服务器发起 AppendEntries RPC ，要求其它服务器复制这个条目。当这个条目被安全的复制之后（下面会讲），leader会将这个条目应用到它的状态机中并且会向客户端返回执行结果。如果follower崩溃了或者运行缓慢或者是网络丢包了，leader会无限的重试 AppendEntries RPC（甚至在它向客户端响应之后）直到所有follower最终存储了所有的日志条目。

下图展示了日志的组成，每个日志条目存储着一条被状态机执行的命令和当这条日志条目被领导人接收时的任期号。日志条目中的任期号用来检测在不同服务器上日志的不一致性，每个日志条目也包含一个整数索引来表示它在日志中的位置。

leader来决定什么时候把日志条目应用到状态机中是安全的；这种日志条目被称为已提交。Raft 算法保证所有已提交的日志条目都是持久化的并且最终会被所有可用的状态机执行。在leader将创建的日志条目复制到大多数的服务器上的时候，日志条目就会被提交（例如在图中的条目 7）。同时，leader的日志中之前的所有日志条目也都会被提交，包括由其他leader创建的条目。leader跟踪了最大的将会被提交的日志项的索引，并且索引值会被包含在未来的所有附加日志 RPCs （包括心跳包），这样其他的服务器才能最终知道leader的提交位置。一旦跟随者知道一条日志条目已经被提交，那么他也会将这个日志条目应用到本地的状态机中（按照日志的顺序）。

日志匹配机制的特性

• 如果在不同的日志中的两个条目拥有相同的索引和任期号，那么他们存储了相同的指令。
• 如果在不同的日志中的两个条目拥有相同的索引和任期号，那么他们之前的所有日志条目也全部相同。

第一个特性是因为leader最多在一个任期里在指定的一个日志索引位置创建一条日志条目，同时日志条目在日志中的位置也从来不会改变。

第二个特性由附加日志 RPC 的一个简单的一致性检查所保证。在发送附加日志 RPC 的时候，领导人会把新的日志条目紧接着之前的条目的索引位置和任期号包含在里面。如果follower在它的日志中找不到包含相同索引位置和任期号的条目，那么他就会拒绝接收新的日志条目。一致性检查就像一个归纳步骤：一开始空的日志状态肯定是满足日志匹配特性的，然后一致性检查保护了日志匹配特性当日志扩展的时候。因此，每当附加日志 RPC 返回成功时，leader就知道follower的日志一定是和自己相同的了。在正常的操作中，leader和follower的日志保持一致性，所以附加日志 RPC 的一致性检查从来不会失败。然而，leader崩溃的情况会使得日志处于不一致的状态（老的leader可能还没有完全复制所有的日志条目）。这种不一致问题会在leader和follower的一系列崩溃下加剧。

下图展示了follower的日志可能和新的leader不同的方式。follower可能会丢失一些在新的leader中有的日志条目，他也可能拥有一些leader没有的日志条目，或者两者都发生。每一个盒子表示是一个日志条目；里面的数字表示任期号。

a,b缺失日志
c,d存在未被提交的日志
e,f 存在缺失日志，还有未被提交的日志

f属于病入膏肓了：在任期 2 的时候是leader，已附加了一些日志条目到自己的日志中，但在提交之前就崩溃了；很快这个机器就被重启了，在任期 3 重新被选为leader，并且又增加了一些日志条目到自己的日志中；在任期 2 和任期 3 的日志被提交之前，这个服务器又宕机了，并且在接下来的几个任期里一直处于宕机状态

在 Raft 算法中，leader处理不一致是通过强制follower直接复制自己的日志来解决了。这意味着在follower中的冲突的日志条目会被leader的日志覆盖。要使得follower的日志进入和自己一致的状态，leader必须找到最后两者达成一致的地方，然后删除从那个点之后的所有日志条目，发送自己的日志给follower。所有的这些操作都在进行附加日志 RPCs 的一致性检查时完成。leader针对每一个follower维护了一个 nextIndex，这表示下一个需要发送给follower的日志条目的索引地址。当一个leader刚获得权力的时候，他初始化所有的 nextIndex 值为自己的最后一条日志的 index 加 1。如果一个follower的日志和leader不一致，那么在下一次的附加日志 RPC 时的一致性检查就会失败。在被follower拒绝之后，领导人就会减小 nextIndex 值并进行重试。最终 nextIndex 会在某个位置使得领导人和跟随者的日志达成一致。当这种情况发生，附加日志 RPC 就会成功，这时就会把follower冲突的日志条目全部删除并且加上leader的日志。一旦附加日志 RPC 成功，那么跟随者的日志就会和领导人保持一致，并且在接下来的任期里一直继续保持。

通过这种机制，leader 在获得权力的时候就不需要任何特殊的操作来恢复一致性。他只需要进行正常的操作，然后日志就能自动的在回复附加日志 RPC 的一致性检查失败的时候自动趋于一致。leader从来不会覆盖或者删除自己的日志。在通常的情况下，新的日志条目可以在一次 RPC 中被复制给集群中的大多数机器；并且单个的缓慢的跟随者不会影响整体的性能。

3.4 安全性细节

前面的章节里描述了 Raft 算法是如何选举和复制日志的。然而，到目前为止描述的机制并不能充分的保证每一个状态机会按照相同的顺序执行相同的指令。例如，一个follower可能会进入不可用状态同时领导人已经提交了若干的日志条目，然后这个follower可能会被选举为leader并且覆盖这些日志条目；因此，不同的状态机可能会执行不同的指令序列。

所以在领导选举的时候增加一些限制来完善 Raft 算法。这一限制保证了任何的leader对于给定的任期号，都拥有了之前任期的所有被提交的日志条目。

3.4.1 选举限制

leader必须存储所有已经提交的日志条目。Raft 使用了一种更加简单的方法，它可以保证所有之前的任期号中已经提交的日志条目在选举的时候都会出现在新的领导人中，不需要传送这些日志条目给leader。这意味着日志条目的传送是单向的，只从leader传给跟随者，并且leader从不会覆盖自身本地日志中已经存在的条目。

Raft 使用投票的方式来阻止一个candidate赢得选举，除非这个candidate包含了所有已经提交的日志条目。candidate为了赢得选举必须联系集群中的大部分节点，这意味着每一个已经提交的日志条目在这些服务器节点中肯定存在于至少一个节点上。如果candidate的日志至少和大多数的服务器节点一样新，那么他一定持有了所有已经提交的日志条目。请求投票 RPC 实现了这样的限制：RPC 中包含了candidate的日志信息，然后投票人会拒绝掉那些日志没有自己新的投票请求。Raft 通过比较两份日志中最后一条日志条目的索引值和任期号定义谁的日志比较新。如果两份日志最后的条目的任期号不同，那么任期号大的日志更加新。如果两份日志最后的条目任期号相同，那么日志比较长的那个就更加新。

3.4.2 提交之前任期内的日志条目

如果一个leader在提交日志条目之前崩溃了，未来后续的leader会继续尝试复制这条日志记录。然而，一个领导人不能断定一个之前任期里的日志条目被保存到大多数服务器上的时候就一定已经提交了。图 8 展示了一种情况，一条已经被存储到大多数节点上的老日志条目，也依然有可能会被未来的领导人覆盖掉。

下图的时间序列展示了为什么leader无法决定对老任期号的日志条目进行提交。在 (a) 中，S1 是领导者，部分的(跟随者)复制了索引位置 2 的日志条目。在 (b) 中，S1 崩溃了，然后 S5 在任期 3 里通过 S3、S4 和自己的选票赢得选举，然后从客户端接收了一条不一样的日志条目放在了索引 2 处。然后到 ©，S5 又崩溃了；S1 重新启动，选举成功，开始复制日志。在这时，来自任期 2 的那条日志已经被复制到了集群中的大多数机器上，但是还没有被提交。如果 S1 在 (d) 中又崩溃了，S5 可以重新被选举成功（通过来自 S2，S3 和 S4 的选票），然后覆盖了他们在索引 2 处的日志。反之，如果在崩溃之前，S1 把自己主导的新任期里产生的日志条目复制到了大多数机器上，就如 (e) 中那样，那么在后面任期里面这些新的日志条目就会被提交（因为 S5 就不可能选举成功）。 这样在同一时刻就同时保证了，之前的所有老的日志条目就会被提交。

为了防止上图现象出现，Raft 永远不会通过计算副本数目的方式去提交一个之前任期内的日志条目。只有leader当前任期里的日志条目通过计算副本数目可以被提交；一旦当前任期的日志条目以这种方式被提交，那么由于日志匹配特性，之前的日志条目也都会被间接的提交。在某些情况下，leader可以安全的知道一个老的日志条目是否已经被提交（例如，该条目是否存储到所有服务器上），但是 Raft 为了简化问题使用一种更加保守的方法。

当leader复制之前任期里的日志时，Raft 会为所有日志保留原始的任期号, 这在提交规则上产生了额外的复杂性。Raft 使用的方法更加容易辨别出日志，因为它可以随着时间和日志的变化对日志维护着同一个任期编号。另外，和其他的算法相比，Raft 中的新leader只需要发送更少日志条目（其他算法中必须在他们被提交之前发送更多的冗余日志条目来为他们重新编号）

3.4.3 安全性论证

假设任期 T 的leader（leader T）在任期内提交了一条日志条目，但是这条日志条目没有被存储到未来某个任期的leader的日志中。设大于 T 的最小任期 U 的leader U 没有这条日志条目。

下图所示，如果 S1 （任期 T 的leader）提交了一条新的日志在它的任期里，然后 S5 在之后的任期 U 里被选举为leader，然后至少会有一个机器，如 S3，既拥有来自 S1 的日志，也给 S5 投票了。

1. 在leader U 选举的时候一定没有那条被提交的日志条目。
2. leader T 复制这条日志条目给集群中的大多数节点，同时，leader U 从集群中的大多数节点赢得了选票。因此，至少有一个节点同时接受了来自leader T 的日志条目，并且给leader U 投票了，这个投票者是产生这个矛盾的关键。
3. 这个投票者必须在给leader U 投票之前先接受了从leader T 发来的已经被提交的日志条目；否则他就会拒绝来自leader T 的附加日志请求（因为此时他的任期号会比 T 大）。
4. 投票者在给leader U 投票时依然保存有这条日志条目，因为任何中间的leader都包含该日志条目，leader从不会删除条目，并且follower只有在和leader冲突的时候才会删除条目。
5. 投票者把自己选票投给leader U 时，leader U 的日志必须和投票者自己一样新。这就导致了两者矛盾之一。
6. 首先，如果投票者和leader U 的最后一条日志的任期号相同，那么leader U 的日志至少和投票者一样长，所以leader U 的日志一定包含所有投票者的日志。这是另一处矛盾，因为投票者包含了那条已经被提交的日志条目，但是在上述的假设里，leader U 是不包含的。
7. 除此之外，leader U 的最后一条日志的任期号就必须比投票人大了。此外，他也比 T 大，因为投票人的最后一条日志的任期号至少和 T 一样大（他包含了来自任期 T 的已提交的日志）。创建了leader U 最后一条日志的之前leader一定已经包含了那条被提交的日志（根据上述假设，leader U 是第一个不包含该日志条目的leader）。所以，根据日志匹配特性，领导人 U 一定也包含那条被提交的日志，这里产生矛盾。
8. 这里完成了矛盾。因此，所有比 T 大的leader一定包含了所有来自 T 的已经被提交的日志。

日志匹配原则保证了未来的leader也同时会包含被间接提交的条目。通过leader完全特性，我们就能证明状态机安全特性，即如果服务器已经在某个给定的索引值应用了日志条目到自己的状态机里，那么其他的服务器不会应用一个不一样的日志到同一个索引值上。在一个服务器应用一条日志条目到他自己的状态机中时，他的日志必须和leader的日志，在该条目和之前的条目上相同，并且已经被提交。现在我们来考虑在任何一个服务器应用一个指定索引位置的日志的最小任期；日志完全特性保证拥有更高任期号的leader会存储相同的日志条目，所以之后的任期里应用某个索引位置的日志条目也会是相同的值。因此，状态机安全特性是成立的。最后，Raft 要求服务器按照日志中索引位置顺序应用日志条目。和状态机安全特性结合起来看，这就意味着所有的服务器会应用相同的日志序列集到自己的状态机中，并且是按照相同的顺序。

3.5 follower和candidate崩溃

到目前为止，我们都只关注了leader崩溃的情况。follower和candidate崩溃后的处理方式比leader要简单的多，并且他们的处理方式是相同的。如果崩溃了，那么后续发送给他们的 RPCs 都会失败。Raft 中处理这种失败就是简单的通过无限的重试；如果崩溃的机器重启了，那么这些 RPC 就会完整的成功。如果一个服务器在完成了一个 RPC，但是还没有响应的时候崩溃了，那么在他重新启动之后就会再次收到同样的请求。Raft 的 RPCs 都是幂等的，所以这样重试不会造成任何问题。例如一个follower如果收到附加日志请求但是他已经包含了这一日志，那么他就会直接忽略这个新的请求。

3.6 时间和可用性

Raft 的要求之一就是安全性不能依赖时间：整个系统不能因为某些事件运行的比预期快一点或者慢一点就产生了错误的结果。但是，可用性（系统可以及时的响应客户端）不可避免的要依赖于时间。例如，如果消息交换比服务器故障间隔时间长，candidate将没有足够长的时间来赢得选举；没有一个稳定的leader，Raft 将无法工作。

leader选举是 Raft 中对时间要求最为关键的方面。Raft 可以选举并维持一个稳定的leader,只要系统满足下面的时间要求：

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

在这个不等式中，广播时间指的是从一个服务器并行的发送 RPCs 给集群中的其他服务器并接收响应的平均时间；选举超时时间就是前面介绍的选举的超时时间限制；然后平均故障间隔时间就是对于一台服务器而言，两次故障之间的平均时间。广播时间必须比选举超时时间小一个量级，这样leader才能够发送稳定的心跳消息来阻止follower开始进入选举状态。选举超时时间应该要比平均故障间隔时间小上几个数量级，这样整个系统才能稳定的运行。当leader崩溃后，整个系统会大约相当于选举超时的时间里不可用；我们希望这种情况在整个系统的运行中很少出现。

广播时间和平均故障间隔时间是由系统决定的，但是选举超时时间是我们自己选择的。Raft 的 RPCs 需要接收方将信息持久化的保存到稳定存储中去，所以广播时间大约是 0.5 毫秒到 20 毫秒，取决于存储的技术。因此，选举超时时间可能需要在 10 毫秒到 500 毫秒之间。大多数的服务器的平均故障间隔时间都在几个月甚至更长，很容易满足时间的需求。