Raft算法

写在前面

　　1. 作为共识算法，Raft不是Paxos协议或其变种，但是他们的用途相同，在结果和效率上，Paft和Paxos协议相当，但是易理解和易构建生产系统上，好于Paxos协议。

　　2. 共识算法：共识是具备容错的能力的分布式系统中的一个基本问题。共识，指的是分布的多个参与者就“值”（value）达成一致。一旦参与者对一个值做出决定，则这个决定是最终的。

Raft算法基础

　　在Raft集群（英语：Raft cluster）里，服务器可能会是这三种身份其中一个：领袖（英语：leader）、追随者（英语：follower），或是候选人（英语：candidate）。在正常情况下只会有一个领袖，其他都是追随者。而领袖会负责所有外部的请求，如果不是领袖的机器收到时，请求会被导到领袖。

　　通常领袖会借由固定时间发送消息，也就是“心跳（英语：heartbeat）”，让追随者知道集群的领袖还在运作。而每个追随者都会设计超时机制（英语：timeout），当超过一定时间没有收到心跳（通常是150 ms或300 ms），集群就会进入选举状态。

　　Raft算法把共识问题分为三个字部份：

　　　　Leader选举（Leader election）：系统初始化或者旧Leader故障需要选主，选出一个新的Leader

　　　　日志复制 (Log Replication)：Leader接受客户端的命令并将其记录为日志，然后赋值给集群中的其他服务器（即Follower角色的备用机），通过在备机执行日志，使得备机的从副本和Leader的主副本保持一致。日志复制依赖于状态机，复制状态机如图所示。

　　　　

 

　　　　　　1：客户端向服务器发送命令。

　　　　　　2：服务器通过共识模块将复制日志发送给每个备机的复制状态机（RSM），每个RSM的复制日志中的指令顺序都是相同的。

　　　　　　3：所示的RSM按顺序处理入职日志中的指令。

　　　　　　4：将处理结果返回给客户端。

　　　　　　由于RSM具有确定性，因此每个状态机的输出和状态都是相同的，因此能保证多个备机的数据处于一致状态。

　　　　　　保持日志的一致性是共识模块的工作，由共识算法完成。由于处于分布式系统中，某些服务器会出故障，因此共识算法需要考虑异常情况。日过与两阶段提交算法（2PC）比较，共识算法的核心思想是等同于2PC算法，只是Raft算法需要选出Leader，这个Leader相当于2PC中的协调者，Raft算法在投票时利用了多数原则完成投票确认，而2PC需要所有参与者都投票确认参能达成共识。所以：Raft算法中的Leader选举和日志复制其实是为了应对分布式系统故障而执行的两个过程，而这两个过程的正确完成需要安全措施来保证，而安全措施是为了应对分布式系统故障而提出的。

 

　　　　安全措施(Safety)：通过一些措施确保系统安全性，如 1确保所有状态机按照相同顺序执行相同命令；2 每一个任期内，只有一个Leader等。

算法详解

　　正常情况下，Leader负责接受客户端的请求命令，并将请求命令作为日志传输给Follower，Follower确认安全（大多数从副本已经将该命令写入日志中）后将日志命令提交到备机的复制状态机执行。

　　几种分布式系统故障：

　　1. Leader故障

　　　　Leader出现故障需要选举一个新的Leader，该过程如图所示：

　　　　

 

 

　　　　1). 确认Leader出现故障

　　　　依赖心跳机制，Follower在一段时间内没有收到Leader的心跳信息（心跳间隔时间设置时间长不能及早发现故障，过短容易频繁触发Leader选举）。

         　　2). Leader选举

　　　　某个Follower服务器将自己维护的current_term_id（当前term的标志，表示自己的term值）+1并转换成候选人candidate，candidate发起投票，首先投自己一票，然后向其他节点并行发起RequertVoteRPC，等待其他节点回复（收到消息的节点指挥给发送消息方回投一票），如果收到大多数的回复，状态变成Leader。

　　　　　　选举需要在一个选举周期（不等长，称为term）中完成。

　　　　　　Term本质是一个逻辑时钟，每个RPC都会带上Term，用于检测过期。

　　　　　　发送方和接收方需要通过term保持偏序关系，如果接收到的消息的term比本地大，更新本地term，且状态是Leader或者Candidate是将自己状态变成Follower；如果比本地term小，拒绝RPC消息。

　　　　选举失败：不会出现Leader，Candidates将本地term+1，发起i虚拟的Leader选举，为了避免重复失败，每个Candidate的选举超时中期从150~300ms中随机选取。

　　　　RequestVoteRPC：选举过程中Candidate发出，用于拉取选票。

　　　　AppendEntriesRPC：Leader发起，用于心跳或复制日志。　　

 

　　2. 复制失败

　　　　Leader正常工作，某个Follower出现问题，Leader将一直给这个Follower发送AppendEntriesRPC消息，用于心跳或复制日志。

　　3. 日志不一致

　　　　新Leader选举产生，部分节点奔溃等现象，可能出现各个节点日志不一致。需要保证：确保投标过程只有拥有全部已提交日志的Candidate才能成为新的Leader。Leader需要强制Follower复制自己的日志

　　　　Raft支持日志压缩功能，参考https://zhuanlan.zhihu.com/p/334610146

 

参考资料

　　1 《分布式数据库原理、架构与实践》