分布式系列分布式系统架构Raft 算法实现原理

Posted 2021-04-27 程序猿小秘圈

概述

说到分布式一致性算法，可能大多数人的第一反应是paxos算法。但是paxos算法一直以来都被认为是难以理解，难以实现。So...Stanford的Diego Ongaro和John Ousterhout提出了Raft算法，这是一个更容易理解的分布式一致性算法，在算法的论文中，不仅详细描述了算法，甚至给出了RPC接口定义和伪代码，这显然更加容易应用到工程实践中。这两个算法在一定程度上是相通的，个人觉得Raft是加了更多约束的Poxas衍生算法。

log entry：每个entry包含状态机的command term：用来标示是那一轮选举，每次选举都会递增 index：log entry的标示，term和index唯一标示一个entry commit：将log entry应用到状态机中

服务器状态

图中是Raft中的Repliated status machine architecture，每个server维护一份log，在这些log中记录的是应用到state machine中的commands。各个服务器中的状态机被apply一致的log的命令，从而保持集群中服务器的最终的一致性。

如下图所示，在Raft算法中，服务器有三种状态：Follower, Candidate, Leader。

在服务器刚启动的时候，都属于Follower状态，它接收Leader的RPC请求。如果经过一定时间没有发现Leader，那么它转换到Candidate状态，进而开始Leader的选举。

Candidate发现集群中已经有Leader的时候便会转换到Follower状态，又或者它在选举中获得大多数节点(majority of servers)的选票变成Leader。

Leader只有在发现比自己高term的Leader的时候才会转换成Follower。

Raft 协议的易理解性描述

虽然 Raft 的论文比 Paxos 简单版论文还容易读了，但论文依然发散的比较多，相对冗长。读完后掩卷沉思觉得还是整理一下才会更牢靠，变成真正属于自己的。这里我就借助前面黑白棋落子里第一种极简思维来描述和概念验证下 Raft 协议的工作方式。

在一个由 Raft 协议组织的集群中有三类角色：

Leader(领袖)

Follower(群众)

Candidate(候选人)

就像一个民主社会，领袖由民众投票选出。刚开始没有领袖，所有集群中的参与者都是群众，那么首先开启一轮大选，在大选期间所有群众都能参与竞选，这时所有群众的角色就变成了候选人，民主投票选出领袖后就开始了这届领袖的任期，然后选举结束，所有除领袖的候选人又变回群众角色服从领袖领导。这里提到一个概念「任期」，用术语 Term 表达。关于 Raft 协议的核心概念和术语就这么多而且和现实民主制度非常匹配，所以很容易理解。三类角色的变迁图如下，结合后面的选举过程来看很容易理解。

Leader 选举过程

在极简的思维下，一个最小的 Raft 民主集群需要三个参与者(如下图：A、B、C)，这样才可能投出多数票。初始状态 ABC 都是 Follower，然后发起选举这时有三种可能情形发生。下图中前二种都能选出 Leader，第三种则表明本轮投票无效(Split Votes)，每方都投给了自己，结果没有任何一方获得多数票。之后每个参与方随机休息一阵(Election Timeout)重新发起投票直到一方获得多数票。这里的关键就是随机 timeout，最先从 timeout 中恢复发起投票的一方向还在 timeout 中的另外两方请求投票，这时它们就只能投给对方了，很快达成一致。

选出 Leader 后，Leader 通过定期向所有 Follower 发送心跳信息维持其统治。若 Follower 一段时间未收到 Leader 的心跳则认为 Leader 可能已经挂了再次发起选主过程。

Leader 节点对一致性的影响

Raft 协议强依赖 Leader 节点的可用性来确保集群数据的一致性。数据的流向只能从 Leader 节点向 Follower 节点转移。当 Client 向集群 Leader 节点提交数据后，Leader 节点接收到的数据处于未提交状态(Uncommitted)，接着 Leader 节点会并发向所有 Follower 节点复制数据并等待接收响应，确保至少集群中超过半数节点已接收到数据后再向 Client 确认数据已接收。一旦向 Client 发出数据接收 Ack 响应后，表明此时数据状态进入已提交(Committed)，Leader 节点再向 Follower 节点发通知告知该数据状态已提交。

在这个过程中，主节点可能在任意阶段挂掉，看下 Raft 协议如何针对不同阶段保障数据一致性的。

1. 数据到达 Leader 节点前

这个阶段 Leader 挂掉不影响一致性

2. 数据到达 Leader 节点，但未复制到 Follower 节点

这个阶段 Leader 挂掉，数据属于未提交状态，Client 不会收到 Ack 会认为超时失败可安全发起重试。Follower 节点上没有该数据，重新选主后 Client 重试重新提交可成功。原来的 Leader 节点恢复后作为 Follower 加入集群重新从当前任期的新 Leader 处同步数据，强制保持和 Leader 数据一致。

3. 数据到达 Leader 节点，成功复制到 Follower 所有节点，但还未向 Leader 响应接收

这个阶段 Leader 挂掉，虽然数据在 Follower 节点处于未提交状态(Uncommitted)但保持一致，重新选出 Leader 后可完成数据提交，此时 Client 由于不知到底提交成功没有，可重试提交。针对这种情况 Raft 要求 RPC 请求实现幂等性，也就是要实现内部去重机制。

4. 数据到达 Leader 节点，成功复制到 Follower 部分节点，但还未向 Leader 响应接收

这个阶段 Leader 挂掉，数据在 Follower 节点处于未提交状态(Uncommitted)且不一致，Raft 协议要求投票只能投给拥有最新数据的节点。所以拥有最新数据的节点会被选为 Leader 再强制同步数据到 Follower，数据不会丢失并最终一致。

如果在这一过程中，发生了网络分区或者网络通信故障，使得Leader不能访问大多数Follwers了，那么Leader只能正常更新它能访问的那些Follower服务器，而大多数的服务器Follower因为没有了Leader，他们重新选举一个候选者作为Leader，然后这个Leader作为代表于外界打交道，如果外界要求其添加新的日志，这个新的Leader就按上述步骤通知大多数Followers，如果这时网络故障修复了，那么原先的Leader就变成Follower，在失联阶段这个老Leader的任何更新都不能算commit，都回滚，接受新的Leader的新的更新。