• 本文已获得原作者的独家授权，有想转载的朋友们可以在后台联系我申请开白哦！
• PS：欢迎掘友们向我投稿哦，被采用的文章还可以送你掘金精美周边！

本文包含 3 个内容：首先介绍什么是线性一致性；其次分析 “写主读从”、“写主读主” 均无法保障线性一致性的原因（是的没错，写主读主也不灵！），并讲述基于 Raft 实现系统时保证线性一致性的方法；最后介绍在不破坏线性一致性的前提下，对 Raft 做读性能优化的具体策略。

笔者期望帮助读者深入理解 Raft 协议，并能付诸于工程实践中，同时解读不易理解或易误解的关键点，看完不懂你来拍我😜 。该系列从原理、源码、实践三个部分讲解 Raft 原理及算法：

• 原理部分结合 Raft 论文讲解 Raft 算法原理，分篇遵循 Raft 的模块化思想，分别讲解 Leader election、Log replication、Safety、Cluster membership change、Log compaction 等。
• 源码部分分析 hashicorp/raft 来学习一个工业界的 Raft 实现（hashicorp/raft 是 Consul 的底层依赖）。
• 实践部分基于 hashicorp/raft 实现一个简单的分布式 kv 存储，作为收尾。

系列历史文章链接：

• Raft 协议实战系列（一）—— 基本概念
• Raft 协议实战系列（二）—— 选主
• Raft 协议实战系列（三）—— 日志复制
• Raft 协议实战系列（四）—— 安全性
• Raft 协议实战系列（五）—— 集群成员变更与日志压缩

1.什么是线性一致性？

在该系列首篇《基本概念》中我们提到过：在分布式系统中，为了消除单点提高系统可用性，通常会使用副本来进行容错，但这会带来另一个问题，即如何保证多个副本之间的一致性。

什么是一致性？所谓一致性有很多种模型，不同的模型都是用来评判一个并发系统正确与否的不同程度的标准。而我们今天要讨论的是强一致性（Strong Consistency）模型，也就是线性一致性（Linearizability），我们经常听到的 CAP 理论中的 C 指的就是它。

其实我们在第一篇就已经简要描述过何为线性一致性：

所谓的强一致性并不是指集群中所有节点在任一时刻的状态必须完全一致，而是指一个目标，即让一个分布式系统看起来只有一个数据副本，并且读写操作都是原子的，这样应用层就可以忽略系统底层多个数据副本间的同步问题。也就是说，我们可以将一个强一致性（线性一致性）分布式系统当成一个整体，一旦某个客户端成功的执行了写操作，那么所有客户端都一定能读出刚刚写入的值。即使发生网络分区故障，或者少部分节点发生异常，整个集群依然能够像单机一样提供服务。

“像单机一样提供服务” 从感官上描述了一个线性一致性系统应该具备的特性，那么我们该如何判断一个系统是否具备线性一致性呢？通俗来说就是不能读到旧（stale）数据，但具体分为两种情况：

• 对于调用时间存在重叠（ 并发）的请求，生效顺序可以任意确定。
• 对于调用时间存在先后关系（ 偏序）的请求，后一个请求不能违背前一个请求确定的结果。

只要根据上述两条规则即可判断一个系统是否具备线性一致性。下面我们来看一个非线性一致性系统的例子。

本节例图均来自《Designing Data-Intensive Application》，作者 Martin Kleppmann

如上图所示，裁判将世界杯的比赛结果写入了主库，Alice 和 Bob 所浏览的页面分别从两个不同的从库读取，但由于存在主从同步延迟，Follower 2 的本次同步延迟高于 Follower 1，最终导致 Bob 听到了 Alice 的惊呼后刷新页面看到的仍然是比赛进行中。

虽然线性一致性的基本思想很简单，只是要求分布式系统看起来只有一个数据副本，但在实际中还是有很多需要关注的点，我们继续看几个例子。

上图从客户端的外部视角展示了多个用户同时请求读写一个系统的场景，每条柱形都是用户发起的一个请求，左端是请求发起的时刻，右端是收到响应的时刻。由于网络延迟和系统处理时间并不固定，所以柱形长度并不相同。

• x 最初的值为 0，Client C 在某个时间段将 x 写为 1。
• Client A 第一个读操作位于 Client C 的写操作之前，因此必须读到原始值 0。
• Client A 最后一个读操作位于 Client C 的写操作之后，如果系统是线性一致的，那么必须读到新值 1。
• 其它与写操作重叠的所有读操作，既可能返回 0，也可能返回 1，因为我们并不清楚写操作在哪个时间段内哪个精确的点生效，这种情况下读写是 并发的。

仅仅是这样的话，仍然不能说这个系统满足线性一致。假设 Client B 的第一次读取返回了 1，如果 Client A 的第二次读取返回了 0，那么这种场景并不破坏上述规则，但这个系统仍不满足线性一致，因为客户端在写操作执行期间看到 x 的值在新旧之间来回翻转，这并不符合我们期望的 “看起来只有一个数据副本” 的要求。

所以我们需要额外添加一个约束，如下图所示。

在任何一个客户端的读取返回新值后，所有客户端的后续读取也必须返回新值，这样系统便满足线性一致了。

我们最后来看一个更复杂的例子，继续细化这个时序图。

如上图所示，每个读写操作在某个特定的时间点都是原子性的生效，我们在柱形中用竖线标记出生效的时间点，将这些标记按时间顺序连接起来。那么线性一致的要求就是：连线总是按照时间顺序向右移动，而不会向左回退。所以这个连线结果必定是一个有效的寄存器读写序列：任何客户端的每次读取都必须返回该条目最近一次写入的值。

线性一致性并非限定在分布式环境下，在单机单核系统中可以简单理解为 “寄存器” 的特性。

Client B 的最后一次读操作并不满足线性一致，因为在连线向右移动的前提下，它读到的值是错误的（因为 Client A 已经读到了由 Client C 写入的 4）。此外这张图里还有一些值得指出的细节点，可以解开很多我们在使用线性一致系统时容易产生的误解：

• Client B 的首个读请求在 Client D 的首个写请求和 Client A 的首个写请求之前发起，但最终读到的却是最后由 Client A 写成功之后的结果。
• Client A 尚未收到首个写请求成功的响应时，Client B 就读到了 Client A 写入的值。

上述现象在线性一致的语义下都是合理的。

所以线性一致性（Linearizability）除了叫强一致性（Strong Consistency）外，还叫做原子一致性（Atomic Consistency）、立即一致性（Immediate Consistency）或外部一致性（External Consistency），这些名字看起来都是比较贴切的。

2.Raft 线性一致性读

在了解了什么是线性一致性之后，我们将其与 Raft 结合来探讨。首先需要明确一个问题，使用了 Raft 的系统都是线性一致的吗？不是的，Raft 只是提供了一个基础，要实现整个系统的线性一致还需要做一些额外的工作。

假设我们期望基于 Raft 实现一个线性一致的分布式 kv 系统，让我们从最朴素的方案开始，指出每种方案存在的问题，最终使整个系统满足线性一致性。

2.1 写主读从缺陷分析

写操作并不是我们关注的重点，如果你稍微看了一些理论部分就应该知道，所有写操作都要作为提案从 leader 节点发起，当然所有的写命令都应该简单交给 leader 处理。真正关键的点在于读操作的处理方式，这涉及到整个系统关于一致性方面的取舍。

在该方案中我们假设读操作直接简单地向 follower 发起，那么由于 Raft 的 Quorum 机制（大部分节点成功即可），针对某个提案在某一时间段内，集群可能会有以下两种状态：

• 某次写操作的日志尚未被复制到一少部分 follower，但 leader 已经将其 commit。
• 某次写操作的日志已经被同步到所有 follower，但 leader 将其 commit 后，心跳包尚未通知到一部分 follower。

以上每个场景客户端都可能读到过时的数据，整个系统显然是不满足线性一致的。

2.2 写主读主缺陷分析

在该方案中我们限定，所有的读操作也必须经由 leader 节点处理，读写都经过 leader 难道还不能满足线性一致？是的！！ 并且该方案存在不止一个问题！！

问题一：状态机落后于 committed log 导致脏读

回想一下前文讲过的，我们在解释什么是 commit 时提到了写操作什么时候可以响应客户端：

所谓 commit 其实就是对日志简单进行一个标记，表明其可以被 apply 到状态机，并针对相应的客户端请求进行响应。

也就是说一个提案只要被 leader commit 就可以响应客户端了，Raft 并没有限定提案结果在返回给客户端前必须先应用到状态机。所以从客户端视角当我们的某个写操作执行成功后，下一次读操作可能还是会读到旧值。

这个问题的解决方式很简单，在 leader 收到读命令时我们只需记录下当前的 commit index，当 apply index 追上该 commit index 时，即可将状态机中的内容响应给客户端。

问题二：网络分区导致脏读

假设集群发生网络分区，旧 leader 位于少数派分区中，而且此刻旧 leader 刚好还未发现自己已经失去了领导权，当多数派分区选出了新的 leader 并开始进行后续写操作时，连接到旧 leader 的客户端可能就会读到旧值了。

因此，仅仅是直接读 leader 状态机的话，系统仍然不满足线性一致性。

2.3 Raft Log Read

为了确保 leader 处理读操作时仍拥有领导权，我们可以将读请求同样作为一个提案走一遍 Raft 流程，当这次读请求对应的日志可以被应用到状态机时，leader 就可以读状态机并返回给用户了。

这种读方案称为 Raft Log Read，也可以直观叫做 Read as Proposal。

为什么这种方案满足线性一致？因为该方案根据 commit index 对所有读写请求都一起做了线性化，这样每个读请求都能感知到状态机在执行完前一写请求后的最新状态，将读写日志一条一条的应用到状态机，整个系统当然满足线性一致。但该方案的缺点也非常明显，那就是性能差，读操作的开销与写操作几乎完全一致。而且由于所有操作都线性化了，我们无法并发读状态机。

3. Raft 读性能优化

接下来我们将介绍几种优化方案，它们在不违背系统线性一致性的前提下，大幅提升了读性能。

3.1 Read Index

与 Raft Log Read 相比，Read Index 省掉了同步 log 的开销，能够大幅提升读的吞吐，一定程度上降低读的时延。其大致流程为：

1. Leader 在收到客户端读请求时，记录下当前的 commit index，称之为 read index。
2. Leader 向 followers 发起一次心跳包，这一步是为了确保领导权，避免网络分区时少数派 leader 仍处理请求。
3. 等待状态机 至少应用到 read index（即 apply index 大于等于 read index）。
4. 执行读请求，将状态机中的结果返回给客户端。

这里第三步的 apply index 大于等于 read index 是一个关键点。因为在该读请求发起时，我们将当时的 commit index 记录了下来，只要使客户端读到的内容在该 commit index 之后，那么结果一定都满足线性一致（如不理解可以再次回顾下前文线性一致性的例子以及 2.2 中的问题一）。

3.2 Lease Read

与 Read Index 相比，Lease Read 进一步省去了网络交互开销，因此更能显著降低读的时延。

基本思路是 leader 设置一个比选举超时（Election Timeout）更短的时间作为租期，在租期内我们可以相信其它节点一定没有发起选举，集群也就一定不会存在脑裂，所以在这个时间段内我们直接读主即可，而非该时间段内可以继续走 Read Index 流程，Read Index 的心跳包也可以为租期带来更新。

Lease Read 可以认为是 Read Index 的时间戳版本，额外依赖时间戳会为算法带来一些不确定性，如果时钟发生漂移会引发一系列问题，因此需要谨慎的进行配置。

3.3 Follower Read

在前边两种优化方案中，无论我们怎么折腾，核心思想其实只有两点：

• 保证在读取时的最新 commit index 已经被 apply。
• 保证在读取时 leader 仍拥有领导权。

这两个保证分别对应 2.2 节所描述的两个问题。

其实无论是 Read Index 还是 Lease Read，最终目的都是为了解决第二个问题。换句话说，读请求最终一定都是由 leader 来承载的。

那么读 follower 真的就不能满足线性一致吗？其实不然，这里我们给出一个可行的读 follower 方案：Follower 在收到客户端的读请求时，向 leader 询问当前最新的 commit index，反正所有日志条目最终一定会被同步到自己身上，follower 只需等待该日志被自己 commit 并 apply 到状态机后，返回给客户端本地状态机的结果即可。这个方案叫做 Follower Read。

注意：Follower Read 并不意味着我们在读过程中完全不依赖 leader 了，在保证线性一致性的前提下完全不依赖 leader 理论上是不可能做到的。

至此，我们 Raft 系列的原理篇就已经完结了。

如果你一路坚持看了下来，相信已经对 Raft 算法的理论有了深刻的理解。当然，理论和工程实践之间存在的鸿沟可能比想象的还要大，实践中有众多的细节问题需要去面对。在后续的源码分析及实践篇中，我们会结合代码讲解到许多理论部分没有提到的这些细节点，并介绍基础架构设计的诸多经验，敬请期待！