学习Raft算法的笔记

Raft是一种为了管理日志复制的一致性算法。它提供了和Paxos算法相同的功能和性能，可是它的算法结构和Paxos不一样，使得Raft算法更加容易理解而且更容易构建实际的系统。为了提高可理解性，Raft将一致性算法分解成几个关键的模块，例如领导选举,日志复制和安全性。同时它经过实施一个更强的一致性来减小须要考虑的状态和数量。从一个用户研究的结果能够证实，对于学生而言，Raft算法比Paxos算法更容易学。Raft算法还包括了新的机制来容许集群成员的动态改变，让利用重叠的大多数来保证安全性。

Raft算法概述

Raft算法是从多副本状态机的角度提出，用于管理多副本状态机的日志复制，它一致性分解为多个子问题：领导选举(Leader election)，日志复制(Log replication),安全性(Safety),日志压缩(Log compaction),成员变动(Menbership change)等。同时，Raft算法使用了更强的假设来减小须要考虑的状态，使之变得更加容易理解。
Raft讲系统中的角色分为领导者(Leader),跟从者(Follower)和候选人(Candidate)：
Leader: 接收客户端请求，并向Follower同步请求日志。当日志同步到大都数节点上后告告诉Follower提交日志。
Follower:接收并持久化Leader同步的日志，在Leader告诉它的日志提交以后，提交日志。
Candidate:Leader选举过程当中的临时角色。

Raft要求系统在任意时刻最多只有一个Leader,正常工做期间Leader和Followers。
Raft算法角色状态转换以下:

跟随者只响应来自其余服务器的请求。若是跟随者接收不到消息，那么它就会变成候选人并发起一次选举。得到集群中大多数选票的候选人将成为领导者。在一个任期内，领导人直到本身宕机了。

Raft算法时间被划分红为一个个的任期(Term)，每一个任期(Term)开始都是一次Leader选举。选举成功后，领导人会管理整个集群直到任期(Term)结束。有时候会选举失败，那么任期(Term)就会没有领导者，而结束。任期(Term)之间的切换能够在不一样的时间不一样的服务器上观察到。

Raft算法中服务器之间节点通讯使用远程调用(RPCs).而在etcd的实现当中v2版本用的http，而v3版本采用的是grpc(自己是跨平台)。而且基本的一致性算法只是用了两种类型的Rpcs。请求投票(RequestVote)RPCs由候选人发起。而后附加条目数(AppendEntries)由Leader发起。用来复制日志和提供一种心跳机制。为了服务器之间传输快照增长了第三种RPCs。当服务器没有及时收到RPC的响应时，会进行重试，而且它们可以并行发起RPCs来获取最佳性能。

复制状态机

一组服务器上的状态机产生相同状态的副本，而且在一些机器宕掉的状况下也能够继续运行。复制状态机在分布式系统中被用于解决不少容错的问题。例如，大规模的系统中一般都有一个集群领导者，像 GFS、HDFS 和 RAMCloud，典型应用就是一个独立的的复制状态机去管理领导选举和存储配置信息而且在领导人宕机的状况下也要存活下来。好比 Chubby 和 ZooKeeper。

复制状态机的结构。一致性算法管理着来自客户端指令的复制日志。状态机从日志中处理相同顺序的相同指令，因此产生的结果也是相同的。

复制状态机一般都是基于复制日志实现的，如图 1。每个服务器存储一个包含一系列指令的日志，而且按照日志的顺序进行执行。每个日志都按照相同的顺序包含相同的指令，因此每个服务器都执行相同的指令序列。由于每一个状态机都是肯定的，每一次执行操做都产生相同的状态和一样的序列。

保证复制日志相同就是一致性算法的工做了。在一台服务器上，一致性模块接收客户端发送来的指令而后增长到本身的日志中去。它和其余服务器上的一致性模块进行通讯来保证每个服务器上的日志最终都以相同的顺序包含相同的请求，尽管有些服务器会宕机。一旦指令被正确的复制，每个服务器的状态机按照日志顺序处理他们，而后输出结果被返回给客户端。所以，服务器集群看起来造成一个高可靠的状态机。

实际系统中使用的一致性算法一般含有如下特性：

安全性保证（绝对不会返回一个错误的结果）：在非拜占庭错误状况下，包括网络延迟、分区、丢包、冗余和乱序等错误均可以保证正确。
可用性：集群中只要有大多数的机器可运行而且可以相互通讯、和客户端通讯，就能够保证可用。所以，一个典型的包含 5 个节点的集群能够容忍两个节点的失败。服务器被中止就认为是失败。他们当有稳定的存储的时候能够从状态中恢复回来并从新加入集群。
不依赖时序来保证一致性：物理时钟错误或者极端的消息延迟在可能只有在最坏状况下才会致使可用性问题。
一般状况下，一条指令能够尽量快的在集群中大多数节点响应一轮远程过程调用时完成。小部分比较慢的节点不会影响系统总体的性能。

Leader选举

Raft使用心跳(heartbeat)触发Leader选举。当服务器启动时，初始化Follower。Leader向全部的Followers周期性的发送heartbeat。若是Follower在选举超时时间内没有收到Leader的heartbeat，就会等待一段随机时间(150ms-300ms)发起一次选举。

Follower先要增长本身的当前任期号，也就把当前的任期号加一而且转换到候选人状态。而后它们会并行的向集群中的其余服务器节点发起请求投票的RPCs来给本身投票。结果会有如下三种状况:

1. 它本身赢得了此次选举
2. 其余的服务器成为了领导者
3. 一段世家以后没有人获取胜利的人。

日志复制

Leader被选举出来后.它就开始为客户端提供服务，客户端每一个请求都包含一条被复制状态机执行的命令。领导人将这条指令做为新的日志条目附加到日志中去。而后并行的发起附加条目RPCs给其余的服务器，让它们复制这个日志条目，当这条日志条目被安全的复制。领导人会应用这条日志条目到它的状态中而后把执行的结果返回客户端。若是Follower崩溃或者运行缓慢，再或者网络丢包，领导人会不断的尝试附加日志条目RPCs(尽管已经回复了客户端)直到全部Follower都最终存储了全部条目数。

日志由有序编号(log index)的日志组成条目。每一个日志条目包含它被建立的任期号(term),和用于状态机执行的命令。若是一个日志条目被复制到大多数服务器上,就被认为能够提交了(commit)了。

Raft维护着一下特征:
1.若是在不一样的日志中的两个条目拥有相同的索引和任期号,那么它们存储了相同的指令。
2.若是在不一样的日志中的两个条目拥有相同的索引和任期号,那么他们的以前的全部日志条目也所有相同。

第一个特新来这样的一个事实,领导人最多在一个任期里在指定的日志索引位置建立一条日志条目，同时日志条目在日志中的位置也历来不会改变。第二个特性由附加日志RPC的一个简单一致性检查保证。在发送附加日志RPC的时候，领导人会把新的日志条目紧接着以前的条目索引位置和任期号包含在里面。若是跟随者在它的日志中找不到包含相同的日志索引位置和任期号的条目,那么他就会拒绝接收新的条目日志。一致性检查就像一个概括步骤:一开始空日志状态确定是知足日志匹配特性的，而后一致性检查保护了日志匹配特性当日志扩展的时候。所以,每当附加日志RPC返回成功时，领导人就知道跟随着的日志时同样的了。

当一个领导人成功当选时，跟随者多是任何状况(a-f)。每个盒子表示是一个日志条目，里面的数字表示任期号。跟随者可能缺乏一些体制条目(a-b)，可能会有一些未被提交的日志条目(c-d)，或者两种状况都存在的(e-f)。例如,场景f可能会发生，某些服务器在任期号2的时候是领导人，已附加了一些日志条目到本身的日志中，但在提交以前就就崩溃了,很快这个机器就被重启了,在任期3从新被选为领导人，而且又增长了一些日志条目到本身的日志中,而且又增长了一些日志条目到本身的日志中，在任期2和任期3的日志被提交以前，这个服务器又宕机了，而且在接下来的几个任期里一直处于宕机状态。

要使得跟随着的日志进入和本身一致的状态，领导人必须找到最后二者达成一致的地方，而后删除那个点以后的全部日志条目，发送本身的日志给跟随者。全部的这些日志操做都在进行附加日志RPCs的一致性检查时完成。领导人针对没一个维护者维护了一个nextIndex,这表示下一个发送给追随者的日志条目的索引地址。当一个领导人刚得到领导者的权利的时候，他初始化全部的nextIndex值做为本身的最后一条日志的index加1。若是一个跟随者的日志和领导人不一致，那么下一第二天志附RPC时的一致性检查就会失败。在被跟随者拒绝以后，领导人就会减小nextIndex值并进行重试。最终nextIndex会在某个位置使得领导人和跟随者的日志达成一致。当这种状况发生，附加日志RPC就会成功，这时就会把跟随者冲突的日志条目所有删除而且加上领导人的日志。一旦附加日志RPC成功，那么跟随者的日志就会和领导人保持一直，而且在接下来的任期里一直继续保持。

安全性

Raft增长了以下两条限制以保证安全性:
1>拥有最新的已提交的log entry的Follower才有资格成为Leader。
这个保证是在RequestVote RPC中作的，Candidate在发送RequestVote RPC时。要带上本身的最后一条日志的term和log Index。其余节点收到消息时，若是发现本身的日志请求中携带的更新，则拒绝投票。日志比较的原则是:若是本地的最后一条log entry的term更大，则term大更新，若是term同样大，则log Index更大的更新。

2.Leader只能推动commit Index来提交当前term已经复制最到最大服务器上的日志，旧term日志的日志要等到提交当前的term的日志来间接提交(log Index 小于commit Index的日志被间接提交)
之因此要这样，是由于可能会出现已提交的日志被覆盖的状况:

如图的时间序列展现了领导人没法决定对老任期号的日志条目进行提交。在(a)中，S1是Leader，部分的是复制了索引的位置2的条目数目。(b)是时期，S1崩溃了，而后S5在任期3里经过S3,S4和本身的选票赢得选举，而后从客户端接收了一条不同的日志条目放在了索引2处。而后到(c),S5崩溃了，S1从新启动，选举成功，开始日志复制。在这个时候，来自任期2的那条日志已经被复制到了集群的大多数机器上，可是尚未被提交，若是S1在(d)时期中又崩溃了。S5能够从新被选举成功(经过来自S2,S3,S4的选票)，而后覆盖了他门在索引2处的日志。反之，若是在崩溃以前，S1把本身主导的任期里产生的日志日条目复制到了大多数机器上，就如(e)中那样。那么在后面任期里面这些新的日志条目会被提交(由于S5就不可能选举成功)。这牙膏在同一时刻就同时保证了，以前的全部老的日志条目就会被提交。

时间和可用性

Raft的要求之一就是安全性不能依赖时间:整个系统不能由于某些事件运行的比预期快一点或者慢一点产生了错误的结果。可是，可用性(系统能够及时的响应客户端)不可避免的要依赖时间。例如，若是消息交换比服务器故障间隔时间长，候选人没有足够长的时间来赢得选举，没有一个稳定的领导人，Raft将没法工做。
领导人选举时Raft中对时间要求最为关键的方面。Raft能够选举并维持一个稳定的领导人，只须要知足下面的时间要求:

广播时间(broadcastTime) << 选举时间(election Timeout) << 平均故障时间(MTBF)

在这个不等式中，广播时间指的时从一个服务器并行的发送RPCs给集群中的其余服务器并接收平均时间，选举超时时间（150ms-300ms）选举超时时间限制，而后平均故障时间就是对于一台服务器而言，两次故障之间的平均时间。广播时间必须比选举超时时间小一个量级，这样领导人才能发送稳定的心跳消息来阻止跟随者开始进入选举状态，经过随机化选举超时时间的方法，整个不等式也使得选票瓜分的状况变成不愿能。选举选举超时时间要比平局故障时间间隔小上几个数量级,这样系统才能稳定的运行。当领导人崩溃后，整个系统会大约至关于超时时的时间里不可用。咱们但愿这种状况在系统中国运行不多出现。

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

成员变动

成员变动是在集群运行过程当中副本发生变化，如增长/减小副本数，节点替换等。
成员变动也是一个分布式一致性的问题，既全部服务器对成员新成员达成一致。可是成员变动又有其特殊性，由于成员变动的一致性达成的过程当中，参与投票的过程会发生变化。

若是将成员变动当成通常的一致性问题，直接向Leader发送成员变动请求，Leader复制成员变动日志，达成多数以后提交，各个服务器提交成员变动日志后从日志成员(Cold)切换到最新成员配置(Cnew的时刻不一样.

成员变动不能影响服务的可用性，可是成员变动过程的某一时刻，可能出现Cold和Cnew中同时存在两个不相交的多数派，进而可能选出两个Leader，造成不一样的决议，破坏安全性。

因为成员变动的这一特殊性，成员变动不能当成通常的一致性问题去解决。

为了解决这一问题.Raft提出了两段的成员变动方法。集群先成旧成员配置Cold切换到一个过分的配置，称为共同一致(joint consensus),共同一致时旧成员配置Cold和新成员配置Cnew的组合Cold U Cnew，一旦共同一致Cold U Cnew被提交，系统在切换到新成员配置Cnew。

一个配置切换的时间线。虚线表示已经被建立可是尚未被提交的条目，实线表示最后被提交的日志条目。领导人首先建立了C-old
,new的配置条目在本身的日志中，并提交到C-old,new中(C-old的大多数和c-new的大多数)。而后他建立C-new条目而且提交到C-new的大多数。这样就不存在C-new和C-old同时作出决定的时间点。

在关于从新配置还有三个问题须要提出,第一个问题是，新的服务器额能初始化没有存储任何的日志条目。当这些服务器以这种状态加入到集群中，那么它们须要一段时间来更新追赶。这时还不能提交新的日志条目。为了不这种可用性的间隔时间Raft在配置更新的时候用了一种额外的阶段，在这种阶段，新的服务器以没有投票权的身份加入集群中来(领导人复制日志给它们。可是不考虑它们是大多数)。一旦新的服务器追遇上了集群中的集群，从新配置能够向上面描述同样处理。

第二个问题，集群的领导人可能不是新配置的一员。在这种状况下，领导人就会在提交了C-new日志后退位(回到追随者状态)。这意味着有这样一段时间，领导人管理着集群，可是不包括他本身，他复制日志可是不把他本身算做大多数之一。当C-new被提交时，会发生领导人过分。由于这时时最新的配置能够独立工做时间点(将老是可以在C-new配置下选出新的Leader)。再此以前，可能只从C-old中选出领导人。

第三个问题是:移除再也不C-new中的服务器可能会扰乱集群。这些服务器将不会再接收心跳。当选举超时时，它们就会进行新的选举过程。它们会发送拥有新的任期号的请求投票RPCs，这样会致使当前的领导人退回成跟随者状态。新的领导人最终被选出来，可是被移除的服务器将会再次超时，而后这种过程再次重复，致使总体可用性大幅度降低。

为了不这个问题，当服务器确认当前领导人存在时，服务器会忽略投票RPCs。特别的，当服务器再当前最小选举超时时间内收到一个请求投票的RPC。他不会更新当前的任期号和投票号。这不会影响正常的选举，每一个服务器在开始一次选举以前，至少等待一个最小选举超时时间。而后这有利于避免被移除的服务器的扰乱。若是领导人可以发送心跳给集群，那么他就不会更大的任期号废黜。

日志压缩

在实际系统中，不能让日志无限增加，不然系统重启时须要花很长的时间回放，从而影响可用性。Raft采用对整个系统进行snapshot来解决，snapshot以前的日志均可以抛弃。
每一个副本独立的对本身系统状态进行snapshot，而且只能对已经提交的日志进行snapshot。
Snapshot中包含如下内容:
1>日志元数据:最后提交的log entry的log index和term。这两个值在snapshot以后的第一条log entry的AppendEntriesRPC的完整性检查的时候会被用上。
2> 系统当前状态。

当Leader要发给某个日志落后太多的Follower的log entry被丢弃，Leader会将snapshot发给Follower。或者新加入一台机器时，也会发送snapshot给它。发送snapshot使用InstalledSnapshot RPC。

一个服务器用新的快照替换了从1到5的条目数，快照存储了当前的状态。快照中包含了最后的索引位置和任期号

作snapshot不要作的太频繁，不然消耗磁盘带宽，也不要作的太平凡，不然一点节点重启要回放大量日志，影响可用性。推荐当日组织达到某个固定的大小作一次snapshot。

作一次snapshot可能耗时过长，会影响正常日志同步。能够经过使用copy-on-write技术避免snapshot过程影响正常的日志同步过程。

一个关于 Raft 一致性算法的浓缩总结（不包括成员变换和日志压缩）。

参考：
http://thesecretlivesofdata.com/raft/(Raft动画)
https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md(Raft论文翻译)