一篇文章搞懂Raft共识算法

Posted 2021-04-27 加班狗的博客

什么是Raft？

raft是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。大家应该都听过大名鼎鼎的Paxos，因为其理解的难度，raft算法的发明者转而研究出了raft算法。Raft增强了可理解性，在性能、可靠性、可用性方面是不输于Paxos的。

raft是一种leader-based的共识算法（consensus algorithm），在部分节点故障、网络延时、网络分割的情况下，多个节点对某个事情达成一致。在分布式系统中，共识算法更多用于提高系统的容错性。

Raft节点

raft协议中，一个节点任一时刻处于以下三个状态之一：leader、follower、candidate

所有节点启动时都是follower状态，在一段时间内如果没有收到来自leader的心跳，follower状态的节点会切换到candidate，发起选举。如果选举成功，则切换到leader状态，如果发现其他节点选举成功，则主动切换到follower。leader会不停的给follower发心跳消息，表明自己的存活状态。如果leader出现故障，一段时间后没有收到leader心跳的follower会转换成candidate，重新选出leader。

选举过程

term：可以理解为任期，leader的履职期。充当了逻辑时钟的作用，接收到leader的心跳，可以根据当前节点的term判断是否是最新的leader。

如果follower在election timeout内没有收到来自leader的心跳，则会主动发起选举。选举过程如下

1）增加节点本地的current term，切换到candidate状态

2）投自己一票，并行给其他节点发送 RequestVote请求

3）等待其他节点的回复

在这个过程中，会收到来自其他节点的消息，可能出现以下三种结果

1）收到majority（大多数节点）的投票（含自己的一票），则赢得选举，成为leader，立刻给所有节点发消息，避免其余节点触发新的选举。

2）被告知别人已当选，对比term（不低于当前节点的term），那么自行切换到follower。

3）一段时间内没有收到majority投票，则保持candidate状态，超时之后重新发出选举。

log replication

客户端将请求发送到leader，leader来调度这些并发请求的顺序，并且保证leader与followers状态的一致性。

raft基于复制状态机（Replicated state machines），即将这些请求以及执行顺序告知followers。leader和followers以相同的顺序来执行这些请求，保证状态一致。raft中，leader将客户端请求（command）封装到一个个log entry，logs由顺序编号的log entry组成 ，每个log entry除了包含command，还包含产生该log entry时的leader term。

将这些log entries复制（replicate）到所有follower节点，然后大家按相同顺序应用（apply）log entry中的command。leader只需要日志被复制到大多数节点即可向客户端返回，一旦向客户端返回成功消息，那么系统就必须保证log（其实是log所包含的command）在任何异常的情况下都不会发生回滚。

以下为请求的流程

1）leader append log entry

2）leader issue AppendEntries RPC in parallel

3）leader wait for majority response

4）leader apply entry to state machine

5）leader reply to client

6）leader notify follower apply log