Question

​ 在 最终一致 的数据库，如果你在同一时刻问两个不同副本相同的问题，可能会得到两个不同的答案。这很让人困惑。如果数据库可以提供只有一个副本的假象（即，只有一个数据副本），那么事情就简单太多了。那么每个客户端都会有相同的数据视图，且不必担心复制滞后了。

​ 这就是 线性一致性（linearizability） 背后的想法【6】（也称为 原子一致性（atomic consistency） 【7】， 强一致性（strong consistency） ， 立即一致性（immediate consistency） 或 外部一致性（external consistency ） 【8】）。线性一致性的精确定义相当微妙，我们将在本节的剩余部分探讨它。但是基本的想法是让一个系统看起来好像只有一个数据副本，而且所有的操作都是原子性的。有了这个保证，即使实际中可能有多个副本，应用也不需要担心它们。

​ 在一个线性一致的系统中，只要一个客户端成功完成写操作，所有客户端从数据库中读取数据必须能够看到刚刚写入的值。维护数据的单个副本的错觉是指，系统能保障读到的值是最近的，最新的，而不是来自陈旧的缓存或副本。换句话说，线性一致性是一个 新鲜度保证（recency guarantee） 。为了阐明这个想法，我们来看看一个非线性一致系统的例子。

图 9-1 这个系统是非线性一致的，导致了球迷的困惑

​ 图 9-1 展示了一个关于体育网站的非线性一致例子【9】。Alice 和 Bob 正坐在同一个房间里，都盯着各自的手机，关注着 2014 年 FIFA 世界杯决赛的结果。在最后得分公布后，Alice 刷新页面，看到宣布了获胜者，并兴奋地告诉 Bob。Bob 难以置信地刷新了自己的手机，但他的请求路由到了一个落后的数据库副本上，手机显示比赛仍在进行。

​ 如果 Alice 和 Bob 在同一时间刷新并获得了两个不同的查询结果，也许就没有那么令人惊讶了。因为他们不知道服务器处理他们请求的精确时刻。然而 Bob 是在听到 Alice 惊呼最后得分 之后 ，点击了刷新按钮（启动了他的查询），因此他希望查询结果至少与爱丽丝一样新鲜。但他的查询返回了陈旧结果，这一事实违背了线性一致性的要求。

什么使得系统线性一致？

​ 线性一致性背后的基本思想很简单：使系统看起来好像只有一个数据副本。然而确切来讲，实际上有更多要操心的地方。为了更好地理解线性一致性，让我们再看几个例子。

​ 图 9-2 显示了三个客户端在线性一致数据库中同时读写相同的键 x 。在分布式系统文献中， x 被称为 寄存器（register） ，例如，它可以是键值存储中的一个 键 ，关系数据库中的一 行 ，或文档数据库中的一个 文档 。

图 9-2 如果读取请求与写入请求并发，则可能会返回旧值或新值

​ 为了简单起见， 图 9-2 采用了用户请求的视角，而不是数据库内部的视角。每个柱都是由客户端发出的请求，其中柱头是请求发送的时刻，柱尾是客户端收到响应的时刻。因为网络延迟变化无常，客户端不知道数据库处理其请求的精确时间——只知道它发生在发送请求和接收响应的之间的某个时刻。ⁱ

ⁱ. 这个图的一个微妙的细节是它假定存在一个全局时钟，由水平轴表示。即使真实的系统通常没有准确的时钟（参阅 不可靠的时钟 ），但这种假设是允许的：为了分析分布式算法，我们可以假设一个精确的全局时钟存在，不过算法无法访问它【47】。算法只能看到由石英振荡器和 NTP 产生的实时逼近。 ↩

在这个例子中，寄存器有两种类型的操作：

• $ read(x)⇒v$表示客户端请求读取寄存器 x 的值，数据库返回值 v 。

• $write(x,v)⇒r$ 表示客户端请求将寄存器 x 设置为值 v ，数据库返回响应 r （可能正确，可能错误）。

在 图 9-2 中， x 的值最初为 0 ，客户端 C 执行写请求将其设置为 1 。发生这种情况时，客户端 A 和 B 反复轮询数据库以读取最新值。 A 和 B 的请求可能会收到怎样的响应？

• 客户端 A 的第一个读操作，完成于写操作开始之前，因此必须返回旧值 0 。
• 客户端 A 的最后一个读操作，开始于写操作完成之后。如果数据库是线性一致性的，它必然返回新值 1 ：因为读操作和写操作一定是在其各自的起止区间内的某个时刻被处理。如果在写入结束后开始读取，则必须在写入之后处理读取，因此它必须看到写入的新值。
• 与写操作在时间上重叠的任何读操作，可能会返回 0 或 1 ，因为我们不知道读取时，写操作是否已经生效。这些操作是 并发（concurrent） 的。

但是，这还不足以完全描述线性一致性：如果与写入同时发生的读取可以返回旧值或新值，那么读者可能会在写入期间看到数值在旧值和新值之间来回翻转。这不是我们所期望的仿真 单一数据副本 的系统。ⁱⁱ

ⁱⁱ. 如果读取（与写入同时发生时）可能返回旧值或新值，则称该寄存器为 常规寄存器（regular register） 【7,25】 ↩

为了使系统线性一致，我们需要添加另一个约束，如 图 9-3 所示

图 9-3 任何一个读取返回新值后，所有后续读取（在相同或其他客户端上）也必须返回新值。

​ 在一个线性一致的系统中，我们可以想象，在 x 的值从 0 自动翻转到 1 的时候（在写操作的开始和结束之间）必定有一个时间点。因此，如果一个客户端的读取返回新的值 1 ，即使写操作尚未完成，所有后续读取也必须返回新值。

​ 图 9-3 中的箭头说明了这个时序依赖关系。客户端 A 是第一个读取新的值 1 的位置。在 A 的读取返回之后，B 开始新的读取。由于 B 的读取严格在发生于 A 的读取之后，因此即使 C 的写入仍在进行中，也必须返回 1 。 （与 图 9-1 中的 Alice 和 Bob 的情况相同：在 Alice 读取新值之后，Bob 也希望读取新的值。）

​ 我们可以进一步细化这个时序图，展示每个操作是如何在特定时刻原子性生效的。 图 9-4 显示了一个更复杂的例子【10】。

在 图 9-4 中，除了读写之外，还增加了第三种类型的操作：

• $cas(x, v{old}, v{new})⇒r$ 表示客户端请求进行原子性的 比较与设置 操作。如果寄存器 $x$ 的当前值等于 $v{old}$ ，则应该原子地设置为 $v{new}$ 。如果 $x≠v_{old}$ ，则操作应该保持寄存器不变并返回一个错误。 $r$ 是数据库的响应（正确或错误）。

图 9-4 中的每个操作都在我们认为执行操作的时候用竖线标出（在每个操作的条柱之内）。这些标记按顺序连在一起，其结果必须是一个有效的寄存器读写序列（ 每次读取都必须返回最近一次写入设置的值 ）。

​ 线性一致性的要求是，操作标记的连线总是按时间（从左到右）向前移动，而不是向后移动。这个要求确保了我们之前讨论的新鲜性保证：一旦新的值被写入或读取，所有后续的读都会看到写入的值，直到它被再次覆盖。

图 9-4 可视化读取和写入看起来已经生效的时间点。 B 的最后读取不是线性一致性的

图 9-4 中有一些有趣的细节需要指出：

• 第一个客户端 B 发送一个读取 x 的请求，然后客户端 D 发送一个请求将 x 设置为 0 ，然后客户端 A 发送请求将 x 设置为 1 。尽管如此，返回到 B 的读取值为 1 （由 A 写入的值）。这是可以的：这意味着数据库首先处理 D 的写入，然后是 A 的写入，最后是 B 的读取。虽然这不是请求发送的顺序，但这是一个可以接受的顺序，因为这三个请求是并发的。也许 B 的读请求在网络上略有延迟，所以它在两次写入之后才到达数据库。
• 在客户端 A 从数据库收到响应之前，客户端 B 的读取返回 1 ，表示写入值 1 已成功。这也是可以的：这并不意味着在写之前读到了值，这只是意味着从数据库到客户端 A 的正确响应在网络中略有延迟。
• 此模型不假设有任何事务隔离：另一个客户端可能随时更改值。例如，C 首先读取 1 ，然后读取 2 ，因为两次读取之间的值由 B 更改。可以使用原子 比较并设置（cas） 操作来检查该值是否未被另一客户端同时更改：B 和 C 的 cas 请求成功，但是 D 的 cas 请求失败（在数据库处理它时， x 的值不再是 0 ）。
• 客户 B 的最后一次读取（阴影条柱中）不是线性一致性的。 该操作与 C 的 cas 写操作并发（它将 x 从 2 更新为 4 ）。在没有其他请求的情况下，B 的读取返回 2 是可以的。然而，在 B 的读取开始之前，客户端 A 已经读取了新的值 4 ，因此不允许 B 读取比 A 更旧的值。再次，与 图 9-1 中的 Alice 和 Bob 的情况相同。

  这就是线性一致性背后的直觉。 正式的定义【6】更准确地描述了它。 通过记录所有请求和响应的时序，并检查它们是否可以排列成有效的顺序，测试一个系统的行为是否线性一致性是可能的（尽管在计算上是昂贵的）【11】。

线性一致性与可序列化

线性一致性 容易和 可序列化 相混淆，因为两个词似乎都是类似 可以按顺序排列 的东西。但它们是两种完全不同的保证，区分两者非常重要：

可序列化

可序列化（Serializability） 是事务的隔离属性，每个事务可以读写多个对象（行，文档，记录）——参阅 单对象和多对象操作 。它确保事务的行为，与它们按照 某种 顺序依次执行的结果相同（每个事务在下一个事务开始之前运行完成）。这种执行顺序可以与事务实际执行的顺序不同。【12】。

线性一致性

线性一致性（Linearizability） 是读取和写入寄存器（单个对象）的 新鲜度保证 。它不会将操作组合为事务，因此它也不会阻止写偏差等问题（参阅 写偏差和幻读 ），除非采取其他措施（例如 物化冲突 ）。

一个数据库可以提供可串行性和线性一致性，这种组合被称为严格的可串行性或强的 单副本强可串行性（strong-1SR） 【4,13】。基于两阶段锁定的可串行化实现（参见 两阶段锁定（2PL） 一节）或 实际串行执行 （参见第 实际串行执行 ）通常是线性一致性的。

但是，可序列化的快照隔离（参见 可序列化的快照隔离（SSI） ）不是线性一致性的：按照设计，它可以从一致的快照中进行读取，以避免锁定读者和写者之间的争用。一致性快照的要点就在于 它不会包括比快照更新的写入 ，因此从快照读取不是线性一致性的。

依赖线性一致性

​ 线性一致性在什么情况下有用？观看体育比赛的最后得分可能是一个轻率的例子：过了几秒钟的结果不可能在这种情况下造成任何真正的伤害。然而对于少数领域，线性一致性是系统正确工作的一个重要条件。

锁定和领导选举

​ 一个使用单主复制的系统，需要确保领导真的只有一个，而不是几个（脑裂）。一种选择领导者的方法是使用锁：每个节点在启动时尝试获取锁，成功者成为领导者【14】。不管这个锁是如何实现的，它必须是线性一致的：所有节点必须就哪个节点拥有锁达成一致，否则就没用了。

​ 诸如 Apache ZooKeeper 【15】和 etcd 【16】之类的协调服务通常用于实现分布式锁和领导者选举。它们使用一致性算法，以容错的方式实现线性一致的操作（在本章后面的 容错共识 中讨论此类算法）ⁱⁱⁱ 。还有许多微妙的细节来正确地实现锁和领导者选择（例如，参阅 领导者和锁 中的屏蔽问题），而像 Apache Curator 【17】这样的库则通过在 ZooKeeper 之上提供更高级别的配方来提供帮助。但是，线性一致性存储服务是这些协调任务的基础。

ⁱⁱⁱ. 严格地说，ZooKeeper 和 etcd 提供线性一致性的写操作，但读取可能是陈旧的，因为默认情况下，它们可以由任何一个副本服务。你可以选择请求线性一致性读取：etcd 调用这个法定读取【16】，而在 ZooKeeper 中，你需要在读取【15】之前调用 sync() 。参阅 使用全局顺序广播实现线性存储 。 ↩

​ 分布式锁也在一些分布式数据库（如 Oracle Real Application Clusters（RAC）【18】）中以更细的粒度使用。 RAC 对每个磁盘页面使用一个锁，多个节点共享对同一个磁盘存储系统的访问权限。由于这些线性一致的锁处于事务执行的关键路径上，RAC 部署通常具有用于数据库节点之间通信的专用集群互连网络。

约束和唯一性保证

​ 唯一性约束在数据库中很常见：例如，用户名或电子邮件地址必须唯一标识一个用户，而在文件存储服务中，不能有两个具有相同路径和文件名的文件。如果要在写入数据时强制执行此约束（例如，如果两个人试图同时创建一个具有相同名称的用户或文件，其中一个将返回一个错误），则需要线性一致性。

​ 这种情况实际上类似于一个锁：当一个用户注册你的服务时，可以认为他们获得了所选用户名的 锁定 。该操作与原子性的比较与设置非常相似：将用户名赋予声明它的用户，前提是用户名尚未被使用。

​ 如果想要确保银行账户余额永远不会为负数，或者不会出售比仓库里的库存更多的物品，或者两个人不会都预定了航班或剧院里同一时间的同一个位置。这些约束条件都要求所有节点都同意一个最新的值（账户余额，库存水平，座位占用率）。

​ 在实际应用中，处理这些限制有时是可以接受的（例如，如果航班超额预订，你可以将客户转移到不同的航班并为其提供补偿）。在这种情况下，可能不需要线性一致性，我们将在 及时性与完整性 中讨论这种松散解释的约束。

​ 然而，一个硬性的唯一性约束（关系型数据库中常见的那种）需要线性一致性。其他类型的约束，如外键或属性约束，可以在不需要线性一致性的情况下实现【19】。

跨信道的时序依赖

​ 注意 图 9-1 中的一个细节：如果 Alice 没有惊呼得分，Bob 就不会知道他的查询结果是陈旧的。他会在几秒钟之后再次刷新页面，并最终看到最后的分数。由于系统中存在额外的信道（Alice 的声音传到了 Bob 的耳朵中），线性一致性的违背才被注意到。

​ 计算机系统也会出现类似的情况。例如，假设有一个网站，用户可以上传照片，一个后台进程会调整照片大小，降低分辨率以加快下载速度（缩略图）。该系统的架构和数据流如 图 9-5 所示。

​ 图像缩放器需要明确的指令来执行尺寸缩放作业，指令是 Web 服务器通过消息队列发送的（参阅 第 11 章 ）。 Web 服务器不会将整个照片放在队列中，因为大多数消息代理都是针对较短的消息而设计的，而一张照片的空间占用可能达到几兆字节。取而代之的是，首先将照片写入文件存储服务，写入完成后再将缩放器的指令放入消息队列。 图 9-5 Web 服务器和图像调整器通过文件存储和消息队列进行通信，打开竞争条件的可能性。

​ 如果文件存储服务是线性一致的，那么这个系统应该可以正常工作。如果它不是线性一致的，则存在竞争条件的风险：消息队列（ 图 9-5 中的步骤 3 和 4）可能比存储服务内部的复制更快。在这种情况下，当缩放器读取图像（步骤 5）时，可能会看到图像的旧版本，或者什么都没有。如果它处理的是旧版本的图像，则文件存储中的全尺寸图和略缩图就产生了永久性的不一致。

​ 出现这个问题是因为 Web 服务器和缩放器之间存在两个不同的信道：文件存储与消息队列。没有线性一致性的新鲜性保证，这两个信道之间的竞争条件是可能的。这种情况类似于 图 9-1 ，数据库复制与 Alice 的嘴到 Bob 耳朵之间的真人音频信道之间也存在竞争条件。

​ 线性一致性并不是避免这种竞争条件的唯一方法，但它是最容易理解的。如果你可以控制额外信道（例如消息队列的例子，而不是在 Alice 和 Bob 的例子），则可以使用在 读己之写 讨论过的备选方法，不过会有额外的复杂度代价。

实现线性一致的系统

​ 我们已经见到了几个线性一致性有用的例子，让我们思考一下，如何实现一个提供线性一致语义的系统。

​ 由于线性一致性本质上意味着 表现得好像只有一个数据副本，而且所有的操作都是原子的 ，所以最简单的答案就是，真的只用一个数据副本。但是这种方法无法容错：如果持有该副本的节点失效，数据将会丢失，或者至少无法访问，直到节点重新启动。

​ 使系统容错最常用的方法是使用复制。我们再来回顾 第 5 章 中的复制方法，并比较它们是否可以满足线性一致性：

单主复制（可能线性一致）

​ 在具有单主复制功能的系统中（参见 领导者与追随者 ），主库具有用于写入的数据的主副本，而追随者在其他节点上保留数据的备份副本。如果从主库或同步更新的从库读取数据，它们 可能（protential） 是线性一致性的^iv 。然而，并不是每个单主数据库都是实际线性一致性的，无论是通过设计（例如，因为使用快照隔离）还是并发错误【10】。

^iv. 对单领域数据库进行分区（分片），以便每个分区有一个单独的领导者，不会影响线性一致性，因为线性一致性只是对单一对象的保证。 交叉分区事务是一个不同的问题（参阅 分布式事务和共识 ）。 ↩

​ 从主库读取依赖一个假设，你确定领导是谁。正如在 真理在多数人手中 中所讨论的那样，一个节点很可能会认为它是领导者，而事实上并非如此——如果具有错觉的领导者继续为请求提供服务，可能违反线性一致性【20】。使用异步复制，故障转移时甚至可能会丢失已提交的写入（参阅 处理节点宕机 ），这同时违反了持久性和线性一致性。

共识算法（线性一致）

​ 一些在本章后面讨论的共识算法，与单领导者复制类似。然而，共识协议包含防止脑裂和陈旧副本的措施。由于这些细节，共识算法可以安全地实现线性一致性存储。例如，Zookeeper 【21】和 etcd 【22】就是这样工作的。

多主复制（非线性一致）

​ 具有多主程序复制的系统通常不是线性一致的，因为它们同时在多个节点上处理写入，并将其异步复制到其他节点。因此，它们可能会产生冲突的写入，需要解析（参阅 处理写入冲突 ）。这种冲突是因为缺少单一数据副本人为产生的。

无主复制（也许不是线性一致的）

​ 对于无领导者复制的系统（Dynamo 风格；参阅 无主复制 ），有时候人们会声称通过要求法定人数读写（ $w + r> n$ ）可以获得 强一致性 。这取决于法定人数的具体配置，以及强一致性如何定义（通常不完全正确）。

​ 基于时钟（例如，在 Cassandra 中；参见 依赖同步时钟 ）的 最后写入胜利 冲突解决方法几乎可以确定是非线性的，由于时钟偏差，不能保证时钟的时间戳与实际事件顺序一致。 松散的法定人数 也破坏了线性一致的可能性。即使使用严格的法定人数，非线性一致的行为也是可能的，如下节所示。

线性一致性和法定人数

​ 直觉上在 Dynamo 风格的模型中，严格的法定人数读写应该是线性一致性的。但是当我们有可变的网络延迟时，就可能存在竞争条件，如 图 9-6 所示。

图 9-6 非线性一致的执行，尽管使用了严格的法定人数

​ 在 图 9-6 中，$x$ 的初始值为 0，写入客户端通过向所有三个副本（ $n = 3, w = 3$ ）发送写入将 $x$ 更新为 1 。客户端 A 并发地从两个节点组成的法定人群（ $r = 2$ ）中读取数据，并在其中一个节点上看到新值 1 。客户端 B 也并发地从两个不同的节点组成的法定人数中读取，并从两个节点中取回了旧值 0 。

​ 仲裁条件满足（ $w + r> n$ ），但是这个执行是非线性一致的：B 的请求在 A 的请求完成后开始，但是 B 返回旧值，而 A 返回新值。 （又一次，如同 Alice 和 Bob 的例子 图 9-1 ）

​ 有趣的是，通过牺牲性能，可以使 Dynamo 风格的法定人数线性化：读取者必须在将结果返回给应用之前，同步执行读取修复（参阅 读时修复与反熵过程 ） ，并且写入者必须在发送写入之前，读取法定数量节点的最新状态【24,25】。然而，由于性能损失，Riak 不执行同步读取修复【26】。 Cassandra 在进行法定人数读取时， 确实 在等待读取修复完成【27】；但是由于使用了最后写入为准的冲突解决方案，当同一个键有多个并发写入时，将不能保证线性一致性。

​ 而且，这种方式只能实现线性一致的读写；不能实现线性一致的比较和设置操作，因为它需要一个共识算法【28】。

​ 总而言之，最安全的做法是：假设采用 Dynamo 风格无主复制的系统不能提供线性一致性。

线性一致性的代价

​ 一些复制方法可以提供线性一致性，另一些复制方法则不能，因此深入地探讨线性一致性的优缺点是很有趣的。

​ 我们已经在 第五章 中讨论了不同复制方法的一些用例。例如对多数据中心的复制而言，多主复制通常是理想的选择（参阅 运维多个数据中心 ）。 图 9-7 说明了这种部署的一个例子。

图 9-7 网络中断迫使在线性一致性和可用性之间做出选择。

​ 考虑这样一种情况：如果两个数据中心之间发生网络中断会发生什么？我们假设每个数据中心内的网络正在工作，客户端可以访问数据中心，但数据中心之间彼此无法互相连接。

​ 使用多主数据库，每个数据中心都可以继续正常运行：由于在一个数据中心写入的数据是异步复制到另一个数据中心的，所以在恢复网络连接时，写入操作只是简单地排队并交换。

​ 另一方面，如果使用单主复制，则主库必须位于其中一个数据中心。任何写入和任何线性一致的读取请求都必须发送给该主库，因此对于连接到从库所在数据中心的客户端，这些读取和写入请求必须通过网络同步发送到主库所在的数据中心。

​ 在单主配置的条件下，如果数据中心之间的网络被中断，则连接到从库数据中心的客户端无法联系到主库，因此它们无法对数据库执行任何写入，也不能执行任何线性一致的读取。它们仍能从从库读取，但结果可能是陈旧的（非线性一致）。如果应用需要线性一致的读写，却又位于与主库网络中断的数据中心，则网络中断将导致这些应用不可用。

如果客户端可以直接连接到主库所在的数据中心，这就不是问题了，哪些应用可以继续正常工作。但直到网络链接修复之前，只能访问从库数据中心的客户端会中断运行。

CAP 定理

​ 这个问题不仅仅是单主复制和多主复制的后果：任何线性一致的数据库都有这个问题，不管它是如何实现的。这个问题也不仅仅局限于多数据中心部署，而可能发生在任何不可靠的网络上，即使在同一个数据中心内也是如此。问题面临的权衡如下：^v

• 如果应用需要线性一致性，且某些副本因为网络问题与其他副本断开连接，那么这些副本掉线时不能处理请求。请求必须等到网络问题解决，或直接返回错误。（无论哪种方式，服务都 不可用（unavailable） ）。
• 如果应用不需要线性一致性，那么某个副本即使与其他副本断开连接，也可以独立处理请求（例如多主复制）。在这种情况下，应用可以在网络问题前保持可用，但其行为不是线性一致的。

^v. 这两种选择有时分别称为 CP（在网络分区下一致但不可用）和 AP（在网络分区下可用但不一致）。 但是，这种分类方案存在一些缺陷【9】，所以最好不要这样用。 ↩

因此不需要线性一致性的应用对网络问题有更强的容错能力。这种见解通常被称为 CAP 定理【29,30,31,32】，由 Eric Brewer 于 2000 年命名，尽管 70 年代的分布式数据库设计者早就知道了这种权衡【33,34,35,36】。

​ CAP 最初是作为一个经验法则提出的，没有准确的定义，目的是开始讨论数据库的权衡。那时候许多分布式数据库侧重于在共享存储的集群上提供线性一致性的语义【18】，CAP 定理鼓励数据库工程师向分布式无共享系统的设计领域深入探索，这类架构更适合实现大规模的网络服务【37】。 对于这种文化上的转变，CAP 值得赞扬 —— 它见证了自 00 年代中期以来新数据库的技术爆炸（即 NoSQL）。

CAP 定理没有帮助

CAP 有时以这种面目出现：一致性，可用性和分区容忍：三者只能择其二。不幸的是这种说法很有误导性【32】，因为网络分区是一种错误，所以它并不是一个选项：不管你喜不喜欢它都会发生【38】。

在网络正常工作的时候，系统可以提供一致性（线性一致性）和整体可用性。发生网络故障时，你必须在线性一致性和整体可用性之间做出选择。因此，一个更好的表达 CAP 的方法可以是一致的，或者在分区时可用【39】。一个更可靠的网络需要减少这个选择，但是在某些时候选择是不可避免的。

在 CAP 的讨论中，术语可用性有几个相互矛盾的定义，形式化作为一个定理【30】并不符合其通常的含义【40】。许多所谓的 高可用 （容错）系统实际上不符合 CAP 对可用性的特殊定义。总而言之，围绕着 CAP 有很多误解和困惑，并不能帮助我们更好地理解系统，所以最好避免使用 CAP。

​ CAP 定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一个一致性模型（即线性一致性）和一种故障（网络分区^vi ，或活跃但彼此断开的节点）。它没有讨论任何关于网络延迟，死亡节点或其他权衡的事。 因此，尽管 CAP 在历史上有一些影响力，但对于设计系统而言并没有实际价值【9,40】。

​ 在分布式系统中有更多有趣的 不可能 的结果【41】，且 CAP 定理现在已经被更精确的结果取代【2,42】，所以它现在基本上成了历史古迹了。

^vi. 正如 真实世界的网络故障 中所讨论的，本书使用 分区（partition） 指代将大数据集细分为小数据集的操作（分片；参见 第 6 章 ）。与之对应的是， 网络分区（network partition） 是一种特定类型的网络故障，我们通常不会将其与其他类型的故障分开考虑。但是，由于它是 CAP 的 P，所以这种情况下不能将其混为一谈。 ↩

线性一致性和网络延迟

​ 虽然线性一致是一个很有用的保证，但实际上，线性一致的系统惊人的少。例如，现代多核 CPU 上的内存甚至都不是线性一致的【43】：如果一个 CPU 核上运行的线程写入某个内存地址，而另一个 CPU 核上运行的线程不久之后读取相同的地址，并没有保证一定能一定读到第一个线程写入的值（除非使用了 内存屏障（memory barrier） 或 围栏（fence） 【44】）。

​ 这种行为的原因是每个 CPU 核都有自己的内存缓存和存储缓冲区。默认情况下，内存访问首先走缓存，任何变更会异步写入主存。因为缓存访问比主存要快得多【45】，所以这个特性对于现代 CPU 的良好性能表现至关重要。但是现在就有几个数据副本（一个在主存中，也许还有几个在不同缓存中的其他副本），而且这些副本是异步更新的，所以就失去了线性一致性。

​ 为什么要做这个权衡？对多核内存一致性模型而言，CAP 定理是没有意义的：在同一台计算机中，我们通常假定通 信都是可靠的。并且我们并不指望一个 CPU 核能在脱离计算机其他部分的条件下继续正常工作。牺牲线性一致性的原因是 性能（performance） ，而不是容错。

​ 许多分布式数据库也是如此：它们是 为了提高性能 而选择了牺牲线性一致性，而不是为了容错【46】。线性一致的速度很慢——这始终是事实，而不仅仅是网络故障期间。

​ 能找到一个更高效的线性一致存储实现吗？看起来答案是否定的：Attiya 和 Welch 【47】证明，如果你想要线性一致性，读写请求的响应时间至少与网络延迟的不确定性成正比。在像大多数计算机网络一样具有高度可变延迟的网络中（参见 超时与无穷的延迟 ），线性读写的响应时间不可避免地会很高。更快地线性一致算法不存在，但更弱的一致性模型可以快得多，所以对延迟敏感的系统而言，这类权衡非常重要。在 第 12 章 中将讨论一些在不牺牲正确性的前提下，绕开线性一致性的方法。