Skip to content

Latest commit

 

History

History
1405 lines (833 loc) · 148 KB

ch9.md

File metadata and controls

1405 lines (833 loc) · 148 KB
Raw

9. 一致性与共识

好死不如赖活着 —— Jay Kreps, 关于Kafka与 Jepsen的若干笔记 (2013)

[TOC]

正如第8章所讨论的，分布式系统中的许多事情可能会出错。处理这种故障的最简单方法是简单地让整个服务失败，并向用户显示错误消息。如果这个解决方案是不可接受的，我们需要找到容忍错误的方法——即保持服务正常运行，即使某些内部组件出现故障。

在本章中，我们将讨论构建容错分布式系统的算法和协议的一些例子。我们将假设第8章的所有问题都可能发生：网络中的数据包可能会丢失，重新排序，重复或任意延迟;时钟近似于最好;并且节点可以暂停（例如，由于垃圾收集）或随时崩溃。

构建容错系统的最好方法是找到一些有用的保证的通用抽象，实现一次，然后让应用程序依靠这些保证。这与第7章中的事务处理方法相同：通过使用事务，应用程序可以假装没有崩溃（原子性），没有其他人同时访问数据库（隔离），存储设备是完全可靠的（耐用性）。即使发生崩溃，竞态条件和磁盘故障，事务抽象隐藏了这些问题，以便应用程序不必担心它们。

现在我们将继续沿着同样的路线前进，寻求可以让应用程序忽略分布式系统的一些问题的抽象概念。例如，分布式系统最重要的抽象之一就是共识（consensus）：就是让所有的节点对某个事物达成一致。正如我们在本章中将会看到的那样，尽管存在网络故障和流程故障，可靠地达成共识是一个令人惊讶的棘手问题。

一旦达成共识，应用程序可以将其用于各种目的。例如，假设你有一个单主复制的数据库。如果主库挂点，并且需要故障转移到另一个节点，剩余的数据库节点可以使用共识来选举新的领导者。正如在“处理节点中断”中所讨论的那样，重要的是只有一个领导者，并且所有的节点都同意领导者是谁。如果两个节点都认为他们是领导者，那么这种情况被称为脑裂（split brain），并且经常导致数据丢失。正确实现共识有助于避免这种问题。

在本章后面的第352页的“分布式事务和共识”中，我们将研究解决共识和相关问题的算法。但首先，我们首先需要探索可以在分布式系统中提供的保证和抽象的范围。

我们需要了解可以做什么和不可以做什么的范围：在某些情况下，系统可以容忍故障并继续工作;在其他情况下，这是不可能的。在理论证明和实际实施中都深入探索了什么是和不可能的限制。我们将在本章中概述这些基本限制。

分布式系统领域的研究人员几十年来一直在研究这些主题，所以有很多材料 - 我们只能在表面上划伤。在本书中，我们没有空间去详细介绍形式模型和证明的细节，所以我们将坚持非正式的直觉。如果您有兴趣，参考文献可以提供更多的深度。

一致性保证

在第161页中的“复制滞后问题”中，我们查看了复制数据库中发生的一些计时问题。如果您在同一时刻查看两个数据库节点，则可能会在两个节点上看到不同的数据，因为写请求在不同的时间到达不同的节点。无论数据库使用何种复制方法（单引导程序，多引导程序或无引导程序复制），都会出现这些不一致情况。

大多数复制的数据库至少提供了最终的一致性，这意味着如果你停止向数据库写入数据并等待一段不确定的时间，那么最终所有的读取请求都会返回相同的值[1]。换句话说，不一致性是暂时的，最终会自行解决（假设网络中的任何故障最终都会被修复）。最终一致性的一个更好的名字可能是收敛的，因为我们预计所有的复制品最终会收敛到相同的值[2]。

然而，这是一个非常弱的保证 - 它没有说什么什么时候副本会汇合。在收敛之前，阅读可能会返回任何东西或没有东西[1]。例如，如果您编写了一个值，然后立即再次读取，则不能保证您将看到刚刚写入的值，因为可能会将读取路由到不同的副本（请参阅第152页的“读取自己的写入” ）。

对于应用程序开发人员而言，最终的一致性是很难的，因为它与普通单线程程序中变量的行为有很大不同。如果将一个值赋给一个变量，然后很快读取，则不会期望读取旧值，或者读取失败。数据库表面上看起来像一个你可以读写的变量，但事实上它有更复杂的语义[3]。

在处理只提供弱保证的数据库时，您需要不断地意识到它的局限性，而不是意外假设太多。错误往往是微妙的，很难找到测试，因为应用程序可能在大多数情况下运行良好。当系统出现故障（例如网络中断）或高并发时，最终一致性的边缘情况才变得明显。

在本章中，我们将探索数据系统可能选择提供的更强一致性模型。它们不是免费的：具有较强保证的系统可能会比保证较差的系统具有更差的性能或更少的容错性。尽管如此，更强有力的保证可以吸引人，因为它们更容易正确使用。一旦你看到了一些不同的一致性模型，你将能够更好地决定哪一个最适合你的需求。

分布式一致性模型和我们之前讨论的事务隔离级别的层次结构有一些相似之处[4,5]（参见“弱隔离级别”）。但是，虽然有一些重叠，但他们大多是独立的问题：事务隔离主要是为了避免由于同时执行事务而导致的竞争状态，而分布式一致性主要是在面对延迟和故障时协调副本的状态。

本章涵盖了广泛的话题，但我们将会看到，这些领域实际上是深深联系在一起的：

  • 我们首先看一下常用的最强一致性模型之一，线性化，并考察其优缺点。
  • 然后，我们将检查分布式系统中订购事件的问题（第339页的“订单保证”），特别是关于因果关系和总订购的问题。
  • 在第三部分（“分布式事务和共识”第359页）中，我们将探讨如何自动提交分布式事务，这将最终引导我们解决共识问题。

线性化

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

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

在一个线性化系统中，只要一个客户端成功完成写操作，所有客户端从数据库中读取数据必须能够看到刚刚写入的值。维护数据的单个副本的错觉是指低保读取的值是最近的，跟上时代的价值，而不是来自一个陈旧的缓存或副本。换句话说，线性化是一种新近的保证。为了澄清这个想法，我们来看看一个不可线性化系统的例子。

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

图9-1显示了一个非线性体育网站的例子[9]。爱丽丝和鲍勃正坐在同一个房间里，他们都在检查他们的手机，看看2014年FIFA世界杯决赛的结果。在最后得分公布后，爱丽丝刷新页面，看到获胜者宣布，并兴奋地告诉鲍勃。鲍勃无意中在自己的手机上重新加载，但他的请求转到了数据库副本上，而他的手机显示该游戏仍在进行中。

如果Alice和Bob在同一时间点击重新加载，如果他们获得了两个不同的查询结果，那么它们就不那么令人惊讶了，因为他们不知道服务器在何时处理它们各自的请求。然而，鲍勃知道他在听到爱丽丝惊呼最后的得分之后点击了重新加载按钮（启动了他的查询），因此他期望他的查询结果至少与爱丽丝一样近。他的查询返回陈旧结果的事实违反了线性化。

什么使得系统线性一致？

线性化背后的基本思想很简单：使系统看起来好像只有一个数据副本。然而，确切地说，这意味着实际上需要一些小心实现。为了更好地理解线性化，让我们看看更多的例子。

图9-2显示了三个客户端在可线性化数据库中同时读写相同的密钥x。在分布式系统文献中，x被称为注册实践，例如，它可以是关键值存储中的一个关键字，关系数据库中的一行或文档数据库中的一个文档。

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

为了简单起见，图9-2仅显示了来自客户端的请求，而不是数据库的内部。每个小节都是由客户端发出的请求，其中小节的开始是发送请求的时间，小节的结尾是客户端收到响应的时间。由于可变的网络延迟，客户端不知道恰恰在数据库处理它的请求时——它只知道它在发送请求和接收响应的客户端之间的某个时间已经发生了。1

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

  • 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，因为我们不知道写操作在处理读操作时是否生效。这些操作与写入同时发生。

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

为了使系统可线性化，我们需要添加另一个约束，如图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，vold，vnew)⇒r表示客户端请求进行原子比较与设置操作（请参阅“比较并设置”一节）。如果寄存器x的当前值等于vold，则应该原子地设置为vnew。如果x≠vold，则操作应该保持寄存器不变并返回一个错误。 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]。

线性化与可序列化

线性化易于与可序列化性相混淆（请参见第251页上的“可序列化”），因为两个词似乎都是类似于“可以按顺序排列”的东西。但是，它们是两个完全不同的保证，区分他们：

可序列化

**可序列化（Serializability）**是事务的隔离属性，每个事务可以读写多个对象（行，文档，记录） - 请参阅第228页上的“单对象和多对象操作”。它确保事务的行为与如果他们已经按照一定的连续顺序执行（每个事务在下一个事务开始之前运行完成）。该顺序与事务实际执行的顺序不同[12]。

线性化

**线性化（Linearizability）**是读取和写入寄存器（个别对象）的最新保证。它不会将操作组合到事务中，因此它不会阻止写入歪斜等问题（请参阅“写入歪斜和虚拟”），除非采取其他措施（如实现冲突）（请参阅本文的“实现冲突” 251）。

一个数据库可以提供可串行性和线性化，这种组合被称为严格的可串行性或强的单拷贝可串行性（strong-1SR）[4,13]。基于两阶段锁定的串行化实现（请参见“两阶段锁定（2PL）”一节，第257页）或实际的串行执行（请参见第242页的“实际的串行执行”）通常是可线性化的。

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

依赖线性一致性

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

一个使用单主复制的系统需要确保确实只有一个领导而不是几个（裂脑）。选择领导者的一种方法是使用一个锁：每个启动的节点试图获得锁，而成功的则成为领导者[14]。不管这个锁是如何实现的，它必须是可线性化的：所有节点必须同意哪个节点拥有锁;否则就没用了。

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

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

限制和唯一性保证

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

这种情况实际上类似于一个锁：当一个用户注册你的服务时，你可以想到他们获得了他们所选用户名的“锁定”。该操作也非常类似于原子比较和设置，将用户名设置为声明它的用户的ID，前提是用户名尚未被使用。 如果你想要确保银行账户余额永远不会消极，或者你没有出售比仓库里的库存更多的物品，或者两个人不同时在同一个位置一个航班或一个剧院。这些约束条件都要求所有节点都同意一个最新的值（账户余额，库存水平，座位占用率）。

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

然而，一个硬性的唯一性约束，比如你通常在关系数据库中发现的约束，需要线性化。其他类型的约束，如外键或属性约束，可以在不需要线性化的情况下实现[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的情况下），则可以使用与我们在第162页的“读取自己的写入”额外的复杂性的成本。

实现线性一致的系统

现在我们已经看了几个线性化有用的例子，让我们考虑一下如何实现一个提供可线性化语义的系统。

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

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

单主复制（可能可线性化）

在具有单引导程序复制功能的系统中（请参见“引导程序和追踪者”第152页），领导者具有用于写入的数据的主副本，而追随者在其他节点上保留数据的备份副本。如果你从领导读取数据，或者从同步更新的追随者读取数据，他们有可能是线性化的4。然而，并不是每个单独的领导者数据库都是可以线性化的，无论是通过设计（例如，因为它使用快照隔离）或者由于并发错误[10]。

使用领导进行阅读依赖于你确定领导是谁的假设。正如在第300页的“真理被多数人定义”中所讨论的那样，一个节点很可能会认为它是领导者，而事实上并非如此 - 如果妄想的领导者继续为请求提供服务，可能违反线性化[20]。使用异步复制，故障转移甚至可能会丢失提交的写入（请参阅第156页的“处理节点中断”），这违反了耐久性和线性化。

共识算法（可线性化）

一些共识算法，我们将在本章后面讨论，与单引导者复制相似。然而，共识协议包含措施，以防止裂脑和陈旧的复制品。由于这些细节，协调算法可以安全地实现线性化存储。例如，Zoo-Keeper [21]和etcd [22]就是这样工作的。

多主复制（不可线性化）

具有多引导程序复制的系统通常不是线性化的，因为它们同时在多个节点上处理写入，并将其异步复制到其他节点。由于这个原因，它们可能会产生冲突的写入，需要解析（请参阅第171页的“处理写入冲突”）。这种冲突是缺乏单一数据副本的人为因素。

无主复制（可能不是线性化的）

对于无领导者复制的系统（Dynamo风格;请参阅第177页的“无主复制”），有时候人们会声称通过要求法定读写（w + r> n）可以获得“强一致性”。根据法定人数的确切配置，取决于您如何界定强一致性，这是不正确的。

基于时钟（例如，在Cassandra中;参见第291页上的“依赖于同步时钟”）的“最后写入胜利”冲突解决方法几乎是非线性的，因为时钟时间戳不能保证与时间戳一致由于时钟歪斜而导致的实际事件排序。不规范的法定人数（第183页的“马虎法定人数和暗示交接”）也破坏了线性化的可能性。即使是严格的法定人数，非线性行为也是可能的，如下一节所示。

线性化和法定人数

直觉上，严格的仲裁读写应该是在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返回新值。 （这又是爱丽丝和鲍勃的情况了图9-1）

有趣的是，可以使Dynamo风格的定额以可降低的性能为代价线性化：读取器必须在将结果返回给应用程序之前，同步执行读取修复（请参阅“修复和反熵”一节第178页） ，并且作者必须在发送写入之前读取法定数量的最新状态[24,25]。然而，由于性能损失，Riak不执行同步读取修复[26]。 Cassandra确实等待读取修复以完成读取问题[27]，但是如果由于使用了最后写入赢得冲突解决方案而导致同一个关键字有多个并发写入，则它将失去线性化。

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

总而言之，假设无Dynamo风格复制的无领导者系统不能提供线性化性是最安全的。

线性一致性的代价

由于一些复制方法可以提供线性化，其他复制方法则不能，因此更深入地探讨线性化的优缺点是很有趣的。

我们已经在第五章讨论了不同复制方法的一些用例。例如，我们看到多领导者复制通常是多数据中心复制的理想选择（请参阅第165页上的“多数据中心操作”）。图9-7说明了这种部署的一个例子。

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

考虑如果两个数据中心之间发生网络中断，会发生什么情况。我们假设每个数据中心内的网络正在工作，客户端可以访问数据中心，但数据中心不能互相连接。

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

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

如果数据中心之间的网络在单引导程序设置中被中断，则连接到跟随者数据中心的客户端不能联系领导者，因此他们不能对数据库进行任何写入，也不能进行任何线性化读取。他们仍然可以从追随者读取，但他们可能是陈旧（非线性）。如果应用程序需要可线性读写，则网络中断将导致应用程序在不能联系领导者的数据中心中变得不可用。 如果客户端可以直接连接到领导者数据中心，这不是问题，因为应用程序在那里继续正常工作。但是只能访问下一个数据中心的客户端将会经历停机，直到网络链接被修复。

CAP定理

这个问题不仅仅是单领导者和多领导者复制的结果：任何可线性化的数据库都有这个问题，不管它是如何实现的。这个问题也不是特定于多数据中心部署，而是可能发生在任何不可靠的网络上，即使在一个数据中心内也是如此。权衡如下：5

  • 如果您的应用程序需要线性化，并且由于网络问题某些副本与其他副本断开连接，则某些副本在断开连接时无法处理请求：它们必须等待，直到网络问题得到解决，或返回错误（无论哪种方式，他们变得不可用）。
  • 如果您的应用程序不需要线性化，那么即使它与其他副本（如多引导程序）断开连接，也可以以每个副本可独立处理请求的方式进行写入。在这种情况下，应用程序可以在网络问题面前保持可用，但其行为不可线性化。

因此，不需要线性化的应用可以更容忍网络问题。这种见解通常被称为CAP定理[29,30,31,32]，由Eric Brewer于2000年命名，尽管自20世纪70年代以来，分布式数据库的设计者已经知道了这种权衡[33,34,35,36 ]。

CAP最初是作为一个经验法则提出的，没有准确的定义，目的是开始讨论数据库的权衡。当时，许多分布式数据库侧重于在具有共享存储的机器集群上提供可线性化的语义[18]，并鼓励数据库工程师探索更广泛的分布式无共享系统的设计空间，这更适合于实施大规模的网络服务[37]。 CAP值得赞扬，因为这种文化转变 - 见证了自2000年代中期以来新的数据库技术的爆炸式增长（被称为NoSQL）。

CAP定理没有帮助

CAP有时以这种面目出现：一致性，可用性和分区容忍：三者只能择其二。

个中只能选择从3中挑选出2个。不幸的是，这样做是误导的[32]，因为网络分区是一种错误，所以它们不是你所拥有的一个选择：他们会发生，不管你喜欢还是不喜欢[38]。

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

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

正式定义的CAP定理[30]的范围很窄，它只考虑一个一致性模型（即线性化）和一种故障（网络分区6或活动但彼此断开的节点）。它没有说任何有关网络延迟，死亡节点或其他权衡的事情。 因此，尽管CAP在历史上具有影响力，但对于设计系统来说，它没有实际价值[9,40]。

在分布式系统中有更多有趣的不可能的结果[41]，并且CAP已经被更精确的结果所取代[2,42]，所以它现在基本上是历史感兴趣的。

线性化和网络延迟

虽然线性化是一个有用的保证，但实际上很少有系统实际上是线性化的。例如，现代多核CPU上的RAM甚至不可线性化[43]：如果一个CPU内核上运行的线程写入内存地址，而另一个CPU内核上的线程不久后读取相同的地址，保证读取第一个线程写入的值（除非使用了内存屏障或栅栏[44]）。

这种行为的原因是每个CPU内核都有自己的内存缓存和存储缓冲区。内存访问首先进入缓存默认情况下，任何更改异步写出到主内存。由于在缓存中访问数据比进入主内存要快[45]，所以这个特性对于现代CPU的良好性能是至关重要的。但是，现在有几个数据副本（一个在主内存中，另外几个在不同的高速缓存中），而且这些副本是异步更新的，因此线性化会丢失。

为什么要做这个交换？使用CAP定理来证明多核内存一致性模型是没有意义的：在一台计算机中，我们通常假定可靠的通信，并且我们不希望一个CPU内核能够继续正常的操作与电脑的其他部分断开连接。降低线性化的原因是性能，而不是容错。

许多分布式数据库也是如此，它们选择不提供线性保证：它们主要是为了提高性能，而不是为了容错[46]。线性化速度很慢 - 这一直是事实，不仅在网络故障期间。

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

顺序保证

我们之前曾经说过，线性化寄存器的行为就好像只有一个数据拷贝一样，而且每一个操作在某个时间点似乎都是原子地生效的。这个定义意味着操作按照一定的顺序执行。我们通过按照它们似乎已经执行的顺序加入操作来说明图9-4中的顺序。

订购在本书中一直是反复出现的主题，这表明这可能是一个重要的基本概念。让我们简要回顾一下我们在其中讨论过的其他一些情况：

  • 在第5章中，我们看到领导者在单引导者复制中的主要目的是确定复制日志中的写入顺序 - 也就是追随者应用这些写入的顺序。如果不存在单个领导，则可能由于并发操作而发生冲突（请参阅第171页的“处理写冲突”）。
  • 我们在第7章中讨论的可序列化是关于确保事务按照某种顺序执行的行为。它可以通过以该序列字面执行事务来实现，或者通过允许并行执行，同时防止序列化冲突（通过锁定或中止）来实现。
  • 我们在第8章讨论过的在分布式系统中使用时间戳和时钟（请参阅第291页上的“依赖于同步时钟”）是另一种将秩序引入无序世界的尝试，例如确定两个写入中的哪一个稍后发生。

事实证明，排序，线性化和共识之间有着深刻的联系。尽管这个概念比本书的其他部分更具理论性和抽象性，但对于澄清我们对什么是系统可以做什么和不可以做什么而言是非常有帮助的。我们将在接下来的几节中探讨这个话题。

顺序与因果

订单不断涌现有几个原因，其中一个原因是它有助于保持因果关系。在这本书的过程中，我们已经看到了几个例子，其中因果关系是重要的：

  • 在“一致前缀读取”（图5-5）中，我们看到一个例子，一个对话的观察者首先看到问题的答案，然后回答问题。这是令人困惑的，因为它违背了我们对因果的直觉：如果一个问题得到了回答，那么显然这个问题必须首先在那里，因为给出答案的人必须看到这个问题（假设他们不是精神的，未来）。我们说在问题和答案之间存在因果关系。
  • 图5-9中出现了类似的模式，我们在这里看到三位领导者之间的复制，并注意到由于网络延迟，一些文字可能会“超过”其他文字。从其中一个副本的角度看，好像有一个不存在的行的更新。这里的因果意味着一行必须先被创建，然后才能被更新。
  • 在第184页的“检测并发写入”中，我们观察到如果您有两个操作A和B，则有三种可能性：A发生在B之前，或B发生在A之前，或者A和B并发。这是在关系是因果关系的另一种表达之前发生的：如果A发生在B之前，那么意味着B可能已经知道了A，或者建立在A上，或者依赖于A.如果A和B是并发的，那么他们;换句话说，我们确信没有人知道另一个。
  • 在事务快照隔离的上下文中（“快照隔离和可重复读”（第223页）），我们说事务从一致的快照中读取。但在这方面“一致”是什么意思？这意味着与因果关系一致：如果快照包含答案，它也必须包含被回答的问题[48]。在一个时间点观察整个数据库使其与因果性保持一致：在那个时间点之前发生的所有操作的效果都是可见的，但是没有发生严重的后续操作。读取偏斜（非重复读取，如图7-6所示）意味着读取的数据处于违反因果关系的状态。
  • 我们在事务之间编写歪斜的示例（请参见第249页上的“编写偏见和疑惑”）也说明了因果关系：在图7-8中，Alice被允许关闭电话，因为交易认为Bob仍在通话，反之亦然。在这种情况下，去电的动作因果关系取决于观察当前谁在呼叫。可序列化的快照隔离（请参见“可序列化的快照隔离（SSI）”（第267页））通过跟踪事务之间的因果依赖关系来检测写入歪斜。
  • 在爱丽丝和鲍勃看足球的例子中（图9-1），在听到爱丽丝惊呼结果之后，鲍勃从服务器得到一个陈旧结果的事实是一个因果关系的违反：爱丽丝的感叹是因果关系依赖于比分，所以鲍勃应该也可以在听完艾丽斯后看到比分。在图像大小调整服务的幌子下，第331页的“跨渠道时序依赖关系”中再次出现了相同的模式。

因果关系对事件施加了一种排序：在收到该消息之前发送消息;问题出现在答案之前。而且，就像现实生活中一样，有一件事情会导致另一件事情：一个节点读取一些数据，然后写出一些结果，另一个节点读取写入的内容并依次写入其他内容，等等。这些依赖因果关系的操作链定义了系统中的因果顺序，即在什么之前发生了什么。 如果一个系统服从因果关系所规定的顺序，我们说它是因果关系一致的。例如，快照隔离提供了因果一致性：当您从数据库中读取数据，并且看到一些数据时，您还必须能够看到任何因果关系的数据（假设在此期间还没有被删除）。

因果顺序不是全序关系

**全序关系（total order）**允许任何两个元素进行比较，所以如果你有两个元素，你总是可以说哪个更大，哪个更小。例如，自然数是完全有序的：如果我给你两个数字，比如说5和13，那么你可以告诉我，13大于5。

但是，数学集并不完全排序：是{a，b}大于{b，c}？那么，你不能真正地比较它们，因为它们都不是其中的一个子集。我们说它们是无法比拟的，因此数学集是部分排序的：在某些情况下，一个集大于另一个（如果一个集包含另一个集的所有元素），但在其他情况下它们是无法比拟的。

总订单和部分订单之间的差异反映在不同的数据库一致性模型中：

线性化

在一个可线性化的系统中，我们有一个总的操作顺序：如果系统的行为就好像只有一个数据副本，并且每个操作都是原子的，这意味着对于任何两个操作，我们总是可以说哪个操作先发生。这个总的排序在图9-4中以时间线表示。

因果关系

我们说过，如果两个操作都没有发生在另一个之前，那么这两个操作是并发的（请参阅第186页上的“发生之前的关系和并发”）。换句话说，如果两个事件是因果关系的（一个发生在另一个事件之前），则它们被排序，但是如果它们是并发的，则它们是无法比拟的。这意味着因果关系定义了一个部分的秩序，而不是一个整体的秩序：一些行动是相互排序的，但有些是无法比拟的。

因此，根据这个定义，在可数据化数据存储中不存在并发操作：必须有一个时间线，所有的操作都是按顺序排列的。可能有几个请求等待处理，但是数据存储确保了每个请求都是在单个时间点自动处理的，并且在单个时间轴上作用于单个数据副本，而没有任何并发性。

并发性意味着时间线会再次分支和合并 - 在这种情况下，不同分支上的操作是无法比拟的（即并发）。在第五章中我们看到了这种现象：例如，图5-14不是一条直线的总体顺序，而是一堆不同的操作同时进行。图中的箭头表示因果关系 - 操作的部分顺序。

如果您熟悉像Git这样的分布式版本控制系统，那么它们的版本历史非常类似于因果关系图。通常，一个提交会以一条直线进行，但是有时您会得到分支（当多个人同时在一个项目上工作时），并且在这些创建的提交合并时创建合并。

线性化强于因果一致性

那么因果顺序和线性化之间的关系是什么？答案是线性化意味着因果关系：任何可线性化的系统都能正确保存注意力[7]。特别是，如果系统中有多个通信通道（如图9-5中的消息队列和文件存储服务），线性可确保因果关系被自动保留，而系统不必做任何特殊的事情（如通过不同部件之间的时间戳）。

线性化确保因果关系的事实使线性化系统变得简单易懂，更具吸引力。然而，正如第335页的“线性可用性的成本”中所讨论的，使系统可线性化可能会损害其性能和可用性，尤其是在系统具有严重的网络延迟的情况下（例如，如果地理位置分散的话）。出于这个原因，一些分布式数据系统已经放弃了线性化，这使得它们可以获得更好的性能，但却使它们难以工作。

好消息是中间地带是可能的。线性化不是保持因果关系的唯一途径 - 还有其他方法。一个系统可以在原因上是一致的，不会造成使其线性化的性能命中（特别是CAP定理不适用）。事实上，因果一致性是最强可能的一致性模型，不会由于网络延迟而减慢，并且在网络故障时仍然可用[2,42]。

在许多情况下，似乎需要线性化的系统实际上只需要确定因果一致性，这可以更有效地实施。基于这种观察，研究人员正在探索新的数据库来保存因果关系，其性能和可用性特征与最终一致的系统类似[49,50,51]。 由于这项研究是相当新的，其中没有很多已经进入生产系统，仍然有挑战需要克服[52,53]。但是，这是未来系统的一个有利的方向。

捕获因果关系

我们不会详细讨论非线性系统如何在这里维持因果一致性，而只是简要地探讨一些关键的思想。为了保持因果关系，您需要知道哪个操作发生在哪个其他操作之前。这是一个部分命令：并发操作可以按任意顺序进行，但是如果一个操作发生在另一个操作之前，那么它们必须按照每个副本的顺序处理。因此，当一个副本处理一个操作时，它必须确保所有因果先前的操作（之前发生的所有操作）已经被处理;如果前面的某个操作丢失了，后面的操作必须等待，直到前面的操作被处理完毕。

为了确定因果依赖关系，我们需要一些方法来描述系统中节点的“知识”。如果节点在发出写入Y时已经看到X值，则X和Y可能是因果关系的。这个分析使用了你在欺诈指控的刑事调查中所期望的那些问题：CEO在做出决定时是否知道X？

在其他操作之前确定哪些操作发生的技术与我们在第181页中的“检测并发写入”中所讨论的内容类似。该节讨论无领导者数据存储区中的因果关系，我们需要检测到同一个关键字为了防止丢失更新。因果关系更进一步：它需要跟踪整个数据库的因果关系，而不仅仅是一个关键。版本向量可以被推广到做这个[54]。

为了确定因果顺序，数据库需要知道应用程序读取哪个版本的数据。这就是为什么在图5-13中，来自先前操作的版本号在写入时被传回到数据库的原因。在SSI的冲突检测中会出现类似的想法，如“可序列化的快照隔离（SSI）”中所述：当事务要提交时，数据库将检查它读取的数据版本是否仍然运行至今。为此，数据库跟踪哪个数据已经被哪个事务读取。

序列号顺序

虽然因果关系是一个重要的理论概念，但实际上跟踪所有的因果关系是不切实际的。在许多应用程序中，客户端在写入内容之前会先读取大量数据，然后不清楚写入是因果关系依赖于全部还是仅仅一些先前的读取。显式跟踪所有已读取的数据将意味着很大的开销。

但是，还有一个更好的方法：我们可以使用序列号或时间戳来排序事件。时间戳不一定来自时钟（或物理时钟，有很多问题，如“不可靠时钟”在287页中所述）。它可以来自一个逻辑时钟，这是一个算法来产生一个数字序列来识别操作，通常使用计数器，每个操作增加计数器。

这样的序列号或时间戳是紧凑的（只有几个字节大小），它们提供了一个总的顺序：也就是说，每一个操作都有一个唯一的序列号，你总是可以比较两个序列号来确定哪个更大（即，哪些操作发生在后面）。

特别是，我们可以按照与因果关系一致的顺序创建序列号7：我们保证，如果操作A因果关系发生在B之前，那么A在总顺序之前发生在B之前（A具有比B更小的序列号）。并行操作可以任意命令。这样一个总的秩序捕获所有的因果信息，但也强加了比由于因果关系所严格要求的更多的秩序。

在具有单引导程序复制的数据库中（请参见“引导程序和追踪者”（第152页）），复制日志定义了与因果关系一致的写操作总顺序。领导者可以简单地为每个操作增加一个计数器，从而为复制日志中的每个操作分配一个单调递增的序列号。如果一个追随者按照他们在复制日志中出现的顺序来应用写入，那么追随者的状态始终是因果一致的（即使它落后于领导者）。

非因果序列号发生器

如果没有一个领导者（可能是因为您使用的是多领导者或无领导者的数据库，或者是因为数据库是分区的），那么如何为操作生成序列号还不太清楚。实践中使用了各种方法：

  • 每个节点都可以生成自己独立的一组序列号。例如，如果有两个节点，一个节点只能生成奇数，而另一个节点只能生成偶数。通常，可以在序列号的二进制表示中保留一些位以包含唯一的节点标识符，这将确保两个不同的节点永远不会生成相同的序列号。
  • 您可以将时间戳从时钟（物理时钟）附加到每个操作[55]。这样的时间戳是不连续的，但是如果它们具有足够高的分辨率，那么它们可能足以完成命令操作。这个事实用于最后的写赢取冲突解决方法（请参阅第291页的“订购事件的时间戳”）。
  • 您可以预先分配序列号的块。例如，节点A可能要求从1到1,000的序列号的块，并且节点B可能要求该区块从1,001到2,000。然后，每个节点可以独立分配其块的序列号，并在序列号的提供开始变低时分配一个新的块。

这三个选项都比单独的领导者增加一个计数器的表现更好，并且更具可扩展性。它们为每个操作生成一个唯一的，大约增加的序列号。然而，他们都有一个问题：他们产生的序列号与因果关系不一致。

因为这些序列号发生器不能正确地捕获不同节点上操作的顺序，所以会出现因果关系问题：

  • 每个节点可以每秒处理不同数量的操作。因此，如果一个节点产生偶数而另一个产生奇数，则偶数的计数器可能落后于奇数的计数器，反之亦然。如果你有一个奇数的操作和一个偶数的操作，你不能准确地说出哪一个因果关系发生了。

  • 来自物理时钟的时间戳会受到时钟偏移的影响，这可能会使其与因果性不一致。例如，见图8-3，其中显示了一个情况，其中后来发生因果关系的操作实际上被分配了较低的时间戳。7

  • 在块分配器的情况下，一个操作可能会被赋予一个范围从1,001到2,000的序列号，而一个因果较晚的操作可能被赋予一个范围从1到1,000的数字。在这里，序列号与因果关系也是不一致的。

Lamport时间戳

尽管刚才描述的三个序列号发生器与因果关系不一致，但实际上有一个简单的方法来产生与因果关系一致的序列号。它被称为Lamport时间戳，莱斯利·兰波特（Leslie Lamport）于1978年提出[56]，现在是分布式系统领域中被引用最多的论文之一。

图9-8说明了Lamport时间戳的使用。每个节点都有一个唯一的标识符，每个节点都保存一个处理操作数量的计数器。 Lamport时间戳然后是一对（计数器，节点ID）。二节点有时可能具有相同的计数器值，但通过在时间戳中包含节点ID，每个时间戳都是唯一的。

图9-8 Lamport时间戳提供了与因果关系一致的总排序。

Lamport时间戳与物理时间时钟没有任何关系，但是它提供了总计次数：如果您有两个时间戳，则计数器值较大的时间戳是较大的时间戳。如果计数器值相同，则节点ID越大的时间戳越大。

到目前为止，这个描述与上一节描述的偶数/奇数计数器基本相同。关于Lamport时间戳的关键思想，使它们与因果关系一致，如下所示：每个节点和每个客户端跟踪迄今为止所见到的最大计数器值，并在每个请求中包含最大计数器值。当一个节点接收到一个最大计数器值大于其自身计数器值的请求或响应时，它立即增加自己的计数器到最大值。

这如图9-8所示，其中客户端A从节点2接收计数器值5，然后将最大值5发送到节点1.此时，节点1的计数器仅为1，但是它立即向前移动到5，所以下一个操作的计数器值增加了6。

只要最大计数器值与每一个操作一起进行，这个方案确保Lamport时间戳的排序与因果性一致，因为每个因果关系导致时间戳增加。

Lamport时间戳有时会与版本向量混淆，我们在第184页上的“检测并发写入”中看到了这些向量戳。虽然存在一些相似之处，但它们具有不同的目的：版本向量可以区分两个操作是并发还是因果依赖另一个，而Lamport时间戳总是执行一个总的顺序。从Lamport的全部订购时间戳，你不能分辨两个操作是并行还是因果关系。 Lamport时间戳优于版本向量的优点是它们更紧凑。

光有时间戳排序还不够

虽然Lamport时间戳定义了与因果关系一致的操作总顺序，但它们还不足以解决分布式系统中的许多常见问题。 例如，考虑一个需要确保用户名唯一标识用户帐户的系统。如果两个用户同时尝试使用相同的用户名创建帐户，则其中一个应该成功，另一个应该失败。 （我们之前在第301页的“领导和锁定”中提到过这个问题。）

乍看之下，似乎总的操作顺序（例如，使用Lamport时间戳）应该足以解决此问题：如果创建了两个具有相同用户名的帐户，请选择时间戳较低的那个作为获胜者（一个谁先抓住用户名），并让更大的时间戳失败。由于时间戳是完全有序的，所以这个比较总是有效的。

这种方法适用于事后确定胜利者：一旦收集了系统中的所有用户名创建操作，就可以比较他们的时间戳。然而，当一个节点刚刚收到用户的一个请求来创建一个用户名，并且现在需要决定这个请求是成功还是失败，这是不够的。此时，节点不知道另一个节点是否正在同时创建具有相同用户名的帐户，以及其他节点可以分配给该操作的时间戳。

为了确保没有其他节点正在使用相同的用户名和较低的时间戳同时创建一个帐户，您必须检查每个节点，看看它在做什么[56]。如果其中一个节点由于网络问题而出现故障或无法到达，则该系统将停止工作。这不是我们需要的那种容错系统。

这里的问题是，只有在收集了所有的操作之后，操作的总顺序才会出现。如果另一个节点已经产生了一些操作，但是你还不知道它们是什么，那么就不能构造最终的操作顺序：来自另一个节点的未知操作可能需要被插入到总数的不同位置订购。

总之：为了实现像用户名的唯一性约束这样的事情，仅仅对操作进行全面的排序是不够的，您还需要知道该命令何时完成。如果您有创建用户名的操作，并且您确定没有其他节点可以在您的操作之前为全部订单插入相同用户名的声明，则可以安全地声明操作成功。

这个知道什么时候你的总订单被完成的概念被记录在总订单广播的话题中。

全局序列广播

如果你的程序只运行在一个CPU内核上，那么定义一个操作总的顺序是很容易的：它只是CPU执行的顺序。但是，在分布式系统中，让所有节点在相同的操作顺序上达成一致是非常棘手的。在最后一节中，我们讨论了按时间戳或序列号进行排序，但发现它不如单主复制（如果使用时间戳排序来实现唯一性约束，则不能容忍任何错误）。

如前所述，单引导程序复制通过选择一个节点作为引导程序来确定操作的总顺序，并对引导程序上的单个CPU核心上的所有操作进行排序。接下来的挑战是如果吞吐量大于单个领导者可以处理的情况下如何扩展系统，以及如果领导者失败（参见第156页的“处理节点中断”），如何处理故障转移。在分布式系统文献中，这个问题被称为全序广播或原子广播8【25,57,58】。

顺序保证的范围

每个分区有一个单独的引导程序的分区数据库通常只对每个分区进行排序，这意味着它们不能提供跨分区的一致性保证（例如，一致的快照，外键引用）。 所有分区的总排序是可能的，但需要额外的协调[59]。

总订单广播通常被描述为在节点之间交换消息的协议。 非正式地，它要求总是满足两个安全属性：

可靠交付（reliable delivery）

没有消息丢失：如果消息被传递到一个节点，它将被传递到所有节点。

完全有序交付（totally ordered delivery）

消息以相同的顺序传递给每个节点。

总订单广播的正确算法必须确保始终满足可靠性和订购属性，即使节点或网络出现故障。当然，在网络中断的时候，消息不会被传送，但是一个算法可以继续重试，以便在网络被最终修复的时候消息能够通过（然后它们仍然必须按照正确的顺序传送）。

使用全序广播

像ZooKeeper和etcd这样的共识服务实际上是实现全面的订单播放。这个事实暗示了整个命令广播和共识之间有着密切的联系，我们将在本章后面进行探讨。

总订单广播正是您所需的数据库复制：如果每封邮件都表示写入数据库，并且每个副本按相同的顺序处理相同的写入，则副本将保持一致（除了临时复制滞后）。这个原则被称为状态机复制[60]，我们将在第11章中回到它。 类似地，可以使用总订单广播来实现可序列化的事务：如第242页上的“实际的串行执行”中所述，如果每个消息表示一个确定性事务作为存储过程来执行，并且每个节点都处理这些消息相同的顺序，那么数据库的分区和副本保持一致[61]。

总订单广播的一个重要方面是订单在交付消息时是固定的：如果后续消息已经交付，节点不允许追溯地将消息插入订单中的较早位置。这个事实使得全部命令广播比时间戳命令更强。

查看总订单广播的另一种方式是创建日志（如在复制日志，事务日志或预写日志中）：传递消息就像附加到日志。由于所有节点必须以相同的顺序传递相同的消息，因此所有节点都可以读取日志并看到相同的消息序列。

全面订购广播对于实施提供防护令牌的锁定服务也很有用（请参见第294页的“防护令牌”）。每个获取锁的请求都作为消息添加到日志中，并且所有消息都按它们在日志中出现的顺序依次编号。序列号可以作为一个击剑标记，因为它是单调递增的。在ZooKeeper中，这个序列号被称为zxid [15]。

使用全序广播实现线性化的存储

如图9-4所示，在可线性化的系统中，有一个操作的总顺序。这是否意味着线性化与总订单播放相同？不完全，但两者之间有密切的联系9。

全部订单广播是异步的：消息被保证以固定的顺序可靠地传送，但是不能保证消息何时被传送（所以一个接收者可能落后于其他接收者）。相比之下，线性化是最近的保证：读取保证看到写入的最新值。

但是，如果您有全面的订单广播，则可以在其上构建线性化存储。例如，您可以确保用户名唯一标识用户帐户。

想象一下，对于每一个可能的用户名，你都可以拥有一个带有原子比较和设置操作的线性化寄存器。每个寄存器最初的值为空值（表示不使用用户名）。当用户想要创建一个用户名时，对该用户名的注册表执行比较设置操作，在前一个注册值为空的情况下，将其设置为用户账号。如果多个用户试图同时获取相同的用户名，则只有一个比较和设置操作会成功，因为其他用户将看到非空值（由于线性化）。

您可以通过使用全部命令广播作为仅追加日志[62,63]来执行如下可线性化的比较和设置操作：

  1. 在日志中添加一条消息，暂时指明您要声明的用户名。
  2. 阅读日志，并等待你附加的信息被传回给你。10
  3. 检查是否有任何消息声称你想要的用户名。如果所需用户名的第一条消息是你自己的消息，那么你是成功的：你可以提交用户名声明（也许通过附加另一条消息到日志）并确认给客户端。如果所需用户名的第一条消息来自其他用户，则中止操作。

由于日志条目以相同顺序传递到所有节点，因此如果有多个并发写入，则所有节点将首先同意哪个节点。选择第一个冲突的写入作为胜利者，并中止后面的写入，确保所有节点都同意写入是提交还是中止。一个类似的方法可以用来在一个日志之上实现可序列化的多对象事务[62]。

虽然此过程确保可线性写入，但不能保证线性化读取 - 如果您从与日志异步更新的存储中读取数据，则可能是陈旧的。 （具体来说，这里描述的过程提供了顺序一致性[47,64]，有时也称为时间线一致性[65,66]，这比线性化要弱一些）。为了使读取线性化，有几个选项：

  • 您可以通过附加消息，读取日志以及在消息被传回给您时执行实际读取来对日志进行排序。消息在日志中的位置因此定义了读取发生的时间点。 （法定读取etcd的工作有点像这样[16]。）
  • 如果日志允许以线性方式获取最新日志消息的位置，则可以查询该位置，等待直到该位置的所有条目传送给您，然后执行读取。 （这是Zoo-Keeper的sync（）操作背后的思想[15]）。
  • 您可以从写入时同步更新的副本进行读取，因此可以确保最新。 （这种技术用于链式复制[63];另请参阅第155页上的“复制研究”。）

使用线性化存储实现总订单广播

最后一节介绍了如何从全部命令广播中构建一个线性化的比较和设置操作。我们也可以把它转过来，假设我们有可线性化的存储，并展示如何从它构建全部命令播放。

最简单的方法是假设你有一个线性化的寄存器来存储一个整数，并且有一个原子增量和获取操作[28]。或者，原子比较和设置操作也可以完成这项工作。

该算法很简单：对于每个要通过全部订单广播发送的消息，您将递增并获取可线性化的整数，然后将从寄存器获得的值作为序号附加到消息中。然后，您可以将消息发送到所有节点（重新发送任何丢失的消息），并且收件人将按序号连续发送消息。

请注意，与Lamport时间戳不同，您通过递增可线性化寄存器获得的数字形成一个没有间隙的序列。因此，如果一个节点已经发送了消息4并且接收到序列号为6的传入消息，则它知道它在传递消息6之前必须等待消息5.同样的情况并非如此

与Lamport时间戳 - 事实上，这是总订单广播和时间戳订购之间的关键区别。

使用原子增量和获取操作来创建线性化整数有多困难？像往常一样，如果事情从来没有失败过，那很容易：你可以把它保存在一个节点的变量中。问题在于处理当该节点的网络连接中断时的情况，并在该节点失败时恢复该值[59]。一般来说，如果你对可线性化序列号的产生者认真思考，你不可避免地会得出一个一致的算法。

这并非巧合：可以证明，线性化的比较和设置（或增量和取得）寄存器和全部命令广播都相当于[28，67]。也就是说，如果你能解决其中的一个问题，你可以把它转化成为其他问题的解决方案。这是相当深刻和令人惊讶的洞察力！

现在是时候正面处理共识问题了，我们将在本章的其余部分进行讨论。

分布式事务与共识

共识是分布式计算中最重要也是最基本的问题之一。从表面上看，似乎很简单：非正式地说，目标只是让几个节点达成一致。你可能会认为这不应该太难。不幸的是，许多破损的系统已经被误认为这个问题很容易解决。 虽然共识是非常重要的，但关于它的部分在本书的后半部分已经出现了，因为这个主题非常微妙，欣赏细微之处需要一些必要的知识。即使在学术研究界，对共识的理解也只是在几十年的时间内逐渐显现出来，一路上有许多误解。现在我们已经讨论了复制（第5章），事务（第7章），系统模型（第8章），线性化以及总播放（本章），我们终于准备好解决共识问题了。

在节点达成一致的情况下，有许多情况是很重要的。例如：

领导选举

​ 在具有单引导程序复制的数据库中，所有节点需要就哪个节点是领导者达成一致。如果一些节点由于网络故障而无法与其他节点通信，则可能会引起争议。在这种情况下，一致性对于避免错误的故障切换非常重要，从而导致两个节点都认为自己是领导者的分裂大脑情况（请参阅第156页的“处理节点中断”）。如果有两个领导者，他们都会接受写入，他们的数据会发生分歧，导致不一致和数据丢失。

原子提交

在支持跨越多个节点或分区的事务的数据库中，有一个事务可能在某些节点上失败，但在其他节点上成功。如果我们想要维护事务的原子性（就ACID而言，请参阅第223页的“原子性”），我们必须让所有节点对事务的结果达成一致：要么全部中止/回滚（如果出现任何错误）或者他们都承诺（如果没有出错）。这个共识的例子被称为原子提交问题[^xii]。

[^]: 原子提交的形式化与共识稍有不同：原子事务只有在所有参与者投票提交的情况下才能提交，如果有任何参与者需要中止，则必须中止。 允许共识决定其中一位参与者提出的任何价值。 然而，原子的承诺和共识是可以相互压缩的[70,71]。 非阻塞原子提交比共识更难 - 请参阅第359页上的“三阶段提交”。

共识的不可能性

您可能已经听说过作者Fischer，Lynch和Paterson之后的FLP结果[68]，这证明如果存在节点可能崩溃的风险，则不存在总是能够达成一致的算法。在分布式系统中，我们必须假设节点可能会崩溃，所以可靠的共识是不可能的。然而，在这里，我们正在讨论达成共识的算法。这里发生了什么？

答案是FLP结果在异步系统模型中得到了证明（请参阅“系统模型与现实”在本部分），这是一个非常有限的模型，它假定确定性算法不能使用任何时钟或超时。如果算法被允许使用超时或其他方法来识别可疑的崩溃节点（即使怀疑有时是错误的），那么共识就变得可以解决了[67]。即使只允许算法使用随机数也足以绕过不可能的结果[69]。 因此，FLP虽然不可能达成共识，但理论上具有重要意义，但实际上分布式系统通常可以达成共识。

在本节中，我们将首先更详细地检查原子提交问题。具体来说，我们将讨论两阶段提交（2PC）算法，这是解决原子提交最常见的方法，并在各种数据库，消息传递系统和应用服务器中实现。事实证明，2PC是一种一致的算法，但不是一个很好的[70,71]。

通过从2PC学习，我们将继续努力实现更好的一致性算法，比如ZooKeeper（Zab）和etcd（Raft）中使用的算法。

原子提交与二阶段提交（2PC）

在第7章中，我们了解到事务原子性的目的是在出现几次写错的情况下提供简单的语义。事务的结果要么是成功的提交，在这种情况下，所有事务的写入都是持久的，或者中止，在这种情况下，所有事务的写入都被回滚（即撤消或丢弃）。

原子性可以防止失败的事务乱丢数据库，其结果是半成品和半更新状态。这对于多对象事务（请参阅“单对象和多对象操作”一节第228页）和维护二级索引的数据库尤其重要。每个辅助索引都是与主数据分离的数据结构 - 因此，如果您修改了一些数据，则还需要在辅助索引中进行相应的更改。原子性确保二级索引与主数据保持一致（如果索引与主数据不一致，则不会非常有用）。

从单节点到分布式原子提交

对于在单个数据库节点执行的事务，原子性通常由存储引擎执行。当客户端请求数据库节点提交事务时，数据库使事务的写入持久化（通常在预先写好的日志中;请参阅第82页的“使B树可靠”），然后将提交记录追加到日志中磁盘。如果数据库在这个过程中间崩溃，当节点重新启动时，事务从日志中恢复：如果提交记录在崩溃之前成功地写入磁盘，则认为事务被提交;如果不是，则来自该事务的任何写入都被回滚。

因此，在单个节点上，事务承诺主要取决于数据持久写入磁盘的顺序：首先是数据，然后是提交记录[72]。事务提交或放弃的关键决定时刻是磁盘完成写入提交记录的时刻：在此之前，仍有可能中止（由于崩溃），但在此之后，事务提交 - 特德（即使数据库崩溃）。因此，这是一个单一的设备（一个特定的磁盘驱动器的控制器，连接到一个特定的节点），使提交原子。

但是，如果一个事务中涉及多个节点呢？例如，也许在分区数据库中有一个多对象事务，或者是一个由术语分区的二级索引（其中索引条目可能位于与主数据不同的节点上;请参阅“分区和二级索引”第206页）。大多数“NoSQL”分布式数据存储不支持这种分布式事务，而是各种集群关系系统（请参见“实践中的分布式事务”）。

在这些情况下，仅向所有节点发送提交请求并且独立提交每个节点的事务是不够的。这样做很容易发生，提交在一些节点上成功，在其他节点上失败，这违反了原子性保证：

  • 某些节点可能会检测到约束冲突或冲突，因此需要中止，而其他节点则可以成功进行提交。
  • 某些提交请求可能在网络中丢失，最终由于超时而中止，而其他提交请求则通过。
  • 在提交记录完全写入之前，某些节点可能会崩溃，并在恢复时回滚，而其他节点则成功提交。

如果某些节点提交了事务，但其他节点却放弃了这些事务，那么这些节点就会彼此不一致（如图7-3所示）。而且一旦在一个节点上提交了一个事务，如果事后证明它在另一个节点上被中止，它将不能被收回。出于这个原因，一旦确定事务中的所有其他节点也将提交，节点就必须进行提交。

事务提交必须是不可撤销的 - 您不得改变主意，并在交易提交后追溯中止交易。这个规则的原因是，一旦数据被提交，其他交易就可以看到，因此其他客户可能会开始依赖这些数据。这个原则构成了读取提交隔离的基础，在“读取提交”一节中讨论了这个问题。如果一个事务在提交后被允许中止，所有读取提交数据的事务将基于被追溯声明不存在的数据所以他们也必须恢复。

（承诺交易的效果有可能在后来被另一个补偿交易取消[73,74]，但从数据库的角度来看，这是一个单独的交易，因此任何交叉交易的正确性要求是应用程序的问题。）

介绍两阶段提交

两阶段提交是一种用于实现跨多个节点的原子事务提交的算法，即确保这一点

图9-9 两阶段提交（2PC）的成功执行

不要混淆2PC和2PL

两阶段提交（2PC）和两阶段锁定（请参阅第257页上的“两阶段锁定（2PL）”）是两个完全不同的事情。 2PC在分布式数据库中提供原子提交，而2PL提供可序列化的隔离。为了避免混淆，最好把它们看作完全独立的概念，并忽略名称中的不幸的相似性。

2PC使用一个通常不会出现在单节点事务中的新组件：协调器（也称为事务管理器）。协调器通常在请求事务的相同应用程序进程（例如，嵌入在Java EE容器中）中实现为库，但也可以是单独的进程或服务。这种协调员的例子包括Narayana，JOTM，BTM或MSDTC。

正常情况下，2PC事务从应用程序在多个数据库节点上读写数据开始。我们把这些数据库节点称为交易参与者。当应用程序准备提交时，协调器开始阶段1：它发送一个准备请求到每个节点，询问他们是否能够提交。协调员然后跟踪参与者的回应：

  • 如果所有参与者都回答“是”，表示他们已经准备好提交，那么协调员在阶段2发出提交请求，实际发生提交。
  • 如果任何参与者回复“否”，则协调员在阶段2中向所有节点发送放弃请求。

这个过程有点像西方传统婚姻仪式：部长要求新娘和新郎分别是否要结婚，而且通常都是从两个方面接受“我做”的答案。收到两者都恢复后，因为参与者投票“是”，它不能拒绝提交时恢复。

因此，该协议包含两个关键的“不归路”点：当参与者投票“是”时，它承诺它肯定能够稍后提交（尽管协调员可能仍然选择放弃）。一旦协调员决定，这个决定是不可撤销的。这些承诺保证了2PC的原子性。 （单节点原子提交将这两个事件合并为一个：将提交记录写入事务日志。）

回到婚姻的比喻，在说“我是”之前，你和你的新娘/新郎有“放弃”这个交易的自由，说“不行！”（或者这个）。然而，在说“我这样做”之后，你不能收回那个声明。如果你说“我这样做”后你晕了，而你没有听到部长说“你现在是夫妻”，那不会改变交易的事实。当你稍后恢复意识时，你可以通过查询部长的全球交易ID状态来查明你是否已婚，或者你可以等待部长下一次提交请求的重试（因为重试将一直持续下去你的无意识的时期）。

承诺体系

从这个简短的描述可能不清楚为什么两阶段提交确保了原子性，而跨几个节点的一阶段提交没有。准备和提交请求当然可以在两阶段的情况下轻易地丢失。 2PC有什么不同？

为了理解它的工作原理，我们必须更详细地分解这个过程：

  1. 当应用程序想要开始一个分布式事务时，它向协调器请求一个事务ID。此交易ID是全球唯一的。
  2. 应用程序在每个参与者上开始单节点事务，并将全局唯一事务ID附加到单节点事务。所有的读写都是在这些单节点事务之一中完成的。如果在这个阶段出现任何问题（例如，节点崩溃或请求超时），则协调者或任何参与者都可以中止。
  3. 当应用程序准备提交时，协调器向所有参与者发送一个准备请求，标记为全局事务ID。如果这些请求中的任何一个失败或超时，则协调器向所有参与者发送针对该交易ID的放弃请求。
  4. 参与者收到准备请求时，确保在任何情况下都可以明确地进行交易。这包括将所有事务数据写入磁盘（出现故障，电源故障或硬盘空间不足以拒绝稍后提交）以及检查是否存在任何冲突或约束违规。通过向协调者回答“是”，节点承诺在没有错误的情况下提交交易。换句话说，参与者放弃了放弃交易的权利，但没有实际承诺。
  5. 当协调员收到所有准备请求的答复时，就是否提交或中止交易作出明确的决定（只有在所有参与者投赞成票的情况下才提交）。协调员必须把这个决定写到磁盘上的事务日志中，以便它知道它决定的方式，以防随后发生崩溃。这被称为提交点。
  6. 一旦协调员的决定写入磁盘，提交或放弃请求被发送给所有参与者。如果此请求失败或超时，则协调员必须一直重试，直到成功为止。没有更多的事情要做，如果做出决定，那么决定必须执行，不管它需要多少次重试。如果参与者在此期间坠毁，交易将在恢复时进行 - 由于参与者投票“是”，因此恢复时不能拒绝提交。

因此，该协议包含两个关键的“不归路”点：当参与者投票“是”时，它承诺它肯定能够稍后提交（尽管协调员可能仍然选择放弃）。一旦协调员决定，这个决定是不可撤销的。这些承诺保证了2PC的原子性。 （单节点原子提交将这两个事件合并为一个：将提交记录写入事务日志。）

回到婚姻的比喻，在说“我是”之前，你和你的新娘/新郎有“放弃”这个交易的自由，说“不行！”（或者这个）。然而，在说“我这样做”之后，你不能收回那个声明。如果你说“我这样做”后你晕了，而你没有听到部长说“你现在是夫妻”，那不会改变交易的事实。当你稍后恢复意识时，你可以通过查询部长的全球交易ID状态来查明你是否已婚，或者你可以等待部长下一次提交请求的重试（因为重试将一直持续下去你的无意识的时期）。

协调者失效

我们已经讨论了在2PC期间如果其中一个参与者或网络发生故障会发生什么情况：如果任何一个准备请求失败或者超时，协调员就中止交易。如果任何提交或中止请求失败，协调器将无条件重试。但是，如果协调员崩溃，会发生什么情况不太清楚。

如果协调员在发送准备请求之前失败，参与者可以安全地中止交易。但是，一旦参与者收到了准备请求并投了“是”，就不能再单方面放弃 - 必须等待协调者回答交易是否已经发生或中止。如果此时协调器崩溃或网络出现故障，参与者只能等待。参与者在这个状态下的交易被怀疑或不确定。

情况如图9-10所示。在这个特定的例子中，协调器实际上决定提交，数据库2收到提交请求。但是，协调器在将提交请求发送到数据库1之前发生崩溃，因此数据库1不知道是否提交或中止。即使超时在这里也没有帮助：如果数据库1在超时后单方面中止，它将最终与提交的数据库2不一致。同样，单方面犯也是不安全的，因为另一个参与者可能已经中止了。

 图9-10 参与者投赞成票后，协调员崩溃。数据库1不知道是否提交或中止

没有协调员的消息，参与者无法知道是否承诺或放弃。原则上，参与者可以相互沟通，找出每个参与者如何投票并达成一致，但这不是2PC协议的一部分。

2PC可以完成的唯一方法是等待协调员恢复。这就是为什么协调员必须在向参与者发送提交或中止请求之前将其提交或中止决定写入磁盘上的事务日志：协调器恢复后，通过读取其事务日志来确定所有有疑问的事务的状态。任何在协调器日志中没有提交记录的事务都会中止。因此，2PC的提交点归结为协调器上的常规单节点原子提交。

三阶段提交

两阶段提交被称为阻塞原子提交协议，因为2PC可能卡住等待协调器恢复。理论上，可以使一个原子提交协议非阻塞，以便在节点失败时不会卡住。但是，在实践中做这个工作并不那么简单。

作为2PC的替代方案，已经提出了一种称为三阶段提交（3PC）的算法[13,80]。然而，3PC假定一个有界延迟的网络和有限响应时间的节点;在大多数具有无限网络延迟和进程暂停的实际系统中（见第8章），它不能保证原子性。

通常，非阻塞原子提交需要一个完美的故障检测器[67,71] - 即一个可靠的机制来判断一个节点是否已经崩溃。在无限延迟的网络中，超时不是可靠的故障检测器，因为即使没有节点崩溃，请求也可能由于网络问题而超时。出于这个原因，2PC继续被使用，尽管协调器故障的已知问题。

实践中的分布式事务

分布式事务，尤其是那些通过两阶段提交实现的事务，声誉混杂。一方面，它们被看作是提供一个难以实现的重要的安全保证;另一方面，他们被批评为造成运营问题，造成业绩下滑，承诺超过他们能够实现的目标[81,82,83,84]。许多云服务由于其产生的操作问题而选择不执行分布式事务[85,86]。

分布式事务的某些实现会带来严重的性能损失 - 例如，MySQL中的分布式事务被报告比单节点事务慢10倍以上[87]，所以当人们建议不要使用这些事务时就不足为奇了。两阶段提交所固有的大部分性能成本是由于崩溃恢复所需的额外磁盘强制（fsync）[88]以及额外的网络往返。

但是，我们不应该直接抛弃分布式交易，而应该更加详细地审视这些交易，因为从中可以汲取重要的经验教训。首先，我们应该精确地说明“分布式交易”的含义。两种截然不同的分布式交易类型经常被混淆：

数据库内部的分布式事务

一些分布式数据库（即在其标准配置中使用复制和分区的数据库）支持该数据库节点之间的内部事务。例如，VoltDB和MySQL Cluster的NDB存储引擎就有这样的内部事务支持。在这种情况下，所有参与交易的节点都运行相同的数据库软件。

异构分布式事务

在异构交易中，参与者有两种或两种以上不同的技术：例如来自不同供应商的两个数据库，甚至是非数据库系统（如消息代理）。跨系统的分布式事务必须确保原子提交，尽管系统可能完全不同。

数据库内部事务不必与任何其他系统兼容，因此他们可以使用任何协议并应用特定技术的特定优化。因此，数据库内部的分布式事务通常可以很好地工作。另一方面，跨越异构技术的交易则更具挑战性。

恰好一次的消息处理

异构的分布式事务处理能够以强大的方式集成不同的系统。例如，当且仅当用于处理消息的数据库事务处理时，来自消息队列的消息才能被确认为已处理成功承诺。这是通过自动提交消息确认和数据库写入单个事务来实现的。使用分布式事务支持，即使消息代理和数据库是在不同机器上运行的两个不相关技术，也是可能的。

如果消息传递或数据库事务失败，两者都会中止，因此消息代理可能会稍后安全地重新传递消息。因此，通过自动提交消息及其处理的副作用，即使在成功之前需要几次重试，也可以确保消息被有效处理一次。中止放弃部分完成的交易的任何副作用。

这样的分布式事务只有在所有受事务影响的系统都能够使用相同的原子提交协议的情况下才是可能的。例如，处理消息的副作用是发送邮件，而邮件服务器不支持两阶段提交：如果邮件处理失败并重试，可能会发送两次或更多次的邮件。但是，如果处理消息的所有副作用在事务中止时回滚，那么可以安全地重新尝试处理步骤，就好像什么都没发生过一样。

我们将回到第11章中的一次消息处理的主题。让我们首先看看允许这种异构分布式事务的原子提交协议。

XA事务

X/Open XA（**扩展架构（eXtended Architecture）**的缩写）是跨异构技术实现两阶段提交的标准[76,77]。它于1991年推出并得到了广泛的实施：许多传统关系数据库（包括PostgreSQL，MySQL，DB2，SQL Server和Oracle）和消息代理（包括ActiveMQ，HornetQ，MSMQ和IBM MQ） 。

XA不是一个网络协议 - 它只是一个用于与事务协调器连接的C API。此API的绑定以其他语言存在;例如，在Java EE应用程序的世界中，XA事务是使用Java事务API（JTA）实现的，而Java事务API（JTA）则由许多用于使用Java数据库连接（JDBC）的数据库驱动程序以及使用Java消息服务（JMS）API。

XA假定您的应用程序使用网络驱动程序或客户端库来与参与者数据库或消息传递服务进行通信。如果驱动程序支持XA，则表示它调用XA API以查明操作是否应该是分布式事务的一部分 - 如果是，则将必要的信息发送到数据库服务器。司机还会提供回调，协调员可以通过回调来要求参与者准备，提交或中止。

事务协调器实现XA API。标准没有指定应该如何实现，但实际上，协调器通常只是一个库，与发出事务的应用程序（不是单独的服务）一起被加载到相同的进程中。它跟踪交易的参与者，在要求他们准备（通过回调驱动程序）之后收集参与者的回答，并使用本地磁盘上的日志记录每次交易的提交/中止决定。

如果应用程序进程崩溃，或者运行应用程序的机器死亡，协调者就会使用它。然后任何有准备但未提交的交易的参与者都被怀疑。由于协调程序的日志位于应用程序服务器的本地磁盘上，因此必须重新启动该服务器，并且协调程序库必须读取日志以恢复每个事务的提交/中止结果。只有这样，协调员才能使用数据库驱动程序的XA回调来要求参与者提交或中止。数据库服务器不能直接联系协调器，因为所有通信都必须通过其客户端库。

怀疑时持有锁

为什么我们非常关心交易被怀疑？系统的其他部分不能继续工作，而忽视最终将被清理的有问题的交易吗？ 问题在于锁定。正如在第225页上的“读取已提交”中所讨论的那样，数据库事务通常对其修改的行进行行级别的排他锁定，以防止脏写入。此外，如果要使用可序列化的隔离，则使用两阶段锁定的数据库也必须对事务读取的任何行执行共享锁定（请参见“双相锁定（2PL）”（第249页））。

在事务提交或中止之前，数据库不能释放这些锁（如图9-9中的阴影区域所示）。因此，在使用两阶段提交时，交易必须在整个时间内保持锁定状态。如果协调员已经坠毁，需要20分钟才能重新启动，这些锁将会保持20分钟。如果协调员的日志由于某种原因完全丢失，这些锁将永久保存，或者至少在管理员手动解决该情况之前。

当这些锁被保留时，其他事务不能修改这些行。根据数据库的不同，其他事务甚至可能被阻止读取这些行。因此，其他交易不能简单地继续他们的业务 - 如果他们想访问相同的数据，他们将被阻止。这可能会导致大部分应用程序变得不可用，直到有问题的事务得到解决。

从协调器故障中恢复

理论上，如果协调器崩溃并重新启动，它应该干净地从日志中恢复其状态，并解决任何有问题的事务。然而，在实践中，孤立的不确定交易确实发生[89,90]，也就是说，协调者不能以任何理由决定结果的交易（例如，因为交易日志已经由于软件错误）。这些交易不能自动解决，所以他们永远坐在数据库中，持有锁和阻止其他交易。

即使重新启动数据库服务器也不能解决这个问题，因为2PC的正确实现必须在重新启动时保留一个有问题的事务的锁（否则就会冒违反原子性保证的风险）。这是一个棘手的情况。

唯一的出路是让管理员手动决定是提交还是回滚事务。管理员必须检查每个有问题的交易的参与者，确定是否有任何参与者已经提交或中止，然后将相同的结果应用于其他参与者。解决这个问题潜在地需要大量的人工努力，并且在严重的生产中断期间（否则，为什么协调员处于这样一个糟糕的状态），很可能需要在高压力和时间压力下完成。

许多XA的实现都有一个叫做启发式决策的紧急逃生舱口：允许参与者单方面决定放弃或进行一个有疑问的交易，而不需要协调员做出明确的决定[76,77,91]。要清楚的是，这里的平庸是可能破坏原子性的委婉说法，因为它违背了两阶段承诺的承诺体系。因此，启发式决策只是为了摆脱灾难性的情况，而不是经常使用。

分布式事务的限制

XA事务解决了保持多个参与者数据系统一致的真实而重要的问题，但正如我们所看到的那样，它们也引入了主要的操作问题。特别是，关键的实现是事务协调器本身就是一种数据库（在其中存储事务结果），因此需要像其他重要数据库一样小心：

  • 如果协调器没有被复制，而是只在一台机器上运行，那么整个系统是一个失败的单点（因为它的失败导致其他应用程序服务器阻塞在有问题的事务处理的锁上）。令人惊讶的是，许多协调器实现默认情况下不是高度可用，或者只有基本的复制支持。
  • 许多服务器端应用程序都是在无状态模式下开发的（受到HTTP的青睐），所有持久状态都存储在数据库中，具有应用程序服务器可随意添加和删除的优点。但是，当协调器是应用程序服务器的一部分时，它会改变部署的性质。突然间，协调员的日志成为持久系统状态的关键部分 - 与数据库本身一样重要，因为协调员日志是为了在崩溃后恢复疑问交易所必需的。这样的应用程序服务器不再是无状态的。
  • 由于XA需要与各种数据系统兼容，因此这是必须的最低公分母。例如，它不能检测到不同系统间的死锁（因为这将需要一个标准化的协议来让系统交换每个事务正在等待的锁的信息），而且它不适用于SSI（参见“可串行快照隔离（SSI） “第261页），因为这需要一个协议来识别不同系统之间的冲突。
  • 对于数据库内部的分布式事务（而不是XA），限制不是很大，例如SSI的分布式版本是可能的。然而，仍然存在2PC成功进行交易的问题，所有参与者都必须作出回应。因此，如果系统的任何部分损坏，交易也会失败。因此，分布式事务有扩大故障的趋势，这与我们构建容错系统的目标背道而驰。

这些事实是否意味着我们应该放弃保持几个系统一致的所有希望？不完全 - 有其他的方法可以让我们在没有异构分布式事务的痛苦的情况下实现同样的事情。我们将在第十一章和第十二章回到这些章节。但首先，我们应该总结一致的话题。

容错的共识

非正式地，共识意味着让几个节点达成一致。例如，如果有几个人同时尝试预订飞机上的最后一个座位或剧院中的同一个座位，或者尝试使用相同的用户名注册一个帐户，则可以使用一个一致的算法来确定哪个其中一个互不相容的行动应该是赢家。

共识问题通常形式化如下：一个或多个节点可以提出值，并且共识算法决定其中的一个值。在座位预订的例子中，当几个顾客同时试图购买最后一个座位时，处理顾客请求的每个节点可以提出正在服务的顾客的ID，并且决定指示哪个顾客获得座位。在这种形式主义中，共识算法必须满足以下性质[25]：11

一致同意

​ 没有两个节点的决定不同。

完整性

​ 没有节点决定两次。

有效性

​ 如果一个节点决定值v，则v由某个节点提出。

终止 ​ 由每个未崩溃节点来最终决定值。

统一协议和完整性属性定义了共识的核心思想：每个人都决定相同的结果，一旦你决定了，你就不能改变主意。有效性属性主要是为了排除微不足道的解决方案：例如，无论提出什么建议，都可以有一个总是决定为空的算法;该算法将满足协议和完整性属性，但不符合有效性属性。

如果你不关心容错，那么满足前三个属性很容易：你可以将一个节点硬编码为“独裁者”，并让该节点做出所有的决定。但是，如果一个节点失败，那么系统就不能再做出任何决定。事实上，这就是我们在两阶段承诺的情况下所看到的：如果协调员失败了，那么不确定的参与者就不能决定是否提交或中止。

终止财产正式形成了容错的思想。它基本上说，一个共识算法不能简单地坐下来，永远不要做任何事 - 换句话说，它必须取得进展。即使有些节点出现故障，其他节点也必须做出决定。 （终止是一种活泼的财产，而另外三种是安全财产 - 参见第308页上的“安全和活力”。）

共识的系统模型假设，当一个节点“崩溃”时，它突然消失，永远不会回来。 （而不是软件崩溃，想象一下地震，包含你的节点的数据中心被山体滑坡所摧毁，你必须假设你的节点被埋在30英尺以下的泥土中，并且永远不会回到在线状态。）这个系统模型，任何等待节点恢复的算法都不能满足终止属性。特别是2PC不符合终止的要求。

当然，如果所有的节点都崩溃，而且没有一个正在运行，那么任何算法都不可能决定什么。算法可以容忍的失败次数有一个限制：事实上，可以证明任何一致性算法都需要至少大部分节点正确运行，以确保终止[67]。大多数人可以安全地形成法定人数（请参阅第179页上的“读和写的法定人数”）。

因此，终止属性受到不到一半的节点崩溃或不可达的假设。然而，即使大多数节点出现故障或存在严重的网络问题，大多数共识的实施都能确保始终满足安全属性 - 协议，完整性和有效性[92]。因此，大规模的中断可能会阻止系统处理请求，但是它不能通过使系统做出无效的决定来破坏共识系统。

大多数一致性算法假定没有拜占庭式的错误，正如在“拜占庭式故障”一节中所讨论的那样。也就是说，如果一个节点没有正确地遵循协议（例如，如果它发送矛盾的消息到不同的节点），它可能会破坏协议的安全属性。只要少于三分之一的节点是拜占庭故障[25,93]，就可以对拜占庭故障形成共识，但我们没有空间在本书中详细讨论这些算法。

共识算法和总订单广播

最着名的容错一致性算法是视图戳复制（viewstamped replication）（VSR）[94,95]，Paxos [96,97,98,99]，Raft [22,100,101]和Zab [15,21,102] 。这些算法之间有相当多的相似之处，但它们并不相同[103]。在本书中，我们不会详细介绍不同的算法：除非你自己实现一个共识系统（这可能不是一个明智的做法），只要了解一些共同的高级思想就足够了这很难[98,104]）。

这些算法中的大多数实际上并不直接使用这里描述的形式化模型（建议和决定单个值，同时满足协议，完整性，有效性和终止性质）。相反，他们决定了一系列的值，这使得他们成为了订单广播算法，正如本章前面所讨论的那样（请参阅第348页上的“全部订单广播”）。

请记住，总订单广播要求将消息按照相同的顺序准确传送到所有节点。如果你仔细想想，这相当于进行了几轮的共识：在每一轮中，节点提出下一个要发送的消息，然后决定下一个要发送的消息总数[67]。

所以，总的订单广播相当于重复的一轮共识（每个共同的决定对应于一个消息传递）：

  • 由于协商一致意见，所有节点决定以相同的顺序传递相同的消息。

  • 由于完整性属性，消息不重复。

  • 由于有效性属性，消息不会被破坏，也不是凭空制造的。

  • 由于终止属性，消息不会丢失。

已加密的复制，Raft和Zab直接执行全部命令广播，因为这样做比重复一轮一次一致的共识更有效。在Paxos的情况下，这种优化被称为Multi-Paxos。

单领导者复制和共识

在第5章中，我们讨论了单领导者复制（参见第152页的“领导者和追随者”），它将所有的写入操作都交给领导者，并以相同的顺序将他们应用到追随者，从而使复制品保持最新状态。这不是基本上全部命令播放？我们怎么不用担心第五章的共识？

答案取决于如何选择领导者。如果领导人是由您的运营团队中的人员手动选择和配置的，那么您基本上拥有独裁种类的“一致性算法”：只允许一个节点接受写入（即，决定写入的顺序复制日志），如果该节点发生故障，则系统将无法写入，直到操作员手动配置其他节点作为主管。这样的制度在实践中可以很好地发挥作用，但是不能达到共识的终止性，因为它需要人为干预才能取得进展。

一些数据库执行自动领导者选举和故障转移，如果旧领导者失败，则促使追随者成为新的领导者（参见第156页的“处理节点中断”）。这使我们更接近容错的全面命令播出，从而达成共识。

但是，有一个问题。我们之前曾经讨论过分裂脑的问题，并且说所有的节点都需要同意领导者是谁，否则两个不同的节点都会相信自己是领导者，从而导致数据库进入不一致的状态。因此，我们需要达成共识才能选出一位领导人。但是，如果这里描述的一致性算法实际上是全序广播算法，并且全部命令广播就像单引导复制，单引导复制需要领导，那么... 看来要选一个领导，我们首先需要一个领导。要解决共识，首先要解决共识。我们如何摆脱这个难题？

时代编号和法定人数

迄今为止所讨论的所有共识协议在内部都以某种形式使用领导者，但是并不能保证领导者是独一无二的。相反，他们可以做出较弱的保证：协议定义了一个纪元号码（称为Paxos中的选票号码，Viewstamped复制中的视图号码，以及Raft中的术语号码），并确保在每个纪元中领导者是唯一的。

每当现在的领导被认为是死的时候，就会在节点之间开始投票选出一个新领导。这次选举被赋予了一个递增的时代号码，因此时代号码是完全有序的，单调递增的。如果在两个不同的时代，两个不同的领导者之间有冲突（也许是因为前一个领导者实际上并没有死亡），那么具有更高时代的领导者就占上风了。

在任何领导人被允许决定任何事情之前，必须首先检查是否没有其他具有较高时代的领导者，这可能会采取相互冲突的决定。领导者如何知道它没有被另一个节点赶下？回想一下第300页的“真理是由多数人定义的”：一个节点不一定相信自己的判断 - 只是因为节点认为它是领导者，并不一定意味着其他节点接受它作为他们的领导者。

相反，它必须从节点法定人数中收集选票（请参阅第179页上的“读和写的法定人数”）。对于领导者想要做出的每一个决定，都必须将建议值发送给其他节点，并等待法定人数的节点响应提案。法定人数通常但不总是由大部分节点组成[105]。一个节点只有在没有意识到任何具有更高纪元的其他领导者的时候才投票赞成。

因此，我们有两轮投票：一次是选一位领导人，二是投票领导人的提议。关键的看法是，这两票的法定人数必须重叠：如果一个提案的投票成功，至少有一个投票的节点也必须参加最近的领导人选举[105]。因此，如果一个提案的投票没有显示任何更高的时代，那么现在的领导者就可以得出这样的结论：没有一个更高时代的领袖选举发生了，因此可以确定它仍然是领导。然后它可以安全地决定提出的价值。

这个投票过程看起来很像两阶段提交。最大的区别是在2PC中协调器不是选出来的，而容错协议算法只需要大部分节点的投票，而2PC则要求每个参与者都做“是”的投票。而且，共识算法定义了一个恢复过程，通过这个过程，节点可以在选举出新的领导者之后进入一个一致的状态，确保总是满足安全属性。这些差异是共识算法的正确性和容错性的关键。

共识的局限性

共识算法对于分布式系统来说是一个巨大的突破：它为具有其他各种不确定性的系统带来了具体的安全属性（一致性，完整性和有效性），而且它们仍然是容错的（只要能够进行处理大多数节点正在工作和可达）。它们提供全部的命令广播，因此它们也可以容错的方式实现线性化的原子操作（参见第350页的“使用全部命令广播实现线性化存储”）。

尽管如此，它们并没有到处使用，因为它的好处是有代价的。

节点在决定之前对节点进行投票的过程是一种同步复制。如第153页的“同步与异步复制”中所述，通常将数据库配置为使用异步复制。在这种配置中，一些承诺的数据在故障转移时可能会丢失 - 但是为了获得更好的性能，许多人选择接受这种风险。

共识体系总是需要严格的多数来操作。这意味着您至少需要三个节点才能容忍一个故障（其余三个为大多数），或者至少有五个节点容忍两个故障（其余三个为五分之一）。如果网络故障切断了其余节点的某些节点，则只有大部分网络可以继续工作，其余部分将被阻塞（另请参阅“可线性化的成本”（第295页））。

大多数一致性算法假定一组参与投票的节点，这意味着您不能只添加或删除集群中的节点。对共识算法的动态成员扩展允许集群中的节点集随着时间的推移而变化，但是它们比静态成员算法要好得多。

共识系统通常依靠超时来检测失败的节点。在网络延迟高度变化的环境中，特别是在地理上分布的系统中，经常发生一个节点错误地认为由于暂时的网络问题，导致失败的原因。虽然这个错误不会损害安全属性，但频繁的领导者选举会导致糟糕的表现，因为系统最终会花费更多的时间来选择领导者而不是做任何有用的工作。

有时，共识算法对网络问题特别敏感。例如，Raft已被证明有不愉快的边缘情况[106]：如果整个网络工作正常，除了一个特定的网络连接一直不可靠，Raft可以进入领导层不断在两个节点之间弹跳的情况，或者目前的领导者不断被迫辞职，所以这个制度从来没有取得进展。其他一致性算法也存在类似的问题，而对不可靠网络更具鲁棒性的设计算法仍然是一个开放的研究问题。

成员与协调服务

像ZooKeeper或etcd这样的项目通常被描述为“分布式键值存储”或“协调和配置服务”。这种服务的API看起来非常像数据库：你可以读写给定键的值，并遍历键。所以如果他们基本上是数据库的话，他们为什么要全力实施一个共识算法呢？是什么使他们不同于任何其他类型的数据库？

为了理解这一点，简单探讨如何使用像ZooKeeper这样的服务是有帮助的。作为应用程序开发人员，您很少需要直接使用ZooKeeper，因为它实际上不适合作为通用数据库。更有可能的是，通过其他项目间接依赖它，例如HBase，Hadoop YARN，OpenStack Nova和Kafka都依赖ZooKeeper在后台运行。这些项目从中得到什么？

ZooKeeper和etcd被设计为容纳少量完全可以放在内存中的数据（虽然它们仍然写入磁盘以保持持久性），所以你不希望在这里存储所有的应用程序的数据。使用容错全序广播算法在所有节点上复制少量的数据。正如前面所讨论的那样，全部命令广播就是数据库复制所需要的：如果每条消息代表对数据库的写入，则以相同的顺序应用相同的写入操作可以保持副本之间的一致性。

ZooKeeper模仿Google的Chubby锁定服务[14,98]，不仅实现了全面的命令广播（因此也实现了共识），而且还构建了一组有趣的其他特性，这些特性在构建分布式系统时变得特别有用：

线性化的原子操作

使用原子比较和设置操作，可以实现锁定：如果多个节点同时尝试执行相同的操作，则只有其中一个节点会成功。共识协议保证了操作将是原子性和线性化的，即使节点发生故障或网络在任何时候都被中断。分布式锁通常作为一个租约来实现，这个租约有一个到期时间，以便在客户端失败的情况下最终被释放（请参阅第295页上的“进程暂停”）。

操作的总排序

如“页首301和锁定”中所述，当某个资源受到锁定或租约的保护时，您需要一个防护令牌来防止客户端在进程暂停的情况下彼此冲突。击剑标记是每次获得锁定时单调增加的数字。 ZooKeeper通过完全排序所有操作，并为每个操作提供一个单调递增的事务ID（zxid）和版本号（cversion）来提供这个功能[15]。

故障检测

客户端在ZooKeeper服务器上维护一个长期的会话，客户端和服务器周期性地交换心跳来检查另一个节点是否还活着。即使连接暂时中断，或者ZooKeeper节点失败，会话仍保持活动状态。但是，如果心跳停止持续时间超过会话超时，ZooKeeper会声明该会话已经死亡。当会话超时（ZooKeeper调用这些临时节点）时，会话持有的任何锁都可以配置为自动释放。

更改通知

一个客户端不仅可以读取其他客户端创建的锁和值，还可以监视其中的更改。因此，客户端可以找出另一个客户端何时加入集群（基于它写入ZooKeeper的值），还是另一个客户端发生故障（因为其会话超时并且其临时节点消失）。通过订阅通知，客户避免了不得不经常轮询以找出变化。

在这些特征中，只有线性化的原子操作才需要达成共识。但是，这些功能的结合使得像ZooKeeper这样的系统在分布式协调中非常有用。

将工作分配给节点

ZooKeeper / Chubby模型运行良好的一个例子是，如果您有几个流程或服务的实例，并且需要选择其中一个实例作为leader或primary。如果领导失败，其他节点之一应该接管。这对于单引导数据库当然是有用的，但对于作业调度程序和类似的有状态系统也是有用的。

另一个例子是，当你有一些分区资源（数据库，消息流，文件存储，分布式参与者系统等），并需要决定将哪个分区分配给哪个节点时。当新节点加入群集时，需要将某些分区从现有节点移动到新节点，以便重新平衡负载（请参阅第195页的“重新平衡分区”）。当节点被移除或失败时，其他节点需要接管失败节点的工作。

这些类型的任务可以通过在ZooKeeper中明智地使用原子操作，各种节点和通知来实现。如果正确完成，这种方法允许应用程序自动从故障中恢复，无需人工干预。尽管Apache Curator [17]等库已经出现在ZooKeeper客户端API的顶层提供了更高级别的工具，但这样做并不容易，但它仍然比尝试从头开始实现必要的一致性算法要好得多，成绩不佳[107]。

应用程序最初只能在单个节点上运行，但最终可能会增长到数千个节点。试图在如此之多的节点上进行多数选票将是非常低效的。相反，ZooKeeper在固定数量的节点（通常是三到五个）上运行，并在这些节点之间执行其多数票，同时支持潜在的大量客户端。因此，ZooKeeper提供了一种将协调节点（共识，操作排序和故障检测）的一些工作“外包”到外部服务的方式。

通常，由ZooKeeper管理的数据的类型变化十分缓慢：代表“分区7中的节点运行在10.1.1.23上”的信息可能会在几分钟或几小时的时间内发生变化。它不是用来存储应用程序的运行时状态的，每秒可能会改变数千甚至数百万次。如果应用程序状态需要从一个节点复制到另一个节点，则可以使用其他工具（如Apache BookKeeper [108]）。

服务发现

ZooKeeper，etcd和Consul也经常用于服务发现 - 也就是找出你需要连接到哪个IP地址才能到达特定的服务。在云数据中心环境中，虚拟机连续来去常见，您通常不会提前知道您的服务的IP地址。相反，您可以配置您的服务，使其在启动时注册服务注册表中的网络端点，然后可以由其他服务找到它们。

但是，服务发现是否需要达成共识还不太清楚。 DNS是查找服务名称的IP地址的传统方式，它使用多层缓存来实现良好的性能和可用性。从DNS读取是绝对不可线性化的，如果DNS查询的结果有点陈旧，通常不会有问题[109]。 DNS对网络中断的可靠性和可靠性更为重要。

尽管服务发现并不需要共识，但领导者选举却是如此。因此，如果您的共识系统已经知道领导是谁，那么也可以使用这些信息来帮助其他服务发现领导是谁。为此，一些共识系统支持只读缓存副本。这些副本异步接收共识算法所有决策的日志，但不主动参与投票。因此，它们能够提供不需要线性化的读取请求。

成员服务

ZooKeeper和朋友们可以看作是成员服务研究的悠久历史的一部分，这个历史可以追溯到20世纪80年代，并且对建立高度可靠的系统（例如空中交通管制）非常重要[110]。

成员资格服务确定哪些节点当前处于活动状态并且是群集的活动成员。正如我们在第8章中看到的那样，由于无限的网络延迟，无法可靠地检测到另一个节点是否发生故障。但是，如果你通过一致的方式进行故障检测，那么节点可以就哪些节点应该被认为是存在或不存在达成一致。

即使它确实存在，仍然可能发生一个节点被错误地宣布死于共识。但是对于一个系统来说，在哪些节点构成当前的成员关系方面是非常有用的。例如，选择领导者可能意味着简单地选择当前成员中编号最小的成员，但如果不同的节点对现有成员的成员有不同意见，则这种方法将不起作用。

本章小结

在本章中，我们从几个不同的角度研究了一致性和共识的主题。我们深入研究了线性化（一种流行的一致性模型）：其目标是使复制的数据看起来好像只有一个副本，并使所有操作都以原子方式运行。虽然线性化因为易于理解而变得很吸引人 - 它使数据库在单线程程序中表现得像一个变量一样，但它具有速度慢的缺点，特别是在网络延迟较大的环境中。

我们还探讨了因果关系，这个因果关系对系统中的事件进行了排序（根据原因和结果发生在什么之前）。与线性化不同，线性化将所有操作放在单一的完全有序的时间线中，因果性为我们提供了一个较弱的一致性模型：有些东西可以是并发的，所以版本历史就像是一个分支和合并的时间线。因果一致性不具备线性化的协调开销，并且对网络问题的敏感性要低得多。

但是，即使我们捕捉到因果顺序（例如使用Lamport时间戳），我们也看到有些事情不能以这种方式实现：在“时间戳排序不够充分”的第347页中，我们考虑了确保用户名是唯一的，并拒绝同一用户名的并发注册。如果一个节点要接受注册，则需要知道另一个节点不是同时注册相同名称的过程。这个问题导致我们达成共识。

我们看到，达成共识意味着决定一件事情，使所有节点对所做决定达成一致，从而决定是不可撤销的。通过一些挖掘，事实证明，广泛的问题实际上可以归结为共识，并且彼此是等价的（从这个意义上说，如果你有一个解决方案，你可以很容易地将它转换成解决方案之一其他）。这种等同的问题包括：

线性化的比较和设置寄存器

寄存器需要基于当前值是否等于操作中给定的参数，自动决定是否设置其值。

原子事务提交

数据库必须决定是否提交或中止分布式事务。

全部订单广播

消息传递系统必须决定传递消息的顺序。

锁和租约

当几个客户争抢锁或租约时，锁决定哪个客户成功获得。

会员/协调服务

给定故障检测器（例如，超时），系统必须决定哪些节点处于活动状态，哪些应该被认为是死的，因为它们的会话超时。

唯一性约束

当多个事务同时尝试使用相同的密钥创建冲突记录时，约束必须决定哪一个允许，哪个会违反约束而失败。

如果您只有一个节点，或者您愿意将决策功能分配给单个节点，所有这些都很简单。这就是在一个单独的领导者数据库中发生的事情：决策的所有权力归属于领导者，这就是为什么这样的数据库能够提供线性化操作，唯一性约束，完全有序的复制日志等等。

但是，如果单个领导失败，或者如果网络中断导致领导不可达，则这样的系统变得无法取得进展。处理这种情况有三种方法：

  1. 等待领导者恢复，同时接受系统将被阻止。许多XA / JTA事务协调员选择这个选项。这种方法并不能完全解决共识，因为它不能满足终止财产的要求：如果领导者没有恢复，系统可以被永久封锁。
  2. 通过让人类选择一个新的领导者节点并重新配置系统来使用它来手动故障切换。许多关系数据库都采用这种方法。这是一种“上帝的行为”的共识 - 计算机系统之外的操作人员做出决定。故障转移的速度受到人类行动速度的限制，通常比计算机慢。
  3. 使用算法自动选择一个新的领导。这种方法需要一个一致的算法，建议使用经过验证的算法来正确处理不利的网络条件[107]。

尽管一个单独的领导者数据库可以提供线性化，而不需要在每个写作上执行一致的算法，但是仍然需要达成共识以保持领导力和领导力的改变。因此，从某种意义上说，有一个领导者只是“把罐子放在路上”：共识还是需要的，只是在一个不同的地方，而不是频繁的。好消息是，容错算法和共识系统存在，我们在本章中简要地讨论它们。

像ZooKeeper这样的工具在提供应用程序可以使用的“外包”协议，故障检测和会员服务方面起着重要的作用。使用起来并不容易，但比开发自己的算法要好得多，可以承受第8章讨论的所有问题。如果你发现自己想要做一个可以归结为一致的东西，而且你想要它要容错，那么建议使用类似ZooKeeper的东西。

尽管如此，并不是每个系统都需要达成共识：例如，无领导者和多领导者复制系统通常不会使用全球共识。这些系统中出现的冲突（参见第171页的“处理冲突”）是不同领导者之间达成共识的结果，但也许没关系：也许我们只需要处理没有线性化的东西，学会更好地工作具有分支和合并版本历史记录的数据。

本章引用了大量关于分布式系统理论的研究。虽然理论论文和证明并不总是容易理解，有时也会做出不切实际的假设，但它们对于通知这一领域的实际工作是非常有价值的：它们帮助我们推理什么可以做，不可以做什么，帮助我们找到违反直觉的方法其中分布式系统往往是有缺陷的。如果你有时间，这些参考资料是值得探索的。

我们在本书第二部分的末尾介绍了复制（第5章），分区（第6章），事务（第7章），分布式系统故障模型（第8章）以及最后的一致性和共识第9章）。现在我们已经奠定了坚实的理论基础，在第三部分我们将再次转向更实用的系统，并讨论如何从异构构建块中构建强大的应用程序。

参考文献

  1. Peter Bailis and Ali Ghodsi: “Eventual Consistency Today: Limitations, Extensions, and Beyond,” ACM Queue, volume 11, number 3, pages 55-63, March 2013. doi:10.1145/2460276.2462076

  2. Prince Mahajan, Lorenzo Alvisi, and Mike Dahlin: “Consistency, Availability, and Convergence,” University of Texas at Austin, Department of Computer Science, Tech Report UTCS TR-11-22, May 2011.

  3. Alex Scotti: “Adventures in Building Your Own Database,” at All Your Base, November 2015.

  4. Peter Bailis, Aaron Davidson, Alan Fekete, et al.: “Highly Available Transactions: Virtues and Limitations,” at 40th International Conference on Very Large Data Bases (VLDB), September 2014. Extended version published as pre-print arXiv:1302.0309 [cs.DB].

  5. Paolo Viotti and Marko Vukolić: “Consistency in Non-Transactional Distributed Storage Systems,” arXiv:1512.00168, 12 April 2016.

  6. Maurice P. Herlihy and Jeannette M. Wing: “Linearizability: A Correctness Condition for Concurrent Objects,” ACM Transactions on Programming Languages and Systems (TOPLAS), volume 12, number 3, pages 463–492, July 1990. doi:10.1145/78969.78972

  7. Leslie Lamport: “On interprocess communication,” Distributed Computing, volume 1, number 2, pages 77–101, June 1986. doi:10.1007/BF01786228

  8. David K. Gifford: “Information Storage in a Decentralized Computer System,” Xerox Palo Alto Research Centers, CSL-81-8, June 1981.

  9. Martin Kleppmann: “Please Stop Calling Databases CP or AP,” martin.kleppmann.com, May 11, 2015.

  10. Kyle Kingsbury: “Call Me Maybe: MongoDB Stale Reads,” aphyr.com, April 20, 2015.

  11. Kyle Kingsbury: “Computational Techniques in Knossos,” aphyr.com, May 17, 2014.

  12. Peter Bailis: “Linearizability Versus Serializability,” bailis.org, September 24, 2014.

  13. Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman: Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. ISBN: 978-0-201-10715-9, available online at research.microsoft.com.

  14. Mike Burrows: “The Chubby Lock Service for Loosely-Coupled Distributed Systems,” at 7th USENIX Symposium on Operating System Design and Implementation (OSDI), November 2006.

  15. Flavio P. Junqueira and Benjamin Reed: ZooKeeper: Distributed Process Coordination. O'Reilly Media, 2013. ISBN: 978-1-449-36130-3

  16. “etcd 2.0.12 Documentation,” CoreOS, Inc., 2015.

  17. “Apache Curator,” Apache Software Foundation, curator.apache.org, 2015.

  18. Morali Vallath: Oracle 10g RAC Grid, Services & Clustering. Elsevier Digital Press, 2006. ISBN: 978-1-555-58321-7

  19. Peter Bailis, Alan Fekete, Michael J Franklin, et al.: “Coordination-Avoiding Database Systems,” Proceedings of the VLDB Endowment, volume 8, number 3, pages 185–196, November 2014.

  20. Kyle Kingsbury: “Call Me Maybe: etcd and Consul,” aphyr.com, June 9, 2014.

  21. Flavio P. Junqueira, Benjamin C. Reed, and Marco Serafini: “Zab: High-Performance Broadcast for Primary-Backup Systems,” at 41st IEEE International Conference on Dependable Systems and Networks (DSN), June 2011. doi:10.1109/DSN.2011.5958223

  22. Diego Ongaro and John K. Ousterhout: “In Search of an Understandable Consensus Algorithm (Extended Version),” at USENIX Annual Technical Conference (ATC), June 2014.

  23. Hagit Attiya, Amotz Bar-Noy, and Danny Dolev: “Sharing Memory Robustly in Message-Passing Systems,” Journal of the ACM, volume 42, number 1, pages 124–142, January 1995. doi:10.1145/200836.200869

  24. Nancy Lynch and Alex Shvartsman: “Robust Emulation of Shared Memory Using Dynamic Quorum-Acknowledged Broadcasts,” at 27th Annual International Symposium on Fault-Tolerant Computing (FTCS), June 1997. doi:10.1109/FTCS.1997.614100

  25. Christian Cachin, Rachid Guerraoui, and Luís Rodrigues: Introduction to Reliable and Secure Distributed Programming, 2nd edition. Springer, 2011. ISBN: 978-3-642-15259-7, doi:10.1007/978-3-642-15260-3

  26. Sam Elliott, Mark Allen, and Martin Kleppmann: personal communication, thread on twitter.com, October 15, 2015.

  27. Niklas Ekström, Mikhail Panchenko, and Jonathan Ellis: “Possible Issue with Read Repair?,” email thread on cassandra-dev mailing list, October 2012.

  28. Maurice P. Herlihy: “Wait-Free Synchronization,” ACM Transactions on Programming Languages and Systems (TOPLAS), volume 13, number 1, pages 124–149, January 1991. doi:10.1145/114005.102808

  29. Armando Fox and Eric A. Brewer: “Harvest, Yield, and Scalable Tolerant Systems,” at 7th Workshop on Hot Topics in Operating Systems (HotOS), March 1999. doi:10.1109/HOTOS.1999.798396

  30. Seth Gilbert and Nancy Lynch: “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services,” ACM SIGACT News, volume 33, number 2, pages 51–59, June 2002. doi:10.1145/564585.564601

  31. Seth Gilbert and Nancy Lynch: “Perspectives on the CAP Theorem,” IEEE Computer Magazine, volume 45, number 2, pages 30–36, February 2012. doi:10.1109/MC.2011.389

  32. Eric A. Brewer: “CAP Twelve Years Later: How the 'Rules' Have Changed,” IEEE Computer Magazine, volume 45, number 2, pages 23–29, February 2012. doi:10.1109/MC.2012.37

  33. Susan B. Davidson, Hector Garcia-Molina, and Dale Skeen: “Consistency in Partitioned Networks,” ACM Computing Surveys, volume 17, number 3, pages 341–370, September 1985. doi:10.1145/5505.5508

  34. Paul R. Johnson and Robert H. Thomas: “RFC 677: The Maintenance of Duplicate Databases,” Network Working Group, January 27, 1975.

  35. Bruce G. Lindsay, Patricia Griffiths Selinger, C. Galtieri, et al.: “Notes on Distributed Databases,” IBM Research, Research Report RJ2571(33471), July 1979.

  36. Michael J. Fischer and Alan Michael: “Sacrificing Serializability to Attain High Availability of Data in an Unreliable Network,” at 1st ACM Symposium on Principles of Database Systems (PODS), March 1982. doi:10.1145/588111.588124

  37. Eric A. Brewer: “NoSQL: Past, Present, Future,” at QCon San Francisco, November 2012.

  38. Henry Robinson: “CAP Confusion: Problems with 'Partition Tolerance,'” blog.cloudera.com, April 26, 2010.

  39. Adrian Cockcroft: “Migrating to Microservices,” at QCon London, March 2014.

  40. Martin Kleppmann: “A Critique of the CAP Theorem,” arXiv:1509.05393, September 17, 2015.

  41. Nancy A. Lynch: “A Hundred Impossibility Proofs for Distributed Computing,” at 8th ACM Symposium on Principles of Distributed Computing (PODC), August 1989. doi:10.1145/72981.72982

  42. Hagit Attiya, Faith Ellen, and Adam Morrison: “Limitations of Highly-Available Eventually-Consistent Data Stores,” at ACM Symposium on Principles of Distributed Computing (PODC), July 2015. doi:10.1145/2767386.2767419

  43. Peter Sewell, Susmit Sarkar, Scott Owens, et al.: “x86-TSO: A Rigorous and Usable Programmer's Model for x86 Multiprocessors,” Communications of the ACM, volume 53, number 7, pages 89–97, July 2010. doi:10.1145/1785414.1785443

  44. Martin Thompson: “Memory Barriers/Fences,” mechanical-sympathy.blogspot.co.uk, July 24, 2011.

  45. Ulrich Drepper: “What Every Programmer Should Know About Memory,” akkadia.org, November 21, 2007.

  46. Daniel J. Abadi: “Consistency Tradeoffs in Modern Distributed Database System Design,” IEEE Computer Magazine, volume 45, number 2, pages 37–42, February 2012. doi:10.1109/MC.2012.33

  47. Hagit Attiya and Jennifer L. Welch: “Sequential Consistency Versus Linearizability,” ACM Transactions on Computer Systems (TOCS), volume 12, number 2, pages 91–122, May 1994. doi:10.1145/176575.176576

  48. Mustaque Ahamad, Gil Neiger, James E. Burns, et al.: “Causal Memory: Definitions, Implementation, and Programming,” Distributed Computing, volume 9, number 1, pages 37–49, March 1995. doi:10.1007/BF01784241

  49. Wyatt Lloyd, Michael J. Freedman, Michael Kaminsky, and David G. Andersen: “Stronger Semantics for Low-Latency Geo-Replicated Storage,” at 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI), April 2013.

  50. Marek Zawirski, Annette Bieniusa, Valter Balegas, et al.: “SwiftCloud: Fault-Tolerant Geo-Replication Integrated All the Way to the Client Machine,” INRIA Research Report 8347, August 2013.

  51. Peter Bailis, Ali Ghodsi, Joseph M Hellerstein, and Ion Stoica: “Bolt-on Causal Consistency,” at ACM International Conference on Management of Data (SIGMOD), June 2013.

  52. Philippe Ajoux, Nathan Bronson, Sanjeev Kumar, et al.: “Challenges to Adopting Stronger Consistency at Scale,” at 15th USENIX Workshop on Hot Topics in Operating Systems (HotOS), May 2015.

  53. Peter Bailis: “Causality Is Expensive (and What to Do About It),” bailis.org, February 5, 2014.

  54. Ricardo Gonçalves, Paulo Sérgio Almeida, Carlos Baquero, and Victor Fonte: “Concise Server-Wide Causality Management for Eventually Consistent Data Stores,” at 15th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS), June 2015. doi:10.1007/978-3-319-19129-4_6

  55. Rob Conery: “A Better ID Generator for PostgreSQL,” rob.conery.io, May 29, 2014.

  56. Leslie Lamport: “Time, Clocks, and the Ordering of Events in a Distributed System,” Communications of the ACM, volume 21, number 7, pages 558–565, July 1978. doi:10.1145/359545.359563

  57. Xavier Défago, André Schiper, and Péter Urbán: “Total Order Broadcast and Multicast Algorithms: Taxonomy and Survey,” ACM Computing Surveys, volume 36, number 4, pages 372–421, December 2004. doi:10.1145/1041680.1041682

  58. Hagit Attiya and Jennifer Welch: Distributed Computing: Fundamentals, Simulations and Advanced Topics, 2nd edition. John Wiley & Sons, 2004. ISBN: 978-0-471-45324-6, doi:10.1002/0471478210

  59. Mahesh Balakrishnan, Dahlia Malkhi, Vijayan Prabhakaran, et al.: “CORFU: A Shared Log Design for Flash Clusters,” at 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI), April 2012.

  60. Fred B. Schneider: “Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial,” ACM Computing Surveys, volume 22, number 4, pages 299–319, December 1990.

  61. Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, et al.: “Calvin: Fast Distributed Transactions for Partitioned Database Systems,” at ACM International Conference on Management of Data (SIGMOD), May 2012.

  62. Mahesh Balakrishnan, Dahlia Malkhi, Ted Wobber, et al.: “Tango: Distributed Data Structures over a Shared Log,” at 24th ACM Symposium on Operating Systems Principles (SOSP), November 2013. doi:10.1145/2517349.2522732

  63. Robbert van Renesse and Fred B. Schneider: “Chain Replication for Supporting High Throughput and Availability,” at 6th USENIX Symposium on Operating System Design and Implementation (OSDI), December 2004.

  64. Leslie Lamport: “How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs,” IEEE Transactions on Computers, volume 28, number 9, pages 690–691, September 1979. doi:10.1109/TC.1979.1675439

  65. Enis Söztutar, Devaraj Das, and Carter Shanklin: “Apache HBase High Availability at the Next Level,” hortonworks.com, January 22, 2015.

  66. Brian F Cooper, Raghu Ramakrishnan, Utkarsh Srivastava, et al.: “PNUTS: Yahoo!’s Hosted Data Serving Platform,” at 34th International Conference on Very Large Data Bases (VLDB), August 2008. doi:10.14778/1454159.1454167

  67. Tushar Deepak Chandra and Sam Toueg: “Unreliable Failure Detectors for Reliable Distributed Systems,” Journal of the ACM, volume 43, number 2, pages 225–267, March 1996. doi:10.1145/226643.226647

  68. Michael J. Fischer, Nancy Lynch, and Michael S. Paterson: “Impossibility of Distributed Consensus with One Faulty Process,” Journal of the ACM, volume 32, number 2, pages 374–382, April 1985. doi:10.1145/3149.214121

  69. Michael Ben-Or: “Another Advantage of Free Choice: Completely Asynchronous Agreement Protocols,” at 2nd ACM Symposium on Principles of Distributed Computing (PODC), August 1983. doi:10.1145/800221.806707

  70. Jim N. Gray and Leslie Lamport: “Consensus on Transaction Commit,” ACM Transactions on Database Systems (TODS), volume 31, number 1, pages 133–160, March 2006. doi:10.1145/1132863.1132867

  71. Rachid Guerraoui: “Revisiting the Relationship Between Non-Blocking Atomic Commitment and Consensus,” at 9th International Workshop on Distributed Algorithms (WDAG), September 1995. doi:10.1007/BFb0022140

  72. Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ramnatthan Alagappan, et al.: “All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications,” at 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), October 2014.

  73. Jim Gray: “The Transaction Concept: Virtues and Limitations,” at 7th International Conference on Very Large Data Bases (VLDB), September 1981.

  74. Hector Garcia-Molina and Kenneth Salem: “Sagas,” at ACM International Conference on Management of Data (SIGMOD), May 1987. doi:10.1145/38713.38742

  75. C. Mohan, Bruce G. Lindsay, and Ron Obermarck: “Transaction Management in the R* Distributed Database Management System,” ACM Transactions on Database Systems, volume 11, number 4, pages 378–396, December 1986. doi:10.1145/7239.7266

  76. “Distributed Transaction Processing: The XA Specification,” X/Open Company Ltd., Technical Standard XO/CAE/91/300, December 1991. ISBN: 978-1-872-63024-3

  77. Mike Spille: “XA Exposed, Part II,” jroller.com, April 3, 2004.

  78. Ivan Silva Neto and Francisco Reverbel: “Lessons Learned from Implementing WS-Coordination and WS-AtomicTransaction,” at 7th IEEE/ACIS International Conference on Computer and Information Science (ICIS), May 2008. doi:10.1109/ICIS.2008.75

  79. James E. Johnson, David E. Langworthy, Leslie Lamport, and Friedrich H. Vogt: “Formal Specification of a Web Services Protocol,” at 1st International Workshop on Web Services and Formal Methods (WS-FM), February 2004. doi:10.1016/j.entcs.2004.02.022

  80. Dale Skeen: “Nonblocking Commit Protocols,” at ACM International Conference on Management of Data (SIGMOD), April 1981. doi:10.1145/582318.582339

  81. Gregor Hohpe: “Your Coffee Shop Doesn’t Use Two-Phase Commit,” IEEE Software, volume 22, number 2, pages 64–66, March 2005. doi:10.1109/MS.2005.52

  82. Pat Helland: “Life Beyond Distributed Transactions: An Apostate’s Opinion,” at 3rd Biennial Conference on Innovative Data Systems Research (CIDR), January 2007.

  83. Jonathan Oliver: “My Beef with MSDTC and Two-Phase Commits,” blog.jonathanoliver.com, April 4, 2011.

  84. Oren Eini (Ahende Rahien): “The Fallacy of Distributed Transactions,” ayende.com, July 17, 2014.

  85. Clemens Vasters: “Transactions in Windows Azure (with Service Bus) – An Email Discussion,” vasters.com, July 30, 2012.

  86. “Understanding Transactionality in Azure,” NServiceBus Documentation, Particular Software, 2015.

  87. Randy Wigginton, Ryan Lowe, Marcos Albe, and Fernando Ipar: “Distributed Transactions in MySQL,” at MySQL Conference and Expo, April 2013.

  88. Mike Spille: “XA Exposed, Part I,” jroller.com, April 3, 2004.

  89. Ajmer Dhariwal: “Orphaned MSDTC Transactions (-2 spids),” eraofdata.com, December 12, 2008.

  90. Paul Randal: “Real World Story of DBCC PAGE Saving the Day,” sqlskills.com, June 19, 2013.

  91. “in-doubt xact resolution Server Configuration Option,” SQL Server 2016 documentation, Microsoft, Inc., 2016.

  92. Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer: “Consensus in the Presence of Partial Synchrony,” Journal of the ACM, volume 35, number 2, pages 288–323, April 1988. doi:10.1145/42282.42283

  93. Miguel Castro and Barbara H. Liskov: “Practical Byzantine Fault Tolerance and Proactive Recovery,” ACM Transactions on Computer Systems, volume 20, number 4, pages 396–461, November 2002. doi:10.1145/571637.571640

  94. Brian M. Oki and Barbara H. Liskov: “Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems,” at 7th ACM Symposium on Principles of Distributed Computing (PODC), August 1988. doi:10.1145/62546.62549

  95. Barbara H. Liskov and James Cowling: “Viewstamped Replication Revisited,” Massachusetts Institute of Technology, Tech Report MIT-CSAIL-TR-2012-021, July 2012.

  96. Leslie Lamport: “The Part-Time Parliament,” ACM Transactions on Computer Systems, volume 16, number 2, pages 133–169, May 1998. doi:10.1145/279227.279229

  97. Leslie Lamport: “Paxos Made Simple,” ACM SIGACT News, volume 32, number 4, pages 51–58, December 2001.

  98. Tushar Deepak Chandra, Robert Griesemer, and Joshua Redstone: “Paxos Made Live – An Engineering Perspective,” at 26th ACM Symposium on Principles of Distributed Computing (PODC), June 2007.

  99. Robbert van Renesse: “Paxos Made Moderately Complex,” cs.cornell.edu, March 2011.

  100. Diego Ongaro: “Consensus: Bridging Theory and Practice,” PhD Thesis, Stanford University, August 2014.

  101. Heidi Howard, Malte Schwarzkopf, Anil Madhavapeddy, and Jon Crowcroft: “Raft Refloated: Do We Have Consensus?,” ACM SIGOPS Operating Systems Review, volume 49, number 1, pages 12–21, January 2015. doi:10.1145/2723872.2723876

  102. André Medeiros: “ZooKeeper’s Atomic Broadcast Protocol: Theory and Practice,” Aalto University School of Science, March 20, 2012.

  103. Robbert van Renesse, Nicolas Schiper, and Fred B. Schneider: “Vive La Différence: Paxos vs. Viewstamped Replication vs. Zab,” IEEE Transactions on Dependable and Secure Computing, volume 12, number 4, pages 472–484, September 2014. doi:10.1109/TDSC.2014.2355848

  104. Will Portnoy: “Lessons Learned from Implementing Paxos,” blog.willportnoy.com, June 14, 2012.

  105. Heidi Howard, Dahlia Malkhi, and Alexander Spiegelman: “Flexible Paxos: Quorum Intersection Revisited,” arXiv:1608.06696, August 24, 2016.

  106. Heidi Howard and Jon Crowcroft: “Coracle: Evaluating Consensus at the Internet Edge,” at Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM), August 2015. doi:10.1145/2829988.2790010

  107. Kyle Kingsbury: “Call Me Maybe: Elasticsearch 1.5.0,” aphyr.com, April 27, 2015.

  108. Ivan Kelly: “BookKeeper Tutorial,” github.com, October 2014.

  109. Camille Fournier: “Consensus Systems for the Skeptical Architect,” at Craft Conference, Budapest, Hungary, April 2015.

  110. Kenneth P. Birman: “A History of the Virtual Synchrony Replication Model,” in Replication: Theory and Practice, Springer LNCS volume 5959, chapter 6, pages 91–120, 2010. ISBN: 978-3-642-11293-5, doi:10.1007/978-3-642-11294-2_6

上一章 目录 下一章
第八章：分布式系统的麻烦 设计数据密集型应用 第三部分：派生数据

Footnotes

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

  2. 一个寄存器中的读取可以返回旧值或新值，如果它们与写入同时发生，则称为常规寄存器[7,25] ↩

  3. 严格地说，ZooKeeper和etcd提供可线性化的写操作，但读取可能是陈旧的，因为默认情况下，它们可以由任何一个副本服务。您可以选择请求线性化读取：etcd调用这个法定读取[16]，而在ZooKeeper中，您需要在读取[15]之前调用sync()。请参阅第350页上的“使用总订单广播实现线性存储”。 ↩

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

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

  6. 正如第279页的“实践中的网络故障”中所讨论的，本书使用分区来指将大数据集精细分解成小数据集（分片;参见第6章）。相比之下，网络分区是特定类型的网络故障，我们通常不会将其与其他类型的故障分开考虑。但是，由于是CAP的P，所以在这种情况下我们不能避免混淆。 ↩

  7. 与因果关系不一致的整个订单很容易创建，但不是很有用。例如，您可以为每个操作生成随机UUID，并按照字典顺序比较UUID以定义操作的总顺序。这是一个有效的总顺序，但是随机的UUID并不告诉你哪个操作首先实际发生，或者操作是否是并发的。 ↩ ↩2

  8. “原子广播”这个术语是传统的，但是它是非常混乱的，因为它与原子的其他用法不一致：它与ACID事务中的原子性没有任何关系，只是与原子操作（在多线程编程的意义上 ）或原子寄存器（线性化存储）。 总的订单组播是另一个同义词。 ↩

  9. 从形式上讲，可线性读写寄存器是一个“更容易”的问题。 总订单广播等同于共识[67]，在异步崩溃停止模型[68]中没有确定性的解决方案，而可线性化的读写寄存器可以在同一系统模型中实现[23,24,25]。 然而，支持原子操作，如比较和设置，或者在寄存器中增加和获取，使得它相当于共识[28]。 因此，共识问题和可线性化的注册问题密切相关。 ↩

  10. 如果您不等待，但是在入队之后立即确认写入，则会得到类似于多核x86处理器的内存一致性模型[43]。 该模型既不是线性的也不是连续的。 ↩

  11. 这种共识的特殊形式被称为统一共识，相当于在具有不可靠故障检测器的异步系统中的常规共识[71]。学术文献通常指的是过程而不是节点，但我们在这里使用节点来与本书的其余部分保持一致。 ↩