分布式强一致算法 —— Raft算法

背景

  Paxos算法是最早的强一致性算法，1990年被Leslie Lamport提出，但是由于其难以理解和实现，导致没有被广泛使用。因此，2013年Raft算法被提出，功能与Paxos算法相同，更易于理解，实现简单，因此迅速被广泛推广使用，已经成为当前主流的强一致性算法。（从CAP角度，Raft算法选择了CP，舍弃了A，选主期间会出现短暂的不可用）

Raft基础

Term

  Term为逻辑时钟，用来比较数据的新旧、Leader的新老、请求是否过时等，每次选举产生新的Term，如下图所示：

日志

• Entry：日志文件中的每条记录，由Term和命令组成；
• Index：每条记录的索引或偏移量；

角色/状态

• Leader：主节点，负责客户端请求处理，以及集群节点间数据同步；
• Follower：从节点，数据备份；
• Candidate：候选节点，选主时的临时状态；

Raft算法

  Raft算法可以分为Leader Election选主和Log Replication日志复制两部分。算法的整体流程是：首先，集群中的节点选举出一个主节点；然后，由主节点处理客户端的所有请求，并负责将请求复制到所有的从节点，保证节点间的数据一致性。

Leader Election

Raft算法通过心跳机制来进行选主，具体过程如下：

1. 节点启动时，初始状态为Follower，并开始倒计时。如果Election Timeout时间内，收到Leader的心跳，则重新开始计时；如果超时，则发起选主；
2. 开始选主后，节点的状态从Follower转变为Candidate，当前任期加1，向集群所有节点发送投票请求（包括节点本身）；

# 投票信息
Term：候选节点的所在的任期；
CandidateId：候选节点ID；
LastLogIndex：候选节点最后一条日志的索引；
LastLogTerm：候选节点最后一条日志的任期；

4. 集群中的其它节点接受到投票请求后，会根据投票信息进行判断：如果能同时满足1）投票中的任期大于等于当前节点的任期；2）对于投票中的任期，当前节点还未投票；3）投票中的数据索引大于等于当前节点数据索引，则同意投票请求；（投票规则）
5. 如果某个节点的投票请求被过半节点同意，那么该节点成为新的Leader，向集群其它节点发送心跳阻止新的选主；如果投票期间，接收到合法Leader（任期大于等于当前节点任期）的心跳，则节点状态从Candidate转为Follower；如果超时或者没有超过半数，则任期加1，重新发起投票；
   

Log Replication

Leader节点选出之后，会负责Client所有请求以及节点间的数据同步，具体过程如下：

1. Client发送请求到Leader节点，如果其它节点接收到会转发到Leader节点；
2. Leader节点接收到请求后，首先将请求命令写入本地日志（未提交状态），然后发日志复制命令送至集群其它节点；
3. 其它节点接收到日志复制命令后，会根据命令信息进行判断：如果根据Index和Term能找到本地记录则写入，否则拒绝；
4. 如果Leader节点接收到大部分节点的ACK，则认为日志复制成功，本地数据状态变为Commited，给客户端返回ACK，并发送Commit请求到集群其它节点；如果Leader节点接收到拒绝请求，会减小Index，继续重试直到找到匹配的记录，然后开始复制；

  不一致处理规则： Raft算法中，Leader节点日志只会追加，没有修改和删除，并且数据流向永远都是从Leader到其它节点（单向的），如果发现不一致，处理规则就是强制其它节点复制Leader数据，覆盖不一致数据。

参考

1. Github地址
2. Raft为什么是更易理解的分布式一致性算法