分布式系统——Raft的分析

这是一篇来自研究生一年级的课程—— 《分布式系统》 的作业记录博客。
其主要是实现分布式系统中一致性的算法 Raft 。

论文链接如下：Raft算法英文原文地址
而中文翻译地址如下：中文翻译版本

首先我们大致通过一个动画过程来了解一下Raft。链接如下：Raft动画演示

---

1 分布式系统的一致性问题

我们假设有一个客户端 X 和一个服务器 Y ，然后 X 发送一个值给 Y，那么唯一的一个服务器就有了这个值。
但我们试想一下现实世界中，服务器的数量不可能只有一个，所以假设有 n 个服务器 Y[n] ，如何将客户端 X 发的值
让多个服务器都能一致起来，这就是需要探究的一个问题。

而在论文中提到，一致性算法是从复制状态机的背景下提出的。复制状态机图示如下：

复制状态机是基于复制日志来实现的，从上图可知，每一个服务器都存储一个包含一系列指令的日志。
客户端向一致性模块发送指令，一致性模块接收到指令然后增加到自己的日志中，它和其他服务器上的一致性模块进行通信来保证每一个服务器上的日志最终都以相同的顺序包含相同的请求。
一旦指令被正确的复制，每一个服务器的状态机按照日志顺序处理它们，然后输出结果被返回给客户端。

---

2 Raft 一致性算法

针对上面提到的分布式系统中一致性问题，Raft 便是一种可以实现一致性的协议（或者算法）。具体的讲，它就是用来管理上图复制状态机中复制日志的算法。

Raft通过选举一个leader，并赋予给它完全的管理复制日志权限来实现一致性。
leader从client接收日志条目，然后将日志条目复制到其他服务器中，并当可以保证安全性时告知其他的服务器需要应用日志条目到它们的状态机中。

这样我们就将 Raft 算法分成三部分：

• 领导选举
• 日志复制
• 安全性

具体内容下面分别来讲述。

---

2.1 Raft 基础知识

我们首先要了解一下Raft的一些基础知识。
首先 Raft 中的服务器一共有 3 个状态：

• Follower
• Candidate
• Leader

三个状态相互转化关系图如下：

也就是说，每个服务器起始的状态都是 Follower，然后开始选举之后，其中一个服务器称为 Candidate， 然后接受投票，若获得大部分的投票则称为 Leader，当然从 Candidate 和 Leader 状态都可以转化成 Follower状态。

而每一个时期，系统只能存在一个 Leader，如果大于1个，则错误，而其他的节点都是 Follower。Follower 都是被动的：他们不会发送任何请求，只是简单的响应来自 Leader 或者 Candidate 的请求。

---

2.2 Leader Election

领导选举是一种非常关键的步骤，也是实现Raft的第一个步骤。

过程如下：

首先系统中存在多个服务器，每个服务器都维护着自己的一个 election timeout，它是随机设定的（一般是150~300ms）。
如果一个 Follower 在其 election timeout 时间里都没有收到任何消息，则它认为系统中没有可用的 Leader，那么它会发起选举已选出新的Leader。

如下图所示，一共有 3 个服务器，每个服务器有一个 “进度条” 代表其 election timeout 。

一旦其中一个节点（下图显示的是节点A）的进度条走完，便成为 Candidate。此时A开始一个新的 election term，并为自己投票。

然后，节点A开始向其他节点发送 Request Vote（请求投票）RPC。

如果接收到A发送的RPC的其他节点还未投票过，则向 Candidate 投票， 并重置自己的 election timeout。

一旦 Candidate 获得了绝大多数 Follower 的投票，则它成为 Leader。 【小弟们都服我做老大】

最后，Leader 便开始按另一个 timeout —— heartbeat timeout 指定的间隔向所有的 Followers 发送 Append Entries（附加日志项）RPC。发送这个RPC是为了 【告知其他服务器我是老大，从而建立自己的权威并且阻止新的老大的产生】 。

Followers 再响应每个 Append Entries RPC。 【对，你就是老大，我们都是小弟，跟着你干】

这个选举任期将持续到一个 Follower 停止接受心跳并成为 Candidate。 【有小弟不接收老大的指挥，不干了，要反抗，自己想成为老大】 。

以上便是 Leader Election的细节。
总的来说，要开始一次选举过程，Follower 先要增加自己的当前任期号并且转换到 Candidate 状态。然后它再并行地向集群中的其他服务器节点发送 Request Vote RPCs 来为自己拉票。Candidate 会继续保持着当前状态直到以下三件事情之一发生：

• 情况一：它自己赢得了这次的选举，成为 Leader ；

  • 当一个候选人从整个集群的大多数服务器节点获得了针对同一个任期号的选票，那么他就赢得了这次选举并成为领导人。每一个服务器最多会在一个任期号里投出一张选票，按照先来先服务的原则，并确保只有一个Leader。

• 情况二：其他的服务器成为 Leader ；

• 情况三：一段时间之后没有任何一个获胜的人。

  • 如果有多个跟随者同时成为候选人，那么选票可能会被瓜分以至于没有候选人可以赢得大多数人的支持。当这种情况发生的时候，每一个候选人都会超时，然后通过增加当前任期号来开始一轮新的选举。然而，没有其他机制的话，选票可能会被无限的重复瓜分。

在等待投票的时候，候选人可能会从其他的服务器接收到声明它是领导人的附加日志项 RPC。如果这个领导人的 Term（包含在此次的 RPC中）大于等于候选人的currentTerm，那么候选人会承认领导人并回到跟随者状态。 相反，如果此次 RPC 中的 Term 比自己的currentTerm 还小，那么候选人就会拒绝这次的 RPC 并且继续保持候选人状态。 【你强我就服你，你继续上，我继续成为小弟。但如果我强，我就不服，我就要反抗】