Raft论文手译（下）

继续上一篇，本篇文章将对Raft论文的后半部分进行翻译。

5.4、安全性

        上一节讲述了Raft的领导者选举和日志条目复制。然而，刚刚讲述的这些机制还不足以保证每个状态机以同样的顺序执行同样的命令。举个例子，在领导者提交几个日志条目时，追随者这时可能还无法运作，接着集群可能选举出新的领导者并覆盖掉这些条目；结果就是，不同的状态机可能会执行不同的指令序列。

        本节会在集群可能要选举领导者时增加一个限制，来完善Raft算法。这个限制可以保证任何一个任期的领导者都能持有前任已提交的所有日志条目（图3的“领导者完整性性质”）。考虑到领导者选举的限制，我们会制定更加详细的条目提交规则。最后，我们提供了一张“领导者完整性性质”的检验草图并展示领导者是如何校准复制状态机的行为的。

5.4.1 选举限制

        在任何基于领导者的一致性算法中，领导者都必须最终保存所有的已提交日志。在某些一致性算法中，例如ViewStamped Replication [22]，集群可以选举出一个领导者，即便它一开始并没有所有的已提交条目。这些算法添加了更多机制来确定丢失的条目，并把它们转移到新的领导者中，这个过程会在选举领导者或不久之后进行。很遗憾的是，这导致增加了大量算法机制和复杂性。Raft通过一种更简单的方式保证之前提交的条目无需转移便存储在每一届选举出的领导者中。这就意味着日志是单向流动的，从领导者流向追随者，而领导者是绝不会覆盖掉自己的日志条目的。

        图8：这个时间序列展示为什么无法改变前任领导者已提交的日志。在（a）中，S1是领导者且部分复制状态机的日志条目下标是2。在（b）中，S1领导者宕机；S5经S3、S4以及自己的选票成为第三任领导者，并在条目下标为2的位置接收了一个不同的条目。在（c）中，S5宕机；S1重启被选举为领导者，并继续条目复制。在这时，任期号为2的日志条目复制到了集群的大多数服务器，但还没提交。如果S1在（d）宕机，S5可能被选举为领导者（通过S2、S3、S4的选票）并通过自己任期号为3的条目覆盖掉原来未提交的条目。然而，如果S1在宕机前就把一个条目复制到集群中的大多服务器，像（e）那样，接着这个条目会被提交（S5无法赢得选举）。这时，之前日志里所有的条目也会被提交。

        Raft通过选票进程阻止竞选者赢得选举，除非它的日志包含所有已提交条目。竞选者必须通知集群中大多数服务器来赢得选举，这就意味着每个已提交的条目必须至少存在于一个服务器中。如果竞选者的日志在其它大多数服务器中是最新的（所谓的“最新”会在下面详细定义），那么它将继续持有所有已提交的日志。“请求投票”远程调用实现了这个限制：这种远程调用包含了竞选者的日志，如果投票者的日志比竞选者的日志更新，则它会拒绝投票。

        Raft通过对比最新条目的下标和任期号来决定两个日志谁是更新的。如果这些日志最新的条目任期号不同，那么任期号高的日志算是最新的。如果日志的任期号相同，则日志长的就是最新的。

5.4.2 从之前的任期提交条目

        正如5.3所述，领导者能察觉到一旦条目在集群中大多服务器中存储，那么它就是在本任期提交的。如果领导者在提交条目前就宕机了，之后的领导者会尝试结束本条目的复制。然而，一个前任期的条目存储在大多服务器中，领导者不会马上判定这个条目已经提交。图8讲述了一种情况，旧的条目即便存储在大多数服务器中，依然也可能会被新的领导者覆盖掉。

       图9：如果S1（T任期的领导者）在本任期提交了一个新日志条目，而S5在U任期被选举为领导者，那么必须至少有一个服务器（S3）接受这个日志条目并投S5一票。

       为了解决图8的问题，Raft绝不会保存日志条目副本，在之前的任期里提交它们。只有本任期领导者的日志条目会以计数副本的形式提交；一旦条目在本任期这样提交上去，那么所有之前的条目都会因为“日志匹配性质”间接地提交。有些情况领导者可以安全地认为旧条目已经提交（举个例子，比如所有服务器都存储了这个条目），但Raft为了简洁性采取一种更保守的方法。

       Raft在提交规则中引入这种额外的完整性，是因为日志条目会在领导者复制前任条目时重新获取原有的任期号。在其它的一致性算法中，如果新上任的领导者复制前任的条目，它必须用新的任期号来复制。Raft的方法能更容易推出日志条目，因为它们随着时间和条目数保持着相同的任期号。同时，在Raft中，领导者相对于其它算法发送前任条目的次数更少（其它算法的日志条目提交前必须发送冗余的条目来记录它们）。

5.4.3 安全性论点

       考虑到Raft算法的完整性，我们现在可以更详细地讨论“领导者完整性性质”了（这个论点是基于安全性论证的；详见节9.2）。我们先假设“领导者完整性性质”不成立，接着找出一个反例。假设T任期的领导者在自己的任期里提交了一个日志条目，但这个日志条目并没有存储到之后的领导者中。考虑到任期U>T，U任期的领导并没有存储这个条目。

       1.该提交的条目在领导者U选举时不能存在与它的日志中（领导者绝对不能删除或覆盖条目）

       2.集群中大多服务器复制了领导者T的条目，而领导者U收到了大多选票，因此至少有一个服务器（投票者）既接受了T的条目，又投了U一票，如图9所示。投票者是达到这个条件的关键。

       3.投票者在投票给领导者U前，必须接受领导者T的已提交条目；否则它就会拒绝领导者T的“添加日志”请求（投票者的任期会比T的高）。

       4.投票者在投领导者U一票时，依然会保存这个条目，因为每个介于两个任期之间的领导者还持有这个条目，领导者是不会移除条目的，而追随者只有在它们的条目与领导者冲突时才会移除它们。

       5.投票者同意投领导者U一票，则领导者U的日志必须和投票者的一样新。这就达到了两个条件的其中一个。

       6.首先，如果投票者和领导者U拥有同样的最新日志任期号，那么领导者U的日志就必须至少和投票者的一样长。这是一个矛盾点，因为投票者持有这个已提交的条目，而领导者U认为它没有。

       7.否则，领导者U的最新日志任期必须比投票者的大。此外，它也比T的任期大，因为投票者的最新日志任期至少是T（它包含了T任期提交的条目），给U创建的最新日志条目的前任领导者必须包含有它的已提交日志条目（假设是这样）。那么根据“日志匹配性质”，领导者U的日志必须也包含这个已提交的条目，而这就是另一个条件。

       8.这完善了矛盾点（反证法）。因此，所有比T任期号更大的领导者必须必须持有T任期所有已提交的条目。

       9.“日志匹配性质”保证之后的领导者会间接持有已提交的条目，例如图8（d）的下标2。

       考虑到“领导者完整性性质”，我们可以从图3证明“状态机安全性质”，在这种状态下如果服务器向它的状态机申请一个下标位置的日志条目，那么其他服务器就不会在同一个下标上申请不同的日志条目。当一个服务器向状态机申请到日志条目时，它的日志必须和服务器的一致且这个条目必须提交。现在考虑所有服务器申请日志下标的最小任期号；“日志完整性性质”能够保证更高任期号的领导者会存储相同的日志条目，申请后续任期下标的服务器也能因而申请到同样的值。因此，“状态机安全性质”是成立的。

       最后，Raft要求服务器按照日志下标顺序申请条目。结合“状态机安全性性质”，这意味着所有的服务器会按相同的顺序向状态机添加日志条目。

5.5、追随者和竞选者宕机

       在此之前我们都聚焦于领导者失败。相比于领导者宕机，追随者和竞选者宕机处理起来就简单多了，而且它们的处理方式是一样的。如果追随者或竞选者宕机了，那么之后发给它的“请求选票”和“添加条目”远程调用就会失败。Raft通过不断重试的方式来处理这些问题：如果宕机的服务器重启了，那么远程调用就能成功。如果服务器在远程调用完成后、响应前宕机，那么它会在重启后再次收到同一个远程调用请求。因为Raft的远程调用是相互独立的，所以这也没什么坏处。举个例子，如果追随者收到一个“添加条目”的请求，这个请求包含追随者日志中已经存在的条目，那么它就会在新的请求中拒绝这些条目。

5.6、时间和可用性

       我们对Raft的其中一个要求是安全性绝对不能依赖时间：系统绝对不能因为某些事件比预期来得太快或太慢而产生错误的结果。然而，可用性（系统以合适的方式响应客户端）必然是会地依赖时间的。举个例子，如果消息交换比服务器宕机通常占用的时间更长，竞选者无法等那么长的时间来赢得竞选；没有一个稳定的领导者，Raft就没法进行。

       领导者选举是Raft在时间方面最重要的地方。只要系统满足以下的时间要求，Raft就可以做到选举和维护一个稳定的领导者：
              广播时间 << 选举超时 << 平均故障间隔时间

       在这个不等式中，“广播时间”是指服务器同时向集群中其它所有服务器发送远程调用和收到回复所占用的时间；“选举超时”是指节5.2讲述的选举超时的时间；而“平均故障间隔时间”是指服务器两次宕机的平均间隔时间。广播时间应该远远小于选举超时时间，这样领导者才能可靠地发送心跳包来阻止追随者开展选举；考虑到Raft使用了随机选举超时时间方案，这个不等式也不太可能导致选票分散现象出现。选举超时时间应该远远小于平均故障间隔时间，这样系统才能稳定运行。当领导者宕机了，系统会因为选举超时而无法使用；我们希望这个时间在总时间中只占极小的一部分。

       广播时间和平均故障间隔时间是这种系统的基本性质，而选举超时时间是必须由我们来选择的。Raft的远程调用通常需要接收者将数据信息保存在可靠的介质中，因此根据存储技术的不同，广播时间可能在0.5毫秒到20毫秒。这样一来，选举超时时间可能在10毫秒到500毫秒之间。通常服务器的平均故障间隔时间在几个月或更长，这就满足了时间上的需求。

       图10：直接将一种配置切换成另一种配置是不安全的，因为不同的服务器会在不同时间切换。在这个例子中，集群的规模从3个服务器增加到5个服务器。不幸的是，在某一时刻同一任期可以选出两个领导者，一个领导者大多配置是旧的（Cold），另一个领导者的大多配置是新的（Cnew）。

6 集群成员变更

       到目前为止我们都在假设集群的配置（指这个一致性算法的服务器集合）是固定不变的。实际上，偶尔改变集群的配置是有必要的，例如取代崩溃的服务器或改变复制机的数量。尽管说可以先让整个集群下线，升级配置文件，再重启整个集群，但这么做会让整个集群在变更结束前都无法使用。此外，如果这期间还涉及到手动操作，它们还得承担操作错误的风险。为了避免这些问题，我们打算让配置变更工作自动完成并把它融入Raft一致性算法中。

       为了使配置变更机制安全可靠，在转换过程中绝不能出现同一任期选举出两个领导者。不幸的是，任何直接将服务器旧配置切换为新配置的方法都是不安全的。立即自动切换所有服务器配置是不可能的，因此集群在转换期间可以隐式地分割成两个规模相当的集群（详见图10）。

       为确保安全性，配置变更必须分两步走。分两步走的方法有很多。举个例子，有些系统（例如[22]）在第一阶段停用旧配置，也就不因此能处理客户端请求了；接着在第二阶段启用新配置。在Raft中，集群首先会切换到“转换”的配置，我们称之为“共同一致性”；一旦共同一致性提交完成，系统就会切换成新配置。共同一致性将新旧配置绑定在了一起：

       在两种配置下，日志条目都已经复制到所有服务器上。

       在两种配置下，任何服务器都可能是领导者。

       一致操作（指选举和提交条目）需要在新旧配置下分别获取集群大多数同意票。

       共同一致性可以让服务器个体在不同时段转换配置而无需对安全性做出妥协。此外，共同一致性能让集群在配置更改的期间继续响应客户端请求。

       图11：这是配置变更的时间线。虚线表示创建但还没提交的配置条目，而实线表示最新提交的配置条目。领导者首先在日志里创建C_old,new的配置条目，并提交提交到C_old,new（指大多C_old和_new配置的服务器）。接着创建C_new条目并把它提交至大多C_new的服务器中。这里并不会出现C_old和C_new同时独立做出决定的情况。

       集群配置会被保存起来并通过特殊的复制日志条目分发出去；图11说明了配置变更的过程。当领导者收到从C_old到C_new配置变更的请求，它会保存这种共同一致性的配置（图中的C_old,new），将其作为一个日志条目并复制它，复制条目的方式在之前讲过。一旦指定的服务器把新配置的条目添加到自己的日志中去，它就会在之后的所有决策中采用这种配置（服务器总会采用日志中的最新配置，无论什么时候这个日志提交）。这就意味着当C_old,new日志条目提交，领导者会使用C_old,new的规则进行决策。如果领导者宕机了，新的领导者可能会在C_old或C_old,new中选出，这取决于胜出的竞选者是否收到C_old,new。在任何情况下，C_new都无法在这期间独自做出决策。

       一旦C_old,new条目提交，C_old、C_new配置的服务器都无法在其它服务器批准的情况下做出决策，而“领导者完整性性质”确保了只有保存了C_old,new日志条目的服务器才能被选举为领导者。领导者创建C_new配置的日志条目并把它复制到集群其它服务器是不安全的。强调一遍，当配置可见时，它就会在每一个服务器中生效。当新的配置在C_new的规则下提交，这就和旧的配置没什么关系了，而不在新配置下的服务器也会被关闭。如图11所示，不存在C_old和C_new同时独自做出决策的情况；这就保证了安全性。

       

持续更新中…