【学习笔记】分布式一致性算法——Raft算法
写在前面
花了好长时间终于吧这篇笔记肝出来了QAQ，最近确实好久没做笔记了（虽然这篇笔记是为毕设服务的），后面估计会多发几篇笔记，鞭策下自己吧QwQ。
什么是Raft
Raft是更易理解的共识算法，相比于Paxos来说，Raft通过两个主要操作来使得问题更佳简化：
- 状态简化：将角色进行简化，减少状态数量和可能发生的变动。
- 将问题分解为三个子问题：Leader选举、日志复制、安全性。
Raft的易理解性，论文中也有调查分析证明。通过对学习Paxos和学习Raft的学生考试对比，学习Raft的考试得分普遍高于Paxos的考试得分。
前置知识——复制状态机
相同的初始状态状态A + 相同的一系列指令 = 相同的结束状态状态B
指所有节点在相同的状态A下，执行一系列指令后，都能得到一致的状态B。这保证了分布式节点的一致性。
前置知识——角色（状态机）
- Leader 领导节点
- Candicate 候选人
- Follower 跟随者（每个节点启动时的初始状态）
前置知识——RPC
节点之间使用远程过程调用（RPC）进行，通信。Raft的RPC有三种：
- RequestVote RPC: 候选人（candidate）发起选举请求
- AppendEntries RPC：表示leader复制日志到follower，也表示心跳包
- InstallSnapshot RPC：对于日志落后较大的follower，leader使用该RPC发送快照给follower，避免了大量AppendEntries RPC请求。
子问题1 —— Leader选举
任期（term）
- 首先每个节点都有一段时间周期
term（任期），term（任期）是递增的，且每个term（任期）中的时间是随机的（论文中给出的时间是150ms-300ms）。 - 选举过程中，follower当收到不是最新的任期（不是大于自己的任期）的rpc选举请求将会拒绝。假如是最新任期，follower则会把自身currentterm（当前任期）设置为最新的任期。
心跳机制
假设当前节点中有leader，leader会不断向其他节点发送心跳包（一种特殊的AppendEntries RPC），当flower节点收到这个RPC时，会重置该任期的时间，这样就不会出现任期内时间周期超时的情况。
选举机制
假设一开始没有Leader，这时候当有follower当前term的时间周期结束时就会自动转变为candicate，并向集群中其他节点发起选举请求。
选举过程如下：
- （1）follower当前term时间周期结束时，term值+1，发起选举并投自己一票。 （2）candidate需要得到超过一半节点的选票才能当选leader，并通知当选声明。如果节点在candidate状态时收到Leader节点的心跳后，如果新Leader的任期不小于自身任期，则将自身状态由candidate转变为follower。 （3）如果没有candidate获得超过半数选票，candidate节点将在自身任期超时后将自身任期+1，继续步骤1.2。
- 每个节点保存了自己term的值，如果candidate在选举过程中发现自己的term不是最大的，就会立即变更为follower角色，如果follower收到了term比自己小的节点的选举请求，会直接拒绝请求。这个机制可以保证集群的数据基本是最新的。
- 有节点当选leader后，会定期给其他节点发送心跳包，其他节点收到leader的心跳包就会立刻重置自己term内的时间周期。当leader挂了或者出现网络分区，将回到步骤1。
子问题2 —— 日志复制
当节点当选leader时，对于客户端发送的每个命令，leader都会储存在对于的日志条目（log entity）中，对于日志条目基本信息如下：
- 索引号（index）
- leader任期号（term）
- 执行的指令
当客户端请求执行指令，客户端就会发送到Raft集群的其中一个节点中，如果发送到follower节点，就会将这个指令转发到leader节点中。
如果发送到leader节点，leader节点会生成一条日志（log entity），并将这条日志通过AppendEntries RPC向follower节点追加日志。
需要注意的是，此时日志并没有真正提交，follower节点收到leader发来的AppendEntries RPC请求后，复制该日志完成后向leader节点发送响应回复RPC，当有半数节点回复时，此时leader节点就可以将这条日志进行提交。
未回复的follower节点有两种情况：
- follower宕机或者回复较慢：leader节点会继续发送AppendEntries RPC，即使leader已经响应客户端。
- follower从宕机状态回复，且日志不是最新的：此时会进行一致性检查操作。
- 一致性检查操作：leader会不断发送AppendEntries RPC给flower，AppendEntries RPC中会包含上一条日志的索引号和任期号，follower判断本节点中是否存在索引号和任期号相同的上一条日志，如果存在则回复成功，不存在则回复失败。如果失败，leader会一直将发送索引号-1的追加日志条目RPC请求，直到follower回复成功为止，这样就可以定位到follower节点第一个缺失的日志。
此外，可能还存在leader节点宕机的情况。如果leader宕机一段时间，导致follower节点任期超时，就会触发leader选举流程。
这时选举出的新leader会出现和follower日志不一致的情况，这时会通过follower强制复制leader日志的手段解决问题。
子问题3 —— 安全性
为了处理边界问题，Raft论文中独立开辟了第三个子问题——安全性，该子问题主要分为四个部分：
- leader宕机 —— 选举限制
- leader宕机 —— 提交相关问题
- follower或candidate宕机
- 时间与可用性
leader宕机 —— 选举限制
举个例子
我们来看下面这张图：
这张图种我们不难看出，follower节点中有很多节点不具备完整的日志，是因为日志复制过程中只要日志复制到了大多数节点就可以提交。
假如这一时刻leader突然宕机了，日志缺失的节点当选leader，是十分危险的。所以要进行选举限制。
选举限制规则
如果candidate上的最后一个日志相比较与follower上的最后一个日志不是最新的（即使follower上最后一个日志是未提交的），那么follower将拒绝该candidate的选举请求。
这个新是这么定义的：
- 任期号不同，则任期号大的日志更新
- 任期号相同，则索引号大的日志更新
有了这样的规则，就能保证选举出来的leader日志是最新的。
leader宕机 —— 提交相关问题
再举个例子
我们分析一下上图：
- （a）时刻S1为leader，生成日志2，并复制到S2。
- （b）时刻S1宕机，S5获得S3、S4选票当选leader，任期号为3，生成日志3后宕机。
- （c）时刻S1故障恢复，重新当选leader，任期号为3时选举失败（因为任期号不是最新的，收到其他follower反对），任期号4时选举成功。S1日志2复制到了S3中（此时日志2未提交），生成日志4后又宕机了。
这里有个问题：（c）时刻中日志2可以提交吗？
假设日志2可以提交，那么（d）时刻，S5再次当选leader，然后把日志3覆盖复制到了所有节点中。这样日志2就被覆盖掉了，是十分危险的
日志提交规则
leader只能提交自己任期内的日志，不会提交非自身任期内的日志。
（但非自身任期内的日志时可以复制的（因为复制是安全的），且提交自身任期内日志时可以顺便把非自身任期内日志提交了，这个个人理解是因为日志时有序的，当新日志提交了，没提交的老日志就默认提交了，这个情况是安全的，不会导致数据不一致的情况。）
还是上面的例子
所以说，（d）时刻的情况是不存在的，即使S5再次当选leader，也要生成一个任期号为5的日志并提交，才能把别的节点未提交的日志覆盖了，否则（d）时刻这种情况也不一定是安全的。
（e）时刻的情况是合法的，S1将日志4复制到了大多数节点，此时已经构成大多数，S1可以把日志4提交了，这样日志2也就一并提交了。
follower或candidate宕机
这种情况是比较简单的，follower或candidate宕机的情况会导致rpc包未被接收。这是只用重复发送rpc包，直到对方节点响应位置。（rpc请求都是幂等的）
时间与可用性
Raft系统整体不受时间影响。也就是说rpc包接收顺序并不会影响日志顺序。
当设置选举超时时间时，主要要考虑两个因素：广播时间（个人理解为延时时间）和平均故障时间。
- 当选举超时时间小于广播时间时，会导致follower节点无法接收到心跳包，导致无限选举的情况。
- 当选举超时时间大于平均故障时间时，会导致还没选举出leader就宕机，进而导致选举不出leader的情况。
然而，一般平均故障时间都会比较长，所以不用太考虑这个因素影响，主要考虑广播时间。
总结来说就是：
广播时间 << 选举超时时间 << 平均故障时间
集群成员变更
分布式集群成员变更过程中，可能会发生leader中途宕机的，造成新旧配置选举出两个leader的情况。这种情况就是分布式系统中的脑裂问题。如下图所示。
图中为三节点扩容至五节点的某一时刻，绿色为旧配置节点，蓝色为新配置节点。此时leader突然宕机恢复。其中旧配置中集群数为3，还在旧配置的节点为1和2，两票可以在旧配置中当选出一个leader。新配置节点数为5，且切换到新配置的节点为3/4/5，三票可以在新配置中当选出一个leader。就会产生两个leader当选的情况。
Raft为了防止这一情况发生，在旧配置和新配置切换过程中加入一个过渡的配置——联合一致（C oldnew）。
联合一致状态下，投票规则如下：
在联合一致状态的节点，投票必须要通过新配置和旧配置的大多数节点才能成功。
这样就能避免脑裂问题了。
举个例子
还是这张图，但这次不是从旧配置直接切换到新配置，而是进入联合一致状态。那么这个时刻leader宕机恢复。重新开始选举。
节点12之间可以产生一个leader，我们假设节点1当选leader。回到节点3/4/5中，假设节点3发起选举，在新配置中，节点3可以拿到节点4/5和自己三票，构成新配置投票的大多数。但是在旧配置中，节点3拿不到节点1/2的选票，因为节点1当选了leader，所以节点三选举失败。通过联合一致状态，就解决了脑裂问题。
新增节点需要考虑的情况
新增节点时，因为新节点日志相比leader落后很多。此时可以先将新节点设置为只读（没有投票权，不参与日志计数），然后再复制节点，等到新节点日志追上leader后便可发起集群成员变更。
缩减节点需要考虑的情况
-
当集群成员缩减时，因为leader可能就是要缩减的节点，leader要在新配置配置完成后自动退位。此时他可以发送Cnew日志，但是日志计数是不计自身。
-
为了避免下线的节点超时发起选举，影响集群运行。因为leader不会继续发送心跳包给下线的节点，造成要下线的节点任期超时发起选举。
解决方法：服务器会在确信集群中有leader的情况下忽略选举请求。
具体方式：如果节点在最小选举超时时间内收到RequestVote RPC是，不会对选举请求进行投票，即使发起选举的节点任期号更大，也不会根据选举请求中的任期号更改自己的任期号。这样节点必须等待一个最小选举参与时间才能处理选举请求，leader可以通过不断发送心跳包来维持集群正常运作，不会被即将下线的节点发起的选举请求干扰集群。
最后的话
本篇笔记是根据参考文献里的内容，以及Raft论文进行的个人对Raft相关内容的一篇知识梳理，知识量较大。虽然本人对相关知识进行了查阅论文考证，但是初学Raft算法，个人理解能力有限，如果有不正确的地方还望指出，感谢~
参考文献
知乎 —— raft共识算法 - Leader选举
csdn —— raft算法详解
csdn —— 分布式一致性协议：Raft算法详解
bilibili —— 解读共识算法Raft
github —— 寻找一种易于理解的一致性算法（扩展版） —— 中文翻译