Raft论文lab2相关部分——Section5

前言

本文总结了raft论文Section 5中与lab2相关的具体实现，包括选举、日志复制、异常处理、安全性部分，来帮助理解，完成lab2的实现。

5.1 raft basic

注：lab2中设计数据结构基于上图Figure 2

1.raft集群

(1)一般有5个服务器，可容忍2个失败。
(2) 服务器有三种状态：leader, follower, or candidate.
一般情况下，有一个leader，其他都是follower
(3) follower是消极的：它们自己不会发生任何请求，只是简单回复leader或candidate的请求。
leader接收所有客户端的请求
candidate用来选举出一个新的leader，正如5.2部分。
状态转化在Figure 4：

2. 任期terms

（1）ratf将时间以任意长度分为terms任期，正如Figure5中显示：

（2）任期是一系列连续的数字。开始于一次选举，当candidate当选为leader，就以提交选票时的任期执行。
（3）每一届任期最多有一个leader。
（4）term像raft中的逻辑时钟，能够让服务器探测到一些错误信息，如过期的leader。
每一个服务器保存了一个Current term数字，这个数字是根据时间单调递增的。
（5）当服务器之间交换信息时，Current terms也进行交换。
如果一个服务器发现自己的current term比其他的小，就会把自己的更新到那个较大的值。
如果一个candidate或leader发现它的term过期了，就会转化成follower。
如果一个服务器收到了带有过期term number的请求，它会拒绝这个请求。

3.RPC

（1）raft 服务器交换信息使用RPC（remote procedure calls)
（2）基本的共识算法实现只需要两种类型的RPCs：RequestVote RPCs 和 AppendEntries RPCs.
RequestVote RPCs: 由选举中的candidates发起 。 如 Section 5.2
AppendEntries RPCs：由leader发起，用来复制 log entries和发送心跳信息。如Section 5.3。
（3）Section 7添加了一个第三种类型的RPC，在服务器之间传输快照snapshots。
（4）服务器如果没有及时接收到响应，将重试RPC，并且为了性能，它们会并发的发送RPCs。

5.2 Leader election

1.raft用心跳机制来触发leader选举。
2.当一个服务器启动时，它从followers状态开始。只要服务器从leader或candidate收到有效的RPCs, 它就会保持followers状态。
leaders发送周期性的心跳（AppendEntries RPCs没有携带任何log entries) 给所有followers来保持它的权威性。
如果一个follower在一个时间周期(election timeout)内没有收到心跳，就会假设当前没有有效的leader，会发起一轮选举来选出新的leader。
3.选举流程
（1）一个follower增加它的current term, 转化其状态为candidate。
（2）然后它给自己投票，并发的发送RequestVote RPCs给集群中的其他服务器。
（3）一个candidate直到以下三种状态发生才结束其候选人状态：
a.它赢得了选举
一个候选者如果在一个term内收到了大多数服务器的投票就赢得了选举。
每个服务器在一个term内最多只能投一次票，依据先来先服务的准则（Section 5.4对投票增加了限制）。
大多数的原则确保了每一个term最多只能有一个候选者赢得选举（Figure 3中的选举安全原则）
当一个候选者赢得选举，它就成为了leader。然后发送心跳信息给其他所有的服务器来阻止新的选举。
b.另外一个服务器当选为leader
当等待投票时，candidate可能会收到一个来自其他服务器声明其成为leader的AppendEntries RPC。如果这个leader的term不小于当前candidate的current term，那么这个candidate就承认leader合法，并且退回follower状态。如果小于，则candidate拒绝这个RPC并且保持candidate状态。
c.一个周期时间内没有当选者
这种结果是当前candidate在选举中即没有赢也没有失败。如果有多个follower同时成为candidate，那么投票会被分开，所以没有candidate能够获得多数投票。
这种情况下，每个candidate会超时并且增加它的term开始新一轮选举。这里如果没有额外的措施，分区投票的情况会无限的重复。
raft采用了随机的election timeouts来解决分区投票的情况（固定150-300ms）。

注：lab2中使用的election timeout是300ms以上。

4.论文这里还提到了给candidate分级，等级高的candidate优先获得投票，等级低的退回follower状态。但是发现会有轻微的使用性上的问题。所以还是决定是使用随机重试的方法。

5.3 Log replication

1.一旦一个leader选举成功，它就开始服务客户端的请求。每个客户端的请求包括了一个被复制状态机执行的命令command。leader将这个command作为一个新的entry放到它的log里，然后并发发送AppendEntries RPCs 给其他服务器来复制这个entry。
当这个entry被安全的复制，leader会apply这个entry到它的状态机，然后回复执行结果给客户端。
如果follower崩溃或者运行缓慢，或者网络包丢失，leader会无限重试AppendEntries RPC（即使它已经回复了客户端）直到所有的follower都保存了所有的entry。
2.logs按照Figure 6展示的方式组织

每个log entry保存一个状态机命令和一个term数字，这个term是entry被leader收到时的任期。这个在log entries中的term数字被用来检测logs的不连贯，和保证Figure 3中的一些特性。

每个log entry也有一个整数下标来标示它在log中的位置。
3.leader决定了apply 一个log entry到状态机的时刻来保障安全，这个时候的entry叫做committed。
raft保证commited entries是持久的，并且最终会被所有可用的状态机执行。
一个log entry 一旦被leader复制到大多数的服务器上（正如Figure6中的entry7), 就被committed了。这个提交也commit了所有在leader log里之前的entry，包括前任leader创建的entry。Section 5.4讨论了一些leader改变后应用这个规则的细节，表示这个commitment的定义是安全的。
leader 保存了它所知道的已提交的最大的下标，并且包含在未来的AppendEntries RPCs请求（包括心跳）中，为了让其他服务器也能知道这个下标。当一个follower知道一个log entry已经committed，它会按照log的顺序apply这个entry到本地状态机。
4.我们设计Raft log机制是为了在不同的服务器之间保持日志的高度一致性。
raft保持以下的特性，这些也维持了Figure 3的 日志匹配特性：
a. 如果不同日志的两个entry有相同的index和term，那么它们保存着同样的命令。
b.如果不同日志的两个entry有相同的index和term，那么前面所有的日志都是相同的。
第二条由AppendEntries时一个简单的一致性检查来保证。当发送一个AppendEntries RPCs时，leader包括了新entry前一个的entry的index和term。如果follower没有在日志中发现同样的index和term的entry，就会拒绝这个新entry。这个一致性检查类似一个归纳的步骤。
总之，当一个AppendEntries返回成功时，领导者通过新条目知道追随者的日志与自己的日志相同。

5.服务器崩溃导致日志不连续的情况
在正常操作的情况下，leader和follower的日志是保持连续的，所以AppendEntries的一致性检查不会失败。然而，当leader崩溃导致日志不连续时（老的leader也许没有完成复制它日志中所有的entry)。这些不一致可能会在一系列leader和follower崩溃中加剧。
Figure 7中展示了一种follower的日志与新leader不同的情况

raft中，leader处理不连续的方式是强制follower的日志复制它自己的。这意味着在follower中冲突的entry会被leader的覆盖。Section 5.4 展示了怎样根据限制复制是安全的。

6.leader处理follower的不连续日志
（1）为了让follower的日志和它自己的一致，leader必须找到最后一个两服务器相同的日志entry，删除follower日志中之后所有的entry，并且发送给follower在那点之后leader的所有entry。所有这些操作在回复AppendEntries RPCs中一致性检查的时候发生。
（2）leader为每一个follower保持一个nextIndex,这个index是leader要发送给follower的下一个日志entry的下标。
当一个leader刚刚选举成功，它会初始化所有的nextIndex的值为它自己日志的最后一个下标（Figure 7中是11）。如果一个follower中的日志与leader的不一致，这个AppendEntries一致性检查就会在下一次AppendEntries RPCs时失败。收到一个被拒绝的消息后，leader就会减少nextIndex的值，并且retry。最终nextIndex会到达leader和follower日志匹配的点。此时，AppendEntries会成功，并移除所有follower中冲突的entry附加上leader中的entry。一旦AppendEntries成功，follower的日志就与leader中的一致，并且在当前term中会保持这种一致的状态。
（3）减少被拒AppendEntries RPCs数量的优化策略。
例如：当拒绝一个AppendEntries请求时，follower可以在返回的信息中包括：冲突entry的term和它日志中保存的这个term的第一个下标。
有了这些信息，leader就可以将nextIndex减少到跨过那个term中所有的冲突entry的位置。这样，每个有冲突entry的term需要一个AppendEntries RPC，而不是每个entry需要一个RPC。在实际中，我们怀疑这个优化是否必要，因为失败极少发生，似乎不太可能有太多不一致的entry。
（4）因为这种机制，leader当选举成功时，不需要采取其他的行为来保持日志一致性。它只需要正常的操作，由于对AppendEntries一致性检查的回复，日志会自动的收敛。
leader不会覆盖或删除自己日志中的entry（ Figure 3中Leader Append-Only Property）
7. log复制机制展示了Section 2中的共识特性：只要大多数的服务器正常运行，raft就可以接收、复制、应用新的log entry。在正常的情况下，一个新的entry可以在一个单独的RPC来回中复制到集群多数的机器上。一个慢的follower不会影响性能。

5.4 Safety

这一部分给要选举为leader的服务器添加了一些限制，来完善Rfte的算法。这些限制保证了一个给定term的leader包括了所有在之前term中提交了的entry。（Figure 3中的Leader Completeness Property）。

5.4.1 Election restriction

1.raft采取了一个简单的方法从选举的时候来保证每一个新的leader有所有之前term的已提交的日志entry，而不需要向新leader转移这些已提交的entry。
这意味着日志entry只会从leader流向follower，而且leader用于不会覆盖它们自己日志中已经存在的entry。
2.raft使用选举流程来保证一个candidate只有拥有所有已提交entry才能赢取选举。
RequestVote RPC实现了这个限制：这个RPC包括了candidate的日志信息，如果投票者自己的日志比candidate的日志更加新，它将会拒绝为该candidate投票。
raft决定哪一个日志更加新的方法是，比较日志中最后一个entry的index和term。
如果日志最后一个entry有不同的term，那么term更大的日志是更新的。如果日志拥有同样的term，那么日志更长的是更加新的。

5.4.2 Committing entries from previous terms

1.按照Section 5.3说的，一旦当前term的entry被复制到大部分的服务器上，leader就知道当前term的entry已提交。如果一个leader在提交一个entry之前就崩溃了，将来的leader们会尝试完成entry的复制。然而，如果一个以前term的entry即使被保存在大部分的服务器上，leader也无法立刻判定它已提交。
Figure 8描述了这种情况，一个老的日志entry被保存在大部分的服务器上，但是还是被新的leader覆盖了。
2.为了解决类似Figure8中的问题，raft永远不会通过计算副本提交之前term的log entry。只有leader当前term内的log entry会通过计算副本来提交，然后所有之前的entry都会间接的提交，因为the Log Matching Property。
raft在提交规则中引入了这种额外的复杂性，因为当一个leader复制以前term的log entry时，这些log entry会保持它们原始的term 数字。在其他的共识算法中，如果一个新的leader复制之前term的entry，它会使用它的新term。raft的方法是都得log entry变得简单，因为它们从头到尾保持同样的任期。
而且，相对于其他共识算法，新的leader发送更少的前任任期的log entry。

5.4.3 Safety argument

证明了the Leader Completeness Property的正确性，即被当选为leader的候选者节点一定有所有已提交的日志entry。
同时也证明了Figure 3中的the State Machine Safety Property，即若一个server已apply一个log entry在它的状态机，其他的server不可以在同一个index apply不同的entry。

5.5 Follower and candidate crashes

follower和candidate崩溃是更简单的情况。发送给它们的RequestVote 和 AppendEntries RPCs就会失败，raft会无限重试。如果崩溃的服务器重启了，RPC会成功。raft的RPC是幂等的。

5.6 Timing and availability

raft的leader选举时间是非常重要的。raft要选举和保持一个稳定状态的leader只要系统满足如下的时间要求：
broadcastTime << electionTimeout << MTBF
broadcastTime是集群中RPC请求来回的平均时间。
broadcast time和MTBF都是底层系统的属性。broadcast time范围是0.5ms-20ms。因此，election timeout应该是10ms-500ms。一般服务器的MTBF是几个月或更多。