mirror of
https://github.com/Vonng/ddia.git
synced 2024-12-06 15:20:12 +08:00
ch9 80%
This commit is contained in:
Vonng
parent
9dc5a3fe8f
commit
11e8c80a64
@ -106,7 +106,7 @@
|
||||
| 第六章：分区 | 初翻 | |
|
||||
| 第七章：事务 | 精翻 60% | Vonng |
|
||||
| 第八章：分布式系统中的问题 | 初翻 | |
|
||||
| 第九章：一致性与共识 | 初翻 65% | Vonng |
|
||||
| 第九章：一致性与共识 | 初翻 80% | Vonng |
|
||||
| 第三部分：前言 | 精翻 | |
|
||||
| 第十章：批处理 | 草翻 | |
|
||||
| 第十一章：流处理 | 草翻 | |
|
||||
|
||||
48
ch7.md
48
ch7.md
@ -82,7 +82,7 @@ ACID一致性的概念是，**对数据的一组特定陈述必须始终成立**
|
||||
|
||||
但是，一致性的这种概念取决于应用程序对不变量的观念，应用程序负责正确定义它的事务，并保持一致性。这并不是数据库可以保证的事情：如果你写入违反不变量的脏数据，数据库也无法阻止你。 （一些特定类型的不变量可以由数据库检查，例如外键约束或唯一约束，但是一般来说，是应用程序来定义什么样的数据是有效的，什么样是无效的。—— 数据库只管存储。）
|
||||
|
||||
原子性，隔离性和持久性是数据库的属性，而一致性（在ACID意义上）是应用程序的属性。应用程序可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。因此，字母C不属于ACID[^i]。
|
||||
原子性，隔离性和持久性是数据库的属性，而一致性（在ACID意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。因此，字母C不属于ACID[^i]。
|
||||
|
||||
[^i]: 乔·海勒斯坦（Joe Hellerstein）指出，在论Härder与Reuter的论文中，“ACID中的C”是被“扔进去凑缩写单词的”【7】，而且那时候大家都不怎么在乎一致性。
|
||||
|
||||
@ -90,7 +90,7 @@ ACID一致性的概念是，**对数据的一组特定陈述必须始终成立**
|
||||
|
||||
大多数数据库都会同时被多个客户端访问。如果它们各自读写数据库的不同部分，这是没有问题的，但是如果它们访问相同的数据库记录，则可能会遇到**并发**问题（**竞争条件（race conditions）**）。
|
||||
|
||||
[图7-1](img/fig7-1.png)是这类问题的一个简单例子。假设你有两个客户端同时在数据库中增长一个计数器。（假设数据库中没有自增操作）每个客户端需要读取计数器的当前值，加1，再回写新值。[图7-1](img/fig7-1.png)中，因为发生了两次增长，计数器应该从42增至44；但由于竞态条件，实际上只增至43。
|
||||
[图7-1](img/fig7-1.png)是这类问题的一个简单例子。假设你有两个客户端同时在数据库中增长一个计数器。（假设数据库中没有自增操作）每个客户端需要读取计数器的当前值，加 1 ，再回写新值。[图7-1](img/fig7-1.png) 中，因为发生了两次增长，计数器应该从42增至44；但由于竞态条件，实际上只增至 43 。
|
||||
|
||||
ACID意义上的隔离性意味着，**同时执行的事务是相互隔离的**：它们不能相互冒犯。传统的数据库教科书将隔离性形式化为**可序列化（Serializability）**，这意味着每个事务可以假装它是唯一在整个数据库上运行的事务。数据库确保当事务已经提交时，结果与它们按顺序运行（一个接一个）是一样的，尽管实际上它们可能是并发运行的【10】。
|
||||
|
||||
@ -131,7 +131,7 @@ ACID意义上的隔离性意味着，**同时执行的事务是相互隔离的**
|
||||
|
||||
***原子性***
|
||||
|
||||
如果在一系列写操作的中途发生错误，则应中止事务处理，并丢弃当前事务的所有写入。换句话说，数据库免去了用户对部分失败的担忧——通过提供“**宁为玉碎，不为瓦全**（all-or-nothing）”的保证。
|
||||
如果在一系列写操作的中途发生错误，则应中止事务处理，并丢弃当前事务的所有写入。换句话说，数据库免去了用户对部分失败的担忧——通过提供“**宁为玉碎，不为瓦全（all-or-nothing）**”的保证。
|
||||
|
||||
***隔离性***
|
||||
|
||||
@ -145,7 +145,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
但如果邮件太多，你可能会觉得这个查询太慢，并决定用单独的字段存储未读邮件的数量（一种反规范化）。现在每当一个新消息写入时，必须也增长未读计数器，每当一个消息被标记为已读时，也必须减少未读计数器。
|
||||
|
||||
在[图7-2](img/fig7-2.png)中，用户2遇到异常情况：邮件列表里显示有未读消息，但计数器显示为零未读消息，因为计数器增长还没有发生[^ii]。隔离性可以避免这个问题：通过确保用户2要么同时看到新邮件和增长后的计数器，要么都看不到。反正不会看到执行到一半的中间结果。
|
||||
在[图7-2](img/fig7-2.png)中，用户2 遇到异常情况：邮件列表里显示有未读消息，但计数器显示为零未读消息，因为计数器增长还没有发生[^ii]。隔离性可以避免这个问题：通过确保用户2 要么同时看到新邮件和增长后的计数器，要么都看不到。反正不会看到执行到一半的中间结果。
|
||||
|
||||
[^ii]: 可以说邮件应用中的错误计数器并不是什么特别重要的问题。但换种方式来看，你可以把未读计数器换成客户账户余额，把邮件收发看成支付交易。
|
||||
|
||||
@ -159,7 +159,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
**图7-3 原子性确保发生错误时，事务先前的任何写入都会被撤消，以避免状态不一致**
|
||||
|
||||
多对象事务需要某种方式来确定哪些读写操作属于同一个事务。在关系型数据库中，通常基于客户端与数据库服务器的TCP连接：在任何特定连接上，`BEGIN TRANSACTION`和`COMMIT`语句之间的所有内容，被认为是同一事务的一部分.[^iii]
|
||||
多对象事务需要某种方式来确定哪些读写操作属于同一个事务。在关系型数据库中，通常基于客户端与数据库服务器的TCP连接：在任何特定连接上，`BEGIN TRANSACTION` 和 `COMMIT` 语句之间的所有内容，被认为是同一事务的一部分.[^iii]
|
||||
|
||||
[^iii]: 这并不完美。如果TCP连接中断，则事务必须中止。如果中断发生在客户端请求提交之后，但在服务器确认提交发生之前，客户端并不知道事务是否已提交。为了解决这个问题，事务管理器可以通过一个唯一事务标识符来对操作进行分组，这个标识符并未绑定到特定TCP连接。后续再“[数据库端到端的争论](ch12.md#数据库端到端的争论)”一节将回到这个主题。
|
||||
|
||||
@ -167,30 +167,30 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
#### 单对象写入
|
||||
|
||||
当单个对象发生改变时，原子性和隔离也是适用的。例如，假设您正在向数据库写入一个20 KB的JSON文档：
|
||||
当单个对象发生改变时，原子性和隔离也是适用的。例如，假设您正在向数据库写入一个 20 KB的 JSON文档：
|
||||
|
||||
- 如果在发送第一个10 KB之后网络连接中断，数据库是否存储了不可解析的10 KB JSON片段？
|
||||
- 如果在发送第一个10 KB之后网络连接中断，数据库是否存储了不可解析的10KB JSON片段？
|
||||
- 如果在数据库正在覆盖磁盘上的前一个值的过程中电源发生故障，是否最终将新旧值拼接在一起？
|
||||
- 如果另一个客户端在写入过程中读取该文档，是否会看到部分更新的值？
|
||||
|
||||
这些问题非常让人头大，故存储引擎一个几乎普遍的目标是：对单节点上的单个对象（例如键值对）上提供原子性和隔离性。原子性可以通过使用日志来实现崩溃恢复（请参阅第82页的“[使B树可靠]()”），并且可以使用每个对象上的锁来实现隔离（每次只允许一个线程访问对象） ）。
|
||||
这些问题非常让人头大，故存储引擎一个几乎普遍的目标是：对单节点上的单个对象（例如键值对）上提供原子性和隔离性。原子性可以通过使用日志来实现崩溃恢复（参阅“[使B树可靠]()”），并且可以使用每个对象上的锁来实现隔离（每次只允许一个线程访问对象） ）。
|
||||
|
||||
一些数据库也提供更复杂的原子操作，例如自增操作，这样就不再需要像[图7-1](img/fig7-1.png)那样的读取-修改-写入序列了。同样流行的是**[比较和设置（CAS, compare-and-set）](#比较并设置（CAS）)**操作，当值没有并发被其他人修改过时，才允许执行写操作。
|
||||
一些数据库也提供更复杂的原子操作，例如自增操作，这样就不再需要像 [图7-1](img/fig7-1.png) 那样的读取-修改-写入序列了。同样流行的是**[比较和设置（CAS, compare-and-set）](#比较并设置（CAS）)**操作，当值没有并发被其他人修改过时，才允许执行写操作。
|
||||
|
||||
这些单对象操作很有用，因为它们可以防止在多个客户端尝试同时写入同一个对象时丢失更新（参阅“[防止丢失更新](#防止丢失更新)”）。但是，它们不是通常意义上的事务。CAS以及其他单一对象操作被称为“轻量级事务”，甚至出于营销目的被称为“ACID”【20,21,22】，但是这个术语是误导性的。事务通常被理解为，**将多个对象上的多个操作合并为一个执行单元的机制**。[^iv]
|
||||
这些单对象操作很有用，因为它们可以防止在多个客户端尝试同时写入同一个对象时丢失更新（参阅“[防止丢失更新](#防止丢失更新)”）。但它们不是通常意义上的事务。CAS以及其他单一对象操作被称为“轻量级事务”，甚至出于营销目的被称为“ACID”【20,21,22】，但是这个术语是误导性的。事务通常被理解为，**将多个对象上的多个操作合并为一个执行单元的机制**。[^iv]
|
||||
|
||||
[^iv]: 严格地说，**原子自增（atomic increment）**这个术语在多线程编程的意义上使用了原子这个词。 在ACID的情况下，它实际上应该被称为**孤立（isolated）**的或**可序列化（serializable）**的增量。 但这就太吹毛求疵了。
|
||||
|
||||
#### 多对象事务的需求
|
||||
|
||||
许多分布式数据存储已经放弃了多对象事务，因为多对象事务很难跨分区实现，而且在需要高可用性或高性能的情况下，它们可能会碍事。但说到底，在分布式数据库中实现事务，并没有什么根本性的障碍。[第9章](ch9.md)将讨论分布式事务的实现。
|
||||
许多分布式数据存储已经放弃了多对象事务，因为多对象事务很难跨分区实现，而且在需要高可用性或高性能的情况下，它们可能会碍事。但说到底，在分布式数据库中实现事务，并没有什么根本性的障碍。[第9章](ch9.md) 将讨论分布式事务的实现。
|
||||
|
||||
但是我们是否需要多对象事务？**是否有可能只用键值数据模型和单对象操作来实现任何应用程序？**
|
||||
|
||||
有一些场景中，单对象插入，更新和删除是足够的。但是许多其他场景需要协调写入几个不同的对象：
|
||||
|
||||
* 在关系数据模型中，一个表中的行通常具有对另一个表中的行的外键引用。 （类似的是，在一个图数据模型中，一个顶点有着到其他顶点的边）。多对象事务使你确信这些引用始终有效：当插入几个相互引用的记录时，外键必须是正确的，最新的，不然数据就没有意义。
|
||||
* 在文档数据模型中，需要一起更新的字段通常在同一个文档中，这被视为单个对象——更新单个文档时不需要多对象事务。但是，缺乏连接功能的文档数据库会鼓励非规范化（参阅“[关系型数据库与文档数据库在今日的对比](ch2.md#关系型数据库与文档数据库在今日的对比)”）。当需要更新非规范化的信息时，如[图7-2](img/fig7-2.png)所示，需要一次更新多个文档。事务在这种情况下非常有用，可以防止非规范化的数据不同步。
|
||||
* 在文档数据模型中，需要一起更新的字段通常在同一个文档中，这被视为单个对象——更新单个文档时不需要多对象事务。但是，缺乏连接功能的文档数据库会鼓励非规范化（参阅“[关系型数据库与文档数据库在今日的对比](ch2.md#关系型数据库与文档数据库在今日的对比)”）。当需要更新非规范化的信息时，如 [图7-2](img/fig7-2.png) 所示，需要一次更新多个文档。事务在这种情况下非常有用，可以防止非规范化的数据不同步。
|
||||
* 在具有二级索引的数据库中（除了纯粹的键值存储以外几乎都有），每次更改值时都需要更新索引。从事务角度来看，这些索引是不同的数据库对象：例如，如果没有事务隔离性，记录可能出现在一个索引中，但没有出现在另一个索引中，因为第二个索引的更新还没有发生。
|
||||
|
||||
这些应用仍然可以在没有事务的情况下实现。然而，**没有原子性，错误处理就要复杂得多，缺乏隔离性，就会导致并发问题**。我们将在“[弱隔离级别](#弱隔离级别)”中讨论这些问题，并在[第12章]()中探讨其他方法。
|
||||
@ -248,7 +248,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
设想一个事务已经将一些数据写入数据库，但事务还没有提交或中止。另一个事务可以看到未提交的数据吗？如果是的话，那就叫做**脏读（dirty reads）**【2】。
|
||||
|
||||
在**读已提交**隔离级别运行的事务必须防止脏读。这意味着事务的任何写入操作只有在该事务提交时才能被其他人看到（然后所有的写入操作都会立即变得可见）。如[图7-4]()所示，用户1设置了`x = 3`，但用户2的`get x`仍旧返回旧值2，而用户1尚未提交。
|
||||
在**读已提交**隔离级别运行的事务必须防止脏读。这意味着事务的任何写入操作只有在该事务提交时才能被其他人看到（然后所有的写入操作都会立即变得可见）。如[图7-4]()所示，用户1 设置了`x = 3`，但用户2 的 `get x `仍旧返回旧值2 ，而用户1 尚未提交。
|
||||
|
||||
|
||||
|
||||
@ -267,7 +267,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
通过防止脏写，这个隔离级别避免了一些并发问题：
|
||||
|
||||
- 如果事务更新多个对象，脏写会导致不好的结果。例如，考虑[图7-5](img/fig7-5.png)，[图7-5](img/fig7-5.png)以一个二手车销售网站为例，Alice和Bob两个人同时试图购买同一辆车。购买汽车需要两次数据库写入：网站上的商品列表需要更新，以反映买家的购买，销售发票需要发送给买家。在[图7-5](img/fig7-5.png)的情况下，销售是属于Bob的（因为他成功更新了商品列表），但发票却寄送给了爱丽丝（因为她成功更新了发票表）。读已提交会阻止这样这样的事故。
|
||||
- 如果事务更新多个对象，脏写会导致不好的结果。例如，考虑 [图7-5](img/fig7-5.png)，[图7-5](img/fig7-5.png) 以一个二手车销售网站为例，Alice和Bob两个人同时试图购买同一辆车。购买汽车需要两次数据库写入：网站上的商品列表需要更新，以反映买家的购买，销售发票需要发送给买家。在[图7-5](img/fig7-5.png)的情况下，销售是属于Bob的（因为他成功更新了商品列表），但发票却寄送给了爱丽丝（因为她成功更新了发票表）。读已提交会阻止这样这样的事故。
|
||||
- 但是，提交读取并不能防止[图7-1]()中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在“[防止更新丢失](#防止丢失更新)”中将讨论如何使这种计数器增量安全。
|
||||
|
||||
|
||||
@ -338,7 +338,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
表中的每一行都有一个`created_by`字段，其中包含将该行插入到表中的的事务ID。此外，每行都有一个`deleted_by`字段，最初是空的。如果某个事务删除了一行，那么该行实际上并未从数据库中删除，而是通过将`deleted_by`字段设置为请求删除的事务的ID来标记为删除。在稍后的时间，当确定没有事务可以再访问已删除的数据时，数据库中的垃圾收集过程会将所有带有删除标记的行移除，并释放其空间。[^译注ii]
|
||||
|
||||
[^译注ii]: 在PostgreSQL中，`created_by`实际名称为`xmin`，`deleted_by`实际名称为`xmax`
|
||||
[^译注ii]: 在PostgreSQL中，`created_by` 实际名称为`xmin`，`deleted_by` 实际名称为`xmax`
|
||||
|
||||
`UPDATE`操作在内部翻译为`DELETE`和`INSERT`。例如，在[图7-7]()中，事务13从账户2中扣除100美元，将余额从500美元改为400美元。实际上包含两条账户2的记录：余额为\$500的行被标记为**被事务13删除**，余额为\$400的行**由事务13创建**。
|
||||
|
||||
@ -626,7 +626,7 @@ COMMIT;
|
||||
|
||||
在这种交互式的事务方式中，应用程序和数据库之间的网络通信耗费了大量的时间。如果不允许在数据库中进行并发处理，且一次只处理一个事务，则吞吐量将会非常糟糕，因为数据库大部分的时间都花费在等待应用程序发出当前事务的下一个查询。在这种数据库中，为了获得合理的性能，需要同时处理多个事务。
|
||||
|
||||
出于这个原因，具有单线程串行事务处理的系统不允许交互式的多语句事务。取而代之，应用程序必须提前将整个事务代码作为存储过程提交给数据库。这些方法之间的差异如[图7-9](img/fig7-9.png)所示。如果事务所需的所有数据都在内存中，则存储过程可以非常快地执行，而不用等待任何网络或磁盘I/O。
|
||||
出于这个原因，具有单线程串行事务处理的系统不允许交互式的多语句事务。取而代之，应用程序必须提前将整个事务代码作为存储过程提交给数据库。这些方法之间的差异如[图7-9](img/fig7-9.png) 所示。如果事务所需的所有数据都在内存中，则存储过程可以非常快地执行，而不用等待任何网络或磁盘I/O。
|
||||
|
||||
|
||||
|
||||
@ -673,7 +673,7 @@ VoltDB还使用存储过程进行复制：但不是将事务的写入结果从
|
||||
|
||||
大约30年来，在数据库中只有一种广泛使用的序列化算法：**两阶段锁定（2PL，two-phase locking）**[^xi]
|
||||
|
||||
[^xi]: 有时也称为严格两阶段锁定（SS2PL, strict two-phas locking），以便和其他2PL变体区分。
|
||||
[^xi]: 有时也称为**严格两阶段锁定（SS2PL, strict two-phas locking）**，以便和其他2PL变体区分。
|
||||
|
||||
> #### 2PL不是2PC
|
||||
>
|
||||
@ -692,8 +692,6 @@ VoltDB还使用存储过程进行复制：但不是将事务的写入结果从
|
||||
|
||||
2PL用于MySQL（InnoDB）和SQL Server中的可序列化隔离级别，以及DB2中的可重复读隔离级别【23,36】。
|
||||
|
||||
[^xi]: 有时被称为强有力的严格的两阶段锁定（SS2PL），以区别于2PL的其他变种。
|
||||
|
||||
读与写的阻塞是通过为数据库中每个对象添加锁来实现的。锁可以处于**共享模式（shared mode）**或**独占模式（exclusive mode）**。锁使用如下：
|
||||
|
||||
- 若事务要读取对象，则须先以共享模式获取锁。允许多个事务同时持有共享锁。但如果另一个事务已经在对象上持有排它锁，则这些事务必须等待。
|
||||
@ -719,7 +717,7 @@ VoltDB还使用存储过程进行复制：但不是将事务的写入结果从
|
||||
|
||||
在前面关于锁的描述中，我们掩盖了一个微妙而重要的细节。在“[导致写入偏差的幻读](#导致写入偏差的幻读)”中，我们讨论了**幻读（phantoms）**的问题。即一个事务改变另一个事务的搜索查询的结果。具有可序列化隔离级别的数据库必须防止**幻读**。
|
||||
|
||||
在会议室预订的例子中，这意味着如果一个事务在某个时间窗口内搜索了一个房间的现有预订（见例7-2），则另一个事务不能同时插入或更新同一时间窗口与同一房间的另一个预订 （可以同时插入其他房间的预订，或在不影响另一个预定的条件下预定同一房间的其他时间段）。
|
||||
在会议室预订的例子中，这意味着如果一个事务在某个时间窗口内搜索了一个房间的现有预订（见[例7-2]()），则另一个事务不能同时插入或更新同一时间窗口与同一房间的另一个预订 （可以同时插入其他房间的预订，或在不影响另一个预定的条件下预定同一房间的其他时间段）。
|
||||
|
||||
如何实现这一点？从概念上讲，我们需要一个**谓词锁（predicate lock）**【3】。它类似于前面描述的共享/排它锁，但不属于特定的对象（例如，表中的一行），它属于所有符合某些搜索条件的对象，如：
|
||||
|
||||
@ -732,7 +730,7 @@ WHERE room_id = 123 AND
|
||||
|
||||
谓词锁限制访问，如下所示：
|
||||
|
||||
- 如果事务A想要读取匹配某些条件的对象，就像在这个`SELECT`查询中那样，它必须获取查询条件上的**共享谓词锁（shared-mode predicate lock）**。如果另一个事务B持有任何满足这一查询条件对象的排它锁，那么A必须等到B释放它的锁之后才允许进行查询。
|
||||
- 如果事务A想要读取匹配某些条件的对象，就像在这个 `SELECT` 查询中那样，它必须获取查询条件上的**共享谓词锁（shared-mode predicate lock）**。如果另一个事务B持有任何满足这一查询条件对象的排它锁，那么A必须等到B释放它的锁之后才允许进行查询。
|
||||
- 如果事务A想要插入，更新或删除任何对象，则必须首先检查旧值或新值是否与任何现有的谓词锁匹配。如果事务B持有匹配的谓词锁，那么A必须等到B已经提交或中止后才能继续。
|
||||
|
||||
这里的关键思想是，谓词锁甚至适用于数据库中尚不存在，但将来可能会添加的对象（幻象）。如果两阶段锁定包含谓词锁，则数据库将阻止所有形式的写入偏差和其他竞争条件，因此其隔离实现了可串行化。
|
||||
@ -743,7 +741,7 @@ WHERE room_id = 123 AND
|
||||
|
||||
通过使谓词匹配到一个更大的集合来简化谓词锁是安全的。例如，如果你有在中午和下午1点之间预订123号房间的谓词锁，则锁定123号房间的所有时间段，或者锁定12:00~13:00时间段的所有房间（不只是123号房间）是一个安全的近似，因为任何满足原始谓词的写入也一定会满足这种更松散的近似。
|
||||
|
||||
在房间预订数据库中，您可能会在`room_id`列上有一个索引，并且/或者在`start_time`和`end_time`上有索引（否则前面的查询在大型数据库上的速度会非常慢）：
|
||||
在房间预订数据库中，您可能会在`room_id`列上有一个索引，并且/或者在`start_time` 和 `end_time`上有索引（否则前面的查询在大型数据库上的速度会非常慢）：
|
||||
|
||||
- 假设您的索引位于`room_id`上，并且数据库使用此索引查找123号房间的现有预订。现在数据库可以简单地将共享锁附加到这个索引项上，指示事务已搜索123号房间用于预订。
|
||||
- 或者，如果数据库使用基于时间的索引来查找现有预订，那么它可以将共享锁附加到该索引中的一系列值，指示事务已经将12:00~13:00时间段标记为用于预定。
|
||||
@ -817,7 +815,7 @@ WHERE room_id = 123 AND
|
||||
|
||||
当事务写入数据库时，它必须在索引中查找最近曾读取受影响数据的其他事务。这个过程类似于在受影响的键范围上获取写锁，但锁并不会阻塞事务到其他事务完成，而是像一个引线一样只是简单通知其他事务：你们读过的数据可能不是最新的啦。
|
||||
|
||||
在[图7-11]()中，事务43通知事务42其先前读已过时，反之亦然。事务42首先提交并成功，尽管事务43的写影响了42，但因为事务43尚未提交，所以写入尚未生效。然而当事务43想要提交时，来自事务42的冲突写入已经被提交，所以43必须中止。
|
||||
在[图7-11]()中，事务43 通知事务42 其先前读已过时，反之亦然。事务42首先提交并成功，尽管事务43 的写影响了42 ，但因为事务43 尚未提交，所以写入尚未生效。然而当事务43 想要提交时，来自事务42 的冲突写入已经被提交，所以事务43 必须中止。
|
||||
|
||||
#### 可序列化的快照隔离的性能
|
||||
|
||||
@ -829,7 +827,7 @@ WHERE room_id = 123 AND
|
||||
|
||||
与串行执行相比，可序列化快照隔离并不局限于单个CPU核的吞吐量：FoundationDB将检测到的序列化冲突分布在多台机器上，允许扩展到很高的吞吐量。即使数据可能跨多台机器进行分区，事务也可以在保证可序列化隔离等级的同时读写多个分区中的数据【54】。
|
||||
|
||||
中止率显着影响SSI的整体表现。例如，长时间读取和写入数据的事务很可能会发生冲突并中止，因此SSI要求同时读写的事务尽量短（长时间运行的只读事务可能没问题）。对于慢事务，SSI可能比两阶段锁定或串行执行更不敏感。
|
||||
中止率显着影响SSI的整体表现。例如，长时间读取和写入数据的事务很可能会发生冲突并中止，因此SSI要求同时读写的事务尽量短（只读长事务可能没问题）。对于慢事务，SSI可能比两阶段锁定或串行执行更不敏感。
|
||||
|
||||
|
||||
|
||||
@ -871,7 +869,7 @@ WHERE room_id = 123 AND
|
||||
|
||||
***字面意义上的串行执行***
|
||||
|
||||
如果每个事务的执行速度非常快，并且事务吞吐量足够低，足以在单个CPU内核上处理，这是一个简单而有效的选择。
|
||||
如果每个事务的执行速度非常快，并且事务吞吐量足够低，足以在单个CPU核上处理，这是一个简单而有效的选择。
|
||||
|
||||
***两阶段锁定***
|
||||
|
||||
|
||||
2
ch8.md
2
ch8.md
@ -588,7 +588,7 @@ Web应用程序确实需要预期受终端用户控制的客户端（如Web浏
|
||||
|
||||
***单调序列***
|
||||
|
||||
如果请求$x$返回了令牌$t_x$，并且请求$y$返回了令牌$t_y$，并且$x$在$y$开始之前已经完成，那么$t_x <t_y$。
|
||||
如果请求 $x$ 返回了令牌 $t_x$，并且请求$y$返回了令牌$t_y$，并且 $x$ 在 $y$ 开始之前已经完成，那么$t_x <t_y$。
|
||||
|
||||
***可用性***
|
||||
|
||||
|
||||
194
ch9.md
194
ch9.md
@ -11,7 +11,7 @@
|
||||
|
||||
[TOC]
|
||||
|
||||
正如[第8章](ch8.md)所讨论的，分布式系统中的许多事情可能会出错。处理这种故障的最简单方法是简单地让整个服务失效，并向用户显示错误消息。如果无法接受这个解决方案，我们就需要找到容错的方法——即使某些内部组件出现故障，服务也能正常运行。
|
||||
正如[第8章](ch8.md)所讨论的，分布式系统中的许多事情可能会出错。处理这种故障的最简单方法是简单地让整个服务失效，并向用户显示错误消息。如果无法接受这个解决方案，我们就需要找到容错的方法—— 即使某些内部组件出现故障，服务也能正常运行。
|
||||
|
||||
在本章中，我们将讨论构建容错分布式系统的算法和协议的一些例子。我们将假设[第8章](ch8.md)的所有问题都可能发生：网络中的数据包可能会丢失，重新排序，重复递送或任意延迟；时钟只是尽其所能地近似；且节点可以暂停（例如，由于垃圾收集）或随时崩溃。
|
||||
|
||||
@ -19,13 +19,13 @@
|
||||
|
||||
现在我们将继续沿着同样的路线前进，寻求可以让应用忽略分布式系统部分问题的抽象概念。例如，分布式系统最重要的抽象之一就是**共识（consensus）**：**就是让所有的节点对某件事达成一致**。正如我们在本章中将会看到的那样，尽管存在网络故障和流程故障，可靠地达成共识是一个令人惊讶的棘手问题。
|
||||
|
||||
一旦达成共识，应用程序可以将其用于各种目的。例如，假设你有一个单主复制的数据库。如果主库挂点，并且需要故障转移到另一个节点，剩余的数据库节点可以使用共识来选举新的领导者。正如在“[处理节点宕机](ch5.md#处理节点宕机)”中所讨论的那样，重要的是只有一个领导者，并且所有的节点都认同其为领导。如果两个节点都认为自己是领导者，这种情况被称为**脑裂（split brain）**，且经常导致数据丢失。正确实现共识有助于避免这种问题。
|
||||
一旦达成共识，应用程序可以将其用于各种目的。例如，假设你有一个单主复制的数据库。如果主库挂点，并且需要故障转移到另一个节点，剩余的数据库节点可以使用共识来选举新的领导者。正如在“[处理节点宕机](ch5.md#处理节点宕机)”中所讨论的那样，重要的是只有一个领导者，且所有的节点都认同其领导。如果两个节点都认为自己是领导者，这种情况被称为**脑裂（split brain）**，且经常导致数据丢失。正确实现共识有助于避免这种问题。
|
||||
|
||||
在本章后面的“[分布式事务和共识](#分布式事务和共识)”中，我们将研究解决共识和相关问题的算法。但首先，我们首先需要探索可以在分布式系统中提供的保证和抽象的范围。
|
||||
|
||||
我们需要了解可以做什么和不可以做什么的范围：在某些情况下，系统可以容忍故障并继续工作；在其他情况下，这是不可能的。我们将深入研究什么可能而什么不可能的限制，既通过理论证明，也通过实际实现。我们将在本章中概述这些基本限制。
|
||||
|
||||
分布式系统领域的研究人员几十年来一直在研究这些主题，所以有很多资料——我们只能介绍一些皮毛。在本书中，我们没有空间去详细介绍形式模型和证明的细节，所以我们将坚持非正式的直觉。如果你有兴趣，参考文献可以提供更多的深度。
|
||||
分布式系统领域的研究人员几十年来一直在研究这些主题，所以有很多资料—— 我们只能介绍一些皮毛。在本书中，我们没有空间去详细介绍形式模型和证明的细节，所以我们将坚持非正式的直觉。如果你有兴趣，参考文献可以提供更多的深度。
|
||||
|
||||
|
||||
|
||||
@ -49,7 +49,7 @@
|
||||
|
||||
* 首先看一下常用的**最强一致性模型**之一，**线性一致性（linearizability）**，并考察其优缺点。
|
||||
* 然后我们将检查分布式系统中[**事件顺序**](#顺序保证)的问题，特别是因果关系和全局顺序的问题。
|
||||
* 在第三部分（“[分布式事务和共识](#分布式事务和共识)”）中将探讨如何自动提交分布式事务，这将最终引导我们解决共识问题。
|
||||
* 在第三部分（“[分布式事务和共识](#分布式事务和共识)”）中将探讨如何原子地提交分布式事务，这将最终引领我们走向共识问题的解决方案。
|
||||
|
||||
|
||||
|
||||
@ -58,15 +58,15 @@
|
||||
|
||||
在**最终一致**的数据库，如果你在同一时刻问两个不同副本相同的问题，可能会得到两个不同的答案。这很让人困惑。如果数据库可以提供只有一个副本的假象（即，只有一个数据副本），那么事情就简单太多了。那么每个客户端都会有相同的数据视图，且不必担心复制滞后了。
|
||||
|
||||
这就是**线性一致性（linearizability）**背后的想法【6】（也称为**原子一致性（atomic consistency）**【7】，**强一致性（strong consistency）**，**立即一致性（immediate consistency）**或**外部一致性（external consistency ）**【8】）。线性一致性的精确定义相当微妙，我们将在本节的剩余部分探讨它。但是基本的想法是让一个系统看起来好像只有一个数据副本，而且所有的操作都是原子的。有了这个保证，即使实际中可能有多个副本，应用也不需要担心它们。
|
||||
这就是**线性一致性（linearizability）**背后的想法【6】（也称为**原子一致性（atomic consistency）**【7】，**强一致性（strong consistency）**，**立即一致性（immediate consistency）**或**外部一致性（external consistency ）**【8】）。线性一致性的精确定义相当微妙，我们将在本节的剩余部分探讨它。但是基本的想法是让一个系统看起来好像只有一个数据副本，而且所有的操作都是原子性的。有了这个保证，即使实际中可能有多个副本，应用也不需要担心它们。
|
||||
|
||||
在一个线性一致性系统中，只要一个客户端成功完成写操作，所有客户端从数据库中读取数据必须能够看到刚刚写入的值。维护数据的单个副本的错觉是指，系统能保障读到的值是最近的，最新的，不是来自一个陈旧的缓存或副本。换句话说，线性一致性是一个**新鲜度保证（recency guarantee）**。为了阐明这个想法，我们来看看一个非线性一致系统的例子。
|
||||
在一个线性一致的系统中，只要一个客户端成功完成写操作，所有客户端从数据库中读取数据必须能够看到刚刚写入的值。维护数据的单个副本的错觉是指，系统能保障读到的值是最近的，最新的，而不是来自陈旧的缓存或副本。换句话说，线性一致性是一个**新鲜度保证（recency guarantee）**。为了阐明这个想法，我们来看看一个非线性一致系统的例子。
|
||||
|
||||
|
||||
|
||||
**图9-1 这个系统是非线性一致的，导致了球迷的困惑**
|
||||
|
||||
[图9-1](img/fig9-1.png)展示了一个非线性一致性的，关于体育网站的例子【9】。Alice和Bob正坐在同一个房间里，都盯着各自的手机，关注着2014年FIFA世界杯决赛的结果。在最后得分公布后，Alice刷新页面，看到宣布了获胜者，并兴奋地告诉Bob。Bob难以置信地刷新了自己的手机，但他的请求路由到了一个落后的数据库副本上，手机显示比赛仍在进行。
|
||||
[图9-1 ](img/fig9-1.png)展示了一个关于体育网站的非线性一致例子【9】。Alice和Bob正坐在同一个房间里，都盯着各自的手机，关注着2014年FIFA世界杯决赛的结果。在最后得分公布后，Alice刷新页面，看到宣布了获胜者，并兴奋地告诉Bob。Bob难以置信地刷新了自己的手机，但他的请求路由到了一个落后的数据库副本上，手机显示比赛仍在进行。
|
||||
|
||||
如果Alice和Bob在同一时间刷新并获得了两个不同的查询结果，也许就没有那么令人惊讶了。因为他们不知道服务器处理他们请求的精确时刻。然而Bob是在听到Alice惊呼最后得分**之后**，点击了刷新按钮（启动了他的查询），因此他希望查询结果至少与爱丽丝一样新鲜。但他的查询返回了陈旧结果，这一事实违背了线性一致性的要求。
|
||||
|
||||
@ -74,7 +74,7 @@
|
||||
|
||||
线性一致性背后的基本思想很简单：使系统看起来好像只有一个数据副本。然而确切来讲，实际上有更多要操心的地方。为了更好地理解线性一致性，让我们再看几个例子。
|
||||
|
||||
[图9-2](img/fig9-2.png)显示了三个客户端在线性一致数据库中同时读写相同的键`x`。在分布式系统文献中，`x`被称为**寄存器（register）**，例如它可以是键值存储中的一个**键**，关系数据库中的一**行**或文档数据库中的一个**文档**。
|
||||
[图9-2](img/fig9-2.png) 显示了三个客户端在线性一致数据库中同时读写相同的键`x`。在分布式系统文献中，`x`被称为**寄存器（register）**，例如，它可以是键值存储中的一个**键**，关系数据库中的一**行**，或文档数据库中的一个**文档**。
|
||||
|
||||
|
||||
|
||||
@ -86,16 +86,16 @@
|
||||
|
||||
在这个例子中，寄存器有两种类型的操作：
|
||||
|
||||
* $ read(x)⇒v$表示客户端请求读取寄存器`x`的值，数据库返回值`v`。
|
||||
* $ read(x)⇒v$表示客户端请求读取寄存器 `x` 的值，数据库返回值 `v`。
|
||||
|
||||
|
||||
* $write(x,v)⇒r$表示客户端请求将寄存器`x`设置为值`v`，数据库返回响应`r`（可能正确，可能错误）。
|
||||
* $write(x,v)⇒r$ 表示客户端请求将寄存器 `x` 设置为值 `v` ，数据库返回响应 `r` （可能正确，可能错误）。
|
||||
|
||||
在[图9-2](img/fig9-2.png)中，x的值最初为`0`，客户端C执行写请求将其设置为`1`。发生这种情况时，客户端A和B反复轮询数据库以读取最新值。 A和B的请求可能会收到怎样的响应？
|
||||
在[图9-2](img/fig9-2.png) 中，`x` 的值最初为 `0`，客户端C 执行写请求将其设置为 `1`。发生这种情况时，客户端A和B反复轮询数据库以读取最新值。 A和B的请求可能会收到怎样的响应？
|
||||
|
||||
* 客户端A的第一个读操作，完成于写操作开始之前，因此必须返回旧值`0`。
|
||||
* 客户端A的最后一个读操作，开始于写操作完成之后。如果数据库是线性一致性的，它必然返回新值`1`：因为读操作和写操作一定是在其各自的起止区间内的某个时刻被处理。如果在写入结束后开始读取，则必须在写入之后处理读取，因此它必须看到写入的新值。
|
||||
* 与写操作在时间上重叠的任何读操作，可能会返回0或1，因为我们不知道读取时，写操作是否已经生效。这些操作是**并发（concurrent）**的。
|
||||
* 客户端A的第一个读操作，完成于写操作开始之前，因此必须返回旧值 `0`。
|
||||
* 客户端A的最后一个读操作，开始于写操作完成之后。如果数据库是线性一致性的，它必然返回新值 `1`：因为读操作和写操作一定是在其各自的起止区间内的某个时刻被处理。如果在写入结束后开始读取，则必须在写入之后处理读取，因此它必须看到写入的新值。
|
||||
* 与写操作在时间上重叠的任何读操作，可能会返回 `0` 或 `1` ，因为我们不知道读取时，写操作是否已经生效。这些操作是**并发（concurrent）**的。
|
||||
|
||||
但是，这还不足以完全描述线性一致性：如果与写入同时发生的读取可以返回旧值或新值，那么读者可能会在写入期间看到数值在旧值和新值之间来回翻转。这不是我们所期望的仿真“单一数据副本”的系统。[^ii]
|
||||
|
||||
@ -106,15 +106,15 @@
|
||||
|
||||
**图9-3 任何一个读取返回新值后，所有后续读取（在相同或其他客户端上）也必须返回新值。**
|
||||
|
||||
在一个线性一致的系统中，我们可以想象，在`x`的值自动翻转从`0`到`1`的时候（在写操作的开始和结束之间）必定有一个时间点。因此，如果一个客户端的读取返回新的值`1`，即使写操作尚未完成，所有后续读取也必须返回新值。
|
||||
在一个线性一致的系统中，我们可以想象，在 `x` 的值从`0` 自动翻转到 `1` 的时候（在写操作的开始和结束之间）必定有一个时间点。因此，如果一个客户端的读取返回新的值 `1`，即使写操作尚未完成，所有后续读取也必须返回新值。
|
||||
|
||||
[图9-3](img/fig9-3.png)中的箭头说明了这个时序依赖关系。客户端A是第一个读取新的值`1`的位置。在A的读取返回之后，B开始新的读取。由于B的读取严格在发生于A的读取之后，因此即使C的写入仍在进行中，也必须返回`1`。 （与[图9-1](img/fig9-1.png)中的Alice和Bob的情况相同：在Alice读取新值之后，Bob也希望读取新的值。）
|
||||
[图9-3](img/fig9-3.png)中的箭头说明了这个时序依赖关系。客户端A 是第一个读取新的值 `1` 的位置。在A 的读取返回之后，B开始新的读取。由于B的读取严格在发生于A的读取之后，因此即使C的写入仍在进行中，也必须返回 `1`。 （与[图9-1](img/fig9-1.png)中的Alice和Bob的情况相同：在Alice读取新值之后，Bob也希望读取新的值。）
|
||||
|
||||
我们可以进一步细化这个时序图，展示每个操作是如何在特定时刻原子性生效的。[图9-4](img/fig9-4.png)显示了一个更复杂的例子【10】。
|
||||
|
||||
在[图9-4]()中，除了读写之外，还增加了第三种类型的操作：
|
||||
|
||||
* $cas(x, v_{old}, v_{new})$⇒r表示客户端请求进行原子性的[**比较与设置**](ch7.md#比较并设置（CAS）)操作。如果寄存器$x$的当前值等于$v_{old}$，则应该原子地设置为$v_{new}$。如果$x≠vold$，则操作应该保持寄存器不变并返回一个错误。 $r$是数据库的响应（正确或错误）。
|
||||
* $cas(x, v_{old}, v_{new})⇒r$ 表示客户端请求进行原子性的[**比较与设置**](ch7.md#比较并设置（CAS）)操作。如果寄存器 $x$ 的当前值等于 $v_{old}$ ，则应该原子地设置为 $v_{new}$ 。如果 $x≠vold$ ，则操作应该保持寄存器不变并返回一个错误。 $r$ 是数据库的响应（正确或错误）。
|
||||
|
||||
[图9-4]()中的每个操作都在我们认为执行操作的时候用竖线标出（在每个操作的条柱之内）。这些标记按顺序连在一起，其结果必须是一个有效的寄存器读写序列（**每次读取都必须返回最近一次写入设置的值**）。
|
||||
|
||||
@ -126,13 +126,13 @@
|
||||
|
||||
[图9-4]()中有一些有趣的细节需要指出：
|
||||
|
||||
* 第一个客户端B发送一个读取`x`的请求，然后客户端D发送一个请求将`x`设置为`0`，然后客户端A发送请求将`x`设置为`1`。尽管如此，返回到B的读取值为`1`（由A写入的值）。这是可以的：这意味着数据库首先处理D的写入，然后是A的写入，最后是B的读取。虽然这不是请求发送的顺序，但这是一个可以接受的顺序，因为这三个请求是并发的。也许B的读请求在网络上略有延迟，所以它在两次写入之后才到达数据库。
|
||||
* 第一个客户端B发送一个读取 `x` 的请求，然后客户端D发送一个请求将 `x` 设置为 `0`，然后客户端A发送请求将 `x` 设置为 `1`。尽管如此，返回到B的读取值为 `1`（由A写入的值）。这是可以的：这意味着数据库首先处理D的写入，然后是A的写入，最后是B的读取。虽然这不是请求发送的顺序，但这是一个可以接受的顺序，因为这三个请求是并发的。也许B的读请求在网络上略有延迟，所以它在两次写入之后才到达数据库。
|
||||
|
||||
* 在客户端A从数据库收到响应之前，客户端B的读取返回`1`，表示写入值`1`已成功。这也是可以的：这并不意味着在写之前读到了值，这只是意味着从数据库到客户端A的正确响应在网络中略有延迟。
|
||||
* 在客户端A从数据库收到响应之前，客户端B的读取返回 `1` ，表示写入值 `1` 已成功。这也是可以的：这并不意味着在写之前读到了值，这只是意味着从数据库到客户端A的正确响应在网络中略有延迟。
|
||||
|
||||
* 此模型不假设有任何事务隔离：另一个客户端可能随时更改值。例如，C首先读取`1`，然后读取`2`，因为两次读取之间的值由B更改。可以使用原子**比较并设置（cas）**操作来检查该值是否未被另一客户端同时更改：B和C的**cas**请求成功，但是D的**cas**请求失败（在数据库处理它时，`x`的值不再是`0`）。
|
||||
* 此模型不假设有任何事务隔离：另一个客户端可能随时更改值。例如，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](img/fig9-1.png)中的Alice和Bob的情况相同。
|
||||
* 客户B的最后一次读取（阴影条柱中）不是线性一致性的。 该操作与C的**cas**写操作并发（它将 `x` 从 `2` 更新为 `4` ）。在没有其他请求的情况下，B的读取返回 `2` 是可以的。然而，在B的读取开始之前，客户端A已经读取了新的值 `4` ，因此不允许B读取比A更旧的值。再次，与[图9-1](img/fig9-1.png)中的Alice和Bob的情况相同。
|
||||
|
||||
这就是线性一致性背后的直觉。 正式的定义【6】更准确地描述了它。 通过记录所有请求和响应的时序，并检查它们是否可以排列成有效的顺序，测试一个系统的行为是否线性一致性是可能的（尽管在计算上是昂贵的）【11】。
|
||||
|
||||
@ -178,13 +178,13 @@
|
||||
|
||||
如果想要确保银行账户余额永远不会为负数，或者不会出售比仓库里的库存更多的物品，或者两个人不会都预定了航班或剧院里同一时间的同一个位置。这些约束条件都要求所有节点都同意一个最新的值（账户余额，库存水平，座位占用率）。
|
||||
|
||||
在实际应用中，处理这些限制有时是可以接受的（例如，如果航班超额预订，你可以将客户转移到不同的航班并为其提供补偿）。在这种情况下，可能不需要线性一致性，我们将在第524页的“[及时性和完整性]()”中讨论这种松散解释的约束。
|
||||
在实际应用中，处理这些限制有时是可以接受的（例如，如果航班超额预订，你可以将客户转移到不同的航班并为其提供补偿）。在这种情况下，可能不需要线性一致性，我们将在“[及时性与完整性](ch12.md#及时性与完整性)”中讨论这种松散解释的约束。
|
||||
|
||||
然而，一个硬性的唯一性约束（关系型数据库中常见的那种）需要线性一致性。其他类型的约束，如外键或属性约束，可以在不需要线性一致性的情况下实现【19】。
|
||||
|
||||
#### 跨信道的时序依赖
|
||||
|
||||
注意[图9-1](img/fig9-1.png)中的一个细节：如果Alice没有惊呼得分，Bob就不会知道他的查询结果是陈旧的。他会在几秒钟之后再次刷新页面，并最终看到最后的分数。由于系统中存在额外的信道（Alice的声音传到了Bob的耳朵中），线性一致性的违背才被注意到。
|
||||
注意[图9-1](img/fig9-1.png) 中的一个细节：如果Alice没有惊呼得分，Bob就不会知道他的查询结果是陈旧的。他会在几秒钟之后再次刷新页面，并最终看到最后的分数。由于系统中存在额外的信道（Alice的声音传到了Bob的耳朵中），线性一致性的违背才被注意到。
|
||||
|
||||
计算机系统也会出现类似的情况。例如，假设有一个网站，用户可以上传照片，一个后台进程会调整照片大小，降低分辨率以加快下载速度（缩略图）。该系统的架构和数据流如[图9-5](img/fig9-5.png)所示。
|
||||
|
||||
@ -224,9 +224,9 @@
|
||||
|
||||
***无主复制（也许不是线性一致的）***
|
||||
|
||||
对于无领导者复制的系统（Dynamo风格；参阅“[无主复制](ch5.md#无主复制)”），有时候人们会声称通过要求法定人数读写（$w + r> n$）可以获得“强一致性”。这取决于法定人数的具体配置，以及强一致性如何定义（通常不完全正确）。
|
||||
对于无领导者复制的系统（Dynamo风格；参阅“[无主复制](ch5.md#无主复制)”），有时候人们会声称通过要求法定人数读写（ $w + r> n$ ）可以获得“强一致性”。这取决于法定人数的具体配置，以及强一致性如何定义（通常不完全正确）。
|
||||
|
||||
基于时钟（例如，在Cassandra中；参见“[依赖同步时钟](ch8.md#依赖同步时钟)”）的“最后写入胜利”冲突解决方法几乎可以确定是非线性的，由于时钟偏差，不能保证时钟的时间戳与实际事件顺序一致。松散的法定人数（第183页的“[松散法定人数与暗示接力](#马虎法定人数和暗示交接)”）也破坏了线性一致的可能性。即使使用严格的法定人数，非线性一致的行为也是可能的，如下一节所示。
|
||||
基于时钟（例如，在Cassandra中；参见“[依赖同步时钟](ch8.md#依赖同步时钟)”）的“最后写入胜利”冲突解决方法几乎可以确定是非线性的，由于时钟偏差，不能保证时钟的时间戳与实际事件顺序一致。[松散的法定人数](ch5.md#马虎法定人数和暗示交接)也破坏了线性一致的可能性。即使使用严格的法定人数，非线性一致的行为也是可能的，如下节所示。
|
||||
|
||||
#### 线性一致性和法定人数
|
||||
|
||||
@ -236,9 +236,9 @@
|
||||
|
||||
**图9-6 非线性一致的执行，尽管使用了严格的法定人数**
|
||||
|
||||
在[图9-6](img/fig9-6.png)中，$x$ 的初始值为0，写入客户端通过向所有三个副本（$n = 3, w = 3$）发送写入将 $x$ 更新为1。客户端A并发地从两个节点组成的法定人群（$r = 2$）中读取数据，并在其中一个节点上看到新值1。客户端B也并发地从两个不同的节点组成的法定人数中读取，并从两个节点中取回了旧值0。
|
||||
在[图9-6](img/fig9-6.png)中，$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]()）
|
||||
仲裁条件满足（ $w + r> n$ ），但是这个执行是非线性一致的：B的请求在A的请求完成后开始，但是B返回旧值，而A返回新值。 （又一次，如同Alice和Bob的例子 [图9-1]()）
|
||||
|
||||
有趣的是，通过牺牲性能，可以使Dynamo风格的法定人数线性化：读取者必须在将结果返回给应用程序之前，同步执行读取修复（参阅“[读时修复与反熵过程](ch5.md#读时修复与反熵过程)”） ，并且写入者必须在发送写入之前，读取法定数量节点的最新状态【24,25】。然而，由于性能损失，Riak不执行同步读取修复【26】。 Cassandra在进行法定人数读取时，**确实**在等待读取修复完成【27】；但是由于使用了最后写入为准的冲突解决方案，当同一个键有多个并发写入时，将不能保证线性一致性。
|
||||
|
||||
@ -279,7 +279,7 @@
|
||||
|
||||
因此不需要线性一致性的应用对网络问题有更强的容错能力。这种见解通常被称为CAP定理【29,30,31,32】，由Eric Brewer于2000年命名，尽管70年代的分布式数据库设计者早就知道了这种权衡【33,34,35,36】。
|
||||
|
||||
CAP最初是作为一个经验法则提出的，没有准确的定义，目的是开始讨论数据库的权衡。那时候许多分布式数据库侧重于在共享存储的集群上提供线性一致性的语义【18】，CAP定理鼓励数据库工程师向分布式无共享系统的设计领域深入探索，这类架构更适合实现大规模的网络服务【37】。 对于这种文化上的转变，CAP值得赞扬——它见证了自00年代中期以来新数据库的技术爆炸（即NoSQL）。
|
||||
CAP最初是作为一个经验法则提出的，没有准确的定义，目的是开始讨论数据库的权衡。那时候许多分布式数据库侧重于在共享存储的集群上提供线性一致性的语义【18】，CAP定理鼓励数据库工程师向分布式无共享系统的设计领域深入探索，这类架构更适合实现大规模的网络服务【37】。 对于这种文化上的转变，CAP值得赞扬 —— 它见证了自00年代中期以来新数据库的技术爆炸（即NoSQL）。
|
||||
|
||||
> ### CAP定理没有帮助
|
||||
>
|
||||
@ -344,7 +344,7 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
|
||||
|
||||
然而数学集合并不完全是全序的：`{a, b}` 比 `{b, c}` 更大吗？好吧，你没法真正比较它们，因为二者都不是对方的子集。我们说它们是**无法比较（incomparable）**的，因此数学集合是**偏序（partially order）**的：在某些情况下，可以说一个集合大于另一个（如果一个集合包含另一个集合的所有元素），但在其他情况下它们是无法比较的[^译注i]。
|
||||
|
||||
[^译注i]: 设R为非空集合A上的关系，如果R是自反的、反对称的和可传递的，则称R为A上的偏序关系。简称偏序，通常记作≦。一个集合A与A上的偏序关系R一起叫作偏序集，记作$<A,R>$或$<A, ≦>$。全序、偏序、关系、集合，这些概念的精确定义可以参考任意一本离散数学教材。
|
||||
[^译注i]: 设R为非空集合A上的关系，如果R是自反的、反对称的和可传递的，则称R为A上的偏序关系。简称偏序，通常记作≦。一个集合A与A上的偏序关系R一起叫作偏序集，记作$(A,R)$或$(A, ≦)$。全序、偏序、关系、集合，这些概念的精确定义可以参考任意一本离散数学教材。
|
||||
|
||||
全序和偏序之间的差异反映在不同的数据库一致性模型中：
|
||||
|
||||
@ -358,13 +358,13 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
|
||||
|
||||
因此，根据这个定义，在线性一致的数据存储中是不存在并发操作的：必须有且仅有一条时间线，所有的操作都在这条时间线上，构成一个全序关系。可能有几个请求在等待处理，但是数据存储确保了每个请求都是在唯一时间线上的某个时间点自动处理的，不存在任何并发。
|
||||
|
||||
并发意味着时间线会分岔然后合并——在这种情况下，不同分支上的操作是无法比较的（即并发操作）。在[第五章](ch5.md)中我们看到了这种现象：例如，[图5-14](img/fig5-14.md)并不是一条直线的全序关系，而是一堆不同的操作并发进行。图中的箭头指明了因果依赖——操作的偏序。
|
||||
并发意味着时间线会分岔然后合并——在这种情况下，不同分支上的操作是无法比较的（即并发操作）。在[第五章](ch5.md)中我们看到了这种现象：例如，[图5-14](img/fig5-14.md) 并不是一条直线的全序关系，而是一堆不同的操作并发进行。图中的箭头指明了因果依赖——操作的偏序。
|
||||
|
||||
如果你熟悉像Git这样的分布式版本控制系统，那么其版本历史与因果关系图极其相似。通常，一个**提交（Commit）**发生在另一个提交之后，在一条直线上。但是有时你会遇到分支（当多个人同时在一个项目上工作时），**合并（Merge）**会在这些并发创建的提交相融合时创建。
|
||||
|
||||
#### 线性一致性强于因果一致性
|
||||
|
||||
那么因果顺序和线性一致性之间的关系是什么？答案是线性一致性**隐含着（implies）**因果关系：任何线性一致的系统都能正确保持因果性【7】。特别是，如果系统中有多个通信通道（如[图9-5](img/fig9-5.png)中的消息队列和文件存储服务），线性一致性可以自动保证因果性，系统无需任何特殊操作（如在不同组件间传递时间戳）。
|
||||
那么因果顺序和线性一致性之间的关系是什么？答案是线性一致性**隐含着（implies）**因果关系：任何线性一致的系统都能正确保持因果性【7】。特别是，如果系统中有多个通信通道（如[图9-5](img/fig9-5.png) 中的消息队列和文件存储服务），线性一致性可以自动保证因果性，系统无需任何特殊操作（如在不同组件间传递时间戳）。
|
||||
|
||||
线性一致性确保因果性的事实使线性一致系统变得简单易懂，更有吸引力。然而，正如“[线性一致性的代价](#线性一致性的代价)”中所讨论的，使系统线性一致可能会损害其性能和可用性，尤其是在系统具有严重的网络延迟的情况下（例如，如果系统在地理上散布）。出于这个原因，一些分布式数据系统已经放弃了线性一致性，从而获得更好的性能，但它们用起来也更为困难。
|
||||
|
||||
@ -440,7 +440,7 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
|
||||
|
||||
迄今，这个描述与上节所述的奇偶计数器基本类似。使兰伯特时间戳因果一致的关键思想如下所示：每个节点和每个客户端跟踪迄今为止所见到的最大**计数器**值，并在每个请求中包含这个最大计数器值。当一个节点收到最大计数器值大于自身计数器值的请求或响应时，它立即将自己的计数器设置为这个最大值。
|
||||
|
||||
这如 [图9-8](img/fig9-8.png) 所示，其中客户端 A 从节点 2 接收计数器值 5 ，然后将最大值 5 发送到节点 1 。此时，节点 1 的计数器仅为 1 ，但是它立即前移至 5 ，所以下一个操作的计数器的值为 6 。
|
||||
这如 [图9-8](img/fig9-8.png) 所示，其中客户端 A 从节点2 接收计数器值 `5` ，然后将最大值 `5` 发送到节点1 。此时，节点1 的计数器仅为 `1` ，但是它立即前移至 `5` ，所以下一个操作的计数器的值为 `6` 。
|
||||
|
||||
只要每一个操作都携带着最大计数器值，这个方案确保兰伯特时间戳的排序与因果一致，因为每个因果依赖都会导致时间戳增长。
|
||||
|
||||
@ -534,17 +534,15 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
|
||||
|
||||
上一节介绍了如何从全序广播构建一个线性一致的CAS操作。我们也可以把它反过来，假设我们有线性一致的存储，接下来会展示如何在此基础上构建全序广播。
|
||||
|
||||
最简单的方法是假设你有一个线性一致的寄存器来存储一个整数，并且有一个原子**增量和获取**操作【28】。或者CAS操作也可以完成这项工作。
|
||||
最简单的方法是假设你有一个线性一致的寄存器来存储一个整数，并且有一个原子**自增并返回**操作【28】。或者原子CAS操作也可以完成这项工作。
|
||||
|
||||
该算法很简单：对于每个要通过全部顺序广播发送的消息，你将递增并获取线性一致性的整数，然后将从寄存器获得的值作为序号附加到消息中。然后，你可以将消息发送到所有节点（重新发送任何丢失的消息），并且收件人将按序号连续发送消息。
|
||||
该算法很简单：每个要通过全序广播发送的消息首先对线性一致寄存器执行**自增并返回**操作。然后将从寄存器获得的值作为序列号附加到消息中。然后你可以将消息发送到所有节点（重新发送任何丢失的消息），而收件人将按序列号连续发送消息。
|
||||
|
||||
请注意，与兰伯特时间戳不同，你通过递增线性一致性寄存器获得的数字形成一个没有间隙的序列。因此，如果一个节点已经发送了消息4并且接收到序列号为6的传入消息，则它知道它在传递消息6之前必须等待消息5.同样的情况并非如此
|
||||
请注意，与兰伯特时间戳不同，通过自增线性一致性寄存器获得的数字形式上是一个没有间隙的序列。因此，如果一个节点已经发送了消息 4 并且接收到序列号为 6 的传入消息，则它知道它在传递消息 6 之前必须等待消息 5 。兰伯特时间戳则与之不同 ——事实上，这是全序广播和时间戳排序间的关键区别。
|
||||
|
||||
与兰伯特时间戳——事实上，这是全序广播和时间戳顺序之间的关键区别。
|
||||
实现一个带有原子性**自增并返回**操作的线性一致寄存器有多困难？像往常一样，如果事情从来不出差错，那很容易：你可以简单地把它保存在单个节点内的变量中。问题在于处理当该节点的网络连接中断时的情况，并在该节点失效时能恢复这个值【59】。一般来说，如果你对线性一致性的序列号生成器进行深入过足够深入的思考，你不可避免地会得出一个共识算法。
|
||||
|
||||
使用原子增量和获取操作来创建线性一致性整数有多困难？像往常一样，如果事情从来没有失败过，那很容易：你可以把它保存在一个节点的变量中。问题在于处理当该节点的网络连接中断时的情况，并在该节点失败时恢复该值【59】。一般来说，如果你对线性一致性序列号的产生者认真思考，你不可避免地会得出一个一致的算法。
|
||||
|
||||
这并非巧合：可以证明，线性一致性的比较和设置（或增量和取得）寄存器和全序广播都相当于【28,67】。也就是说，如果你能解决其中的一个问题，你可以把它转化成为其他问题的解决方案。这是相当深刻和令人惊讶的洞察力！
|
||||
这并非巧合：可以证明，线性一致的CAS（或自增并返回）寄存器与全序广播都都等价于**共识**问题【28,67】。也就是说，如果你能解决其中的一个问题，你可以把它转化成为其他问题的解决方案。这是相当深刻和令人惊讶的洞察！
|
||||
|
||||
现在是时候正面处理共识问题了，我们将在本章的其余部分进行讨论。
|
||||
|
||||
@ -552,125 +550,125 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
|
||||
|
||||
## 分布式事务与共识
|
||||
|
||||
共识是分布式计算中最重要也是最基本的问题之一。从表面上看，似乎很简单：非正式地说，目标只是让几个节点达成一致。你可能会认为这不应该太难。不幸的是，许多破损的系统已经被误认为这个问题很容易解决。
|
||||
**共识**是分布式计算中最重要也是最基本的问题之一。从表面上看似乎很简单：非正式地讲，目标只是**让几个节点达成一致（get serveral nodes to agree on something）**。你也许会认为这不会太难。不幸的是，许多出故障的系统都是因为错误地轻信这个问题很容易解决。
|
||||
|
||||
虽然共识是非常重要的，但关于它的部分在本书的后半部分已经出现了，因为这个主题非常微妙，欣赏细微之处需要一些必要的知识。即使在学术研究界，对共识的理解也只是在几十年的时间内逐渐显现出来，一路上有许多误解。现在我们已经讨论了复制（[第5章](ch5.md)），事务（[第7章](ch7.md)），系统模型（[第8章](ch8.md)），线性一致性以及全序（[本章](ch9.md)），我们终于准备好解决共识问题了。
|
||||
尽管共识非常重要，但关于它的内容出现在本书的后半部分，因为这个主题非常微妙，欣赏细微之处需要一些必要的知识。即使在学术界，对共识的理解也是在几十年的过程中逐渐沉淀而来，一路上也有着许多误解。现在我们已经讨论了复制（[第5章](ch5.md)），事务（[第7章](ch7.md)），系统模型（[第8章](ch8.md)），线性一致以及全序（[本章](ch9.md)），我们终于准备好解决共识问题了。
|
||||
|
||||
在节点达成一致的情况下，有许多情况是很重要的。例如：
|
||||
节点能达成一致，在很多场景下都非常重要，例如：
|
||||
|
||||
***领导选举***
|
||||
|
||||
在具有单引导程序复制的数据库中，所有节点需要就哪个节点是领导者达成一致。如果一些节点由于网络故障而无法与其他节点通信，则可能会引起争议。在这种情况下，一致性对于避免错误的故障切换非常重要，从而导致两个节点都认为自己是领导者的脑裂情况（参阅“[处理节点宕机](ch5.md#处理节点宕机)”）。如果有两个领导者，它们都会接受写入，他们的数据会发生分歧，导致不一致和数据丢失。
|
||||
在单主复制的数据库中，所有节点需要就哪个节点是领导者达成一致。如果一些节点由于网络故障而无法与其他节点通信，则可能会对领导权的归属引起争议。在这种情况下，共识对于避免错误的故障切换非常重要。错误的故障切换会导致两个节点都认为自己是领导者（**脑裂**，参阅“[处理节点宕机](ch5.md#处理节点宕机)”）。如果有两个领导者，它们都会接受写入，它们的数据会发生分歧，从而导致不一致和数据丢失。
|
||||
|
||||
***原子提交***
|
||||
|
||||
在支持跨越多个节点或分区的事务的数据库中，有一个事务可能在某些节点上失败，但在其他节点上成功。如果我们想要维护事务的原子性（就ACID而言，请参“[原子性](ch7.md#原子性)”），我们必须让所有节点对事务的结果达成一致：要么全部中止/回滚（如果出现任何错误）或者他们都承诺（如果没有出错）。这个共识的例子被称为原子提交问题[^xii]。
|
||||
在支持跨多节点或跨多分区事务的数据库中，一个事务可能在某些节点上失败，但在其他节点上成功。如果我们想要维护事务的原子性（就ACID而言，请参“[原子性](ch7.md#原子性)”），我们必须让所有节点对事务的结果达成一致：要么全部中止/回滚（如果出现任何错误），要么它们全部提交（如果没有出错）。这个共识的例子被称为**原子提交（atomic commit）**问题[^xii]。
|
||||
|
||||
|
||||
[^xii]: 原子提交的形式化与共识稍有不同：原子事务只有在所有参与者投票提交的情况下才能提交，如果有任何参与者需要中止，则必须中止。 允许共识决定其中一位参与者提出的任何值。 然而，原子的承诺和共识是可以相互压缩的【70,71】。 非阻塞原子提交比共识更难——参阅“[三阶段提交](#三阶段提交)”。
|
||||
[^xii]: 原子提交的形式化与共识稍有不同：原子事务只有在**所有**参与者投票提交的情况下才能提交，如果有任何参与者需要中止，则必须中止。 共识则允许就**任意一个**被参与者提出的候选值达成一致。 然而，原子提交和共识可以相互简化为对方【70,71】。 **非阻塞**原子提交则要比共识更为困难 —— 参阅“[三阶段提交](#三阶段提交)”。
|
||||
|
||||
> ### 共识的不可能性
|
||||
>
|
||||
> 你可能已经听说过作者Fischer，Lynch和Paterson之后的FLP结果【68】，这证明如果存在节点可能崩溃的风险，则不存在总是能够达成一致的算法。在分布式系统中，我们必须假设节点可能会崩溃，所以可靠的共识是不可能的。然而，在这里，我们正在讨论达成共识的算法。这里发生了什么？
|
||||
> 你可能已经听说过作者Fischer，Lynch和Paterson之后的FLP结果【68】，它证明，如果存在节点可能崩溃的风险，则不存在**总是**能够达成共识的算法。在分布式系统中，我们必须假设节点可能会崩溃，所以可靠的共识是不可能的。然而这里我们正在讨论达成共识的算法，到底是怎么回事？
|
||||
>
|
||||
> 答案是FLP结果在异步系统模型中得到了证明（参阅“[系统模型与现实](#系统模型与现实)”），这是一个非常有限的模型，它假定确定性算法不能使用任何时钟或超时。如果算法被允许使用超时或其他方法来识别可疑的崩溃节点（即使怀疑有时是错误的），那么共识就变得可以解决了【67】。即使只允许算法使用随机数也足以绕过不可能的结果【69】。
|
||||
> 答案是FLP结果在**异步系统模型**中得到了证明（参阅“[系统模型与现实](ch8.md#系统模型与现实)”），这是一种限制性很强的模型，它假定确定性算法不能使用任何时钟或超时。如果允许算法使用**超时**或其他方法来识别可疑的崩溃节点（即使怀疑有时是错误的），则共识变为一个可解的问题【67】。即使仅仅允许算法使用随机数，也足以绕过这个不可能的结果【69】。
|
||||
>
|
||||
> 因此，FLP虽然不可能达成共识，但理论上具有重要意义，但实际上分布式系统通常可以达成共识。
|
||||
> 因此，FLP是关于共识不可能性的重要理论结果，但现实中的分布式系统通常是可以达成共识的。
|
||||
|
||||
在本节中，我们将首先更详细地检查原子提交问题。具体来说，我们将讨论两阶段提交（2PC）算法，这是解决原子提交最常见的方法，并在各种数据库、消息传递系统和应用服务器中实现。事实证明，2PC是一种一致的算法，但并不是一个很好的算法【70,71】。
|
||||
在本节中，我们将首先更详细地研究**原子提交**问题。具体来说，我们将讨论**两阶段提交（2PC, two-phase commit）**算法，这是解决原子提交问题最常见的办法，并在各种数据库、消息队列和应用服务器中实现。事实证明2PC是一种共识算法，但不是一个非常好的算法【70,71】。
|
||||
|
||||
通过对2PC学习，我们将继续努力实现更好的一致性算法，比如ZooKeeper（Zab）和etcd（Raft）中使用的算法。
|
||||
通过对2PC的学习，我们将继续努力实现更好的一致性算法，比如ZooKeeper（Zab）和etcd（Raft）中使用的算法。
|
||||
|
||||
|
||||
|
||||
### 原子提交与二阶段提交（2PC）
|
||||
|
||||
在[第7章](ch7.md)中，我们了解到事务原子性的目的是在出现几次写错的情况下提供简单的语义。事务的结果要么是成功的提交，在这种情况下，所有事务的写入都是持久的，或者中止，在这种情况下，所有事务的写入都被回滚（即撤消或丢弃）。
|
||||
在[第7章](ch7.md)中我们了解到，事务原子性的目的是在多次写操作中途出错的情况下，提供一种简单的语义。事务的结果要么是成功提交，在这种情况下，事务的所有写入都是持久化的；要么是中止，在这种情况下，事务的所有写入都被回滚（即撤消或丢弃）。
|
||||
|
||||
原子性可以防止失败的事务搅乱数据库，其结果是半成品和半更新状态。这对于多对象事务（参阅“[单对象和多对象操作](ch7.md#单对象和多对象操作)”）和维护二级索引的数据库尤其重要。每个辅助索引都是与主数据分离的数据结构——因此，如果你修改了一些数据，则还需要在辅助索引中进行相应的更改。原子性确保二级索引与主数据保持一致（如果索引与主数据不一致，则不会很有用）。
|
||||
原子性可以防止失败的事务搅乱数据库，避免数据库陷入半成品结果和半更新状态。这对于多对象事务（参阅“[单对象和多对象操作](ch7.md#单对象和多对象操作)”）和维护次级索引的数据库尤其重要。每个辅助索引都是与主数据相分离的数据结构—— 因此，如果你修改了一些数据，则还需要在辅助索引中进行相应的更改。原子性确保二级索引与主数据保持一致（如果索引与主数据不一致，就没什么用了）。
|
||||
|
||||
#### 从单节点到分布式原子提交
|
||||
|
||||
对于在单个数据库节点执行的事务，原子性通常由存储引擎执行。当客户端请求数据库节点提交事务时，数据库使事务的写入持久化（通常在预写式日志中：参阅“[使B树可靠](ch3.md#使B树可靠)”），然后将提交记录追加到日志中磁盘。如果数据库在这个过程中间崩溃，当节点重新启动时，事务从日志中恢复：如果提交记录在崩溃之前成功地写入磁盘，则认为事务被提交；否则来自该事务的任何写入都被回滚。
|
||||
对于在单个数据库节点执行的事务，原子性通常由存储引擎实现。当客户端请求数据库节点提交事务时，数据库将使事务的写入持久化（通常在预写式日志中：参阅“[使B树可靠](ch3.md#使B树可靠)”），然后将提交记录追加到磁盘中的日志里。如果数据库在这个过程中间崩溃，当节点重启时，事务会从日志中恢复：如果提交记录在崩溃之前成功地写入磁盘，则认为事务被提交；否则来自该事务的任何写入都被回滚。
|
||||
|
||||
因此，在单个节点上，事务承诺主要取决于数据持久写入磁盘的顺序：首先是数据，然后是提交记录【72】。事务提交或放弃的关键决定时刻是磁盘完成写入提交记录的时刻：在此之前，仍有可能中止（由于崩溃），但在此之后，事务已经提交（即使数据库崩溃）。因此，这是一个单一的设备（一个特定的磁盘驱动器的控制器，连接到一个特定的节点），使得提交具有原子性。
|
||||
因此，在单个节点上，事务的提交主要取决于数据持久化落盘的**顺序**：首先是数据，然后是提交记录【72】。事务提交或终止的关键决定时刻是磁盘完成写入提交记录的时刻：在此之前，仍有可能中止（由于崩溃），但在此之后，事务已经提交（即使数据库崩溃）。因此，是单一的设备（连接到单个磁盘驱动的控制器，且挂载在单台机器上）使得提交具有原子性。
|
||||
|
||||
但是，如果一个事务中涉及多个节点呢？例如，也许在分区数据库中有一个多对象事务，或者是一个由关键词分区的二级索引（其中索引条目可能位于与主数据不同的节点上；参阅“[分区和二级索引](ch6.md#分区和二级索引)”）。大多数“NoSQL”分布式数据存储不支持这种分布式事务，而是各种集群关系系统（请参见“[实践中的分布式事务](#实践中的分布式事务)”）。
|
||||
但是，如果一个事务中涉及多个节点呢？例如，你也许在分区数据库中会有一个多对象事务，或者是一个按关键词分区的二级索引（其中索引条目可能位于与主数据不同的节点上；参阅“[分区和二级索引](ch6.md#分区和二级索引)”）。大多数“NoSQL”分布式数据存储不支持这种分布式事务，但是很多关系型数据库集群支持（参见“[实践中的分布式事务](#实践中的分布式事务)”）。
|
||||
|
||||
在这些情况下，仅向所有节点发送提交请求并且独立提交每个节点的事务是不够的。这样做很容易发生：提交在某些节点上成功，在其他节点上失败，这违反了原子性保证：
|
||||
在这些情况下，仅向所有节点发送提交请求并独立提交每个节点的事务是不够的。这样很容易发生违反原子性的情况：提交在某些节点上成功，而在其他节点上失败：
|
||||
|
||||
* 某些节点可能会检测到约束冲突或冲突，因此需要中止，而其他节点则可以成功进行提交。
|
||||
* 某些提交请求可能在网络中丢失，最终由于超时而中止，而其他提交请求则通过。
|
||||
* 在提交记录完全写入之前，某些节点可能会崩溃，并在恢复时回滚，而其他节点则成功提交。
|
||||
|
||||
如果某些节点提交了事务，但其他节点却放弃了这些事务，那么这些节点就会彼此不一致（如[图7-3](img/fig7-3.png)所示）。而且一旦在一个节点上提交了一个事务，如果事后证明它在另一个节点上被中止，它将不能被撤回。出于这个原因，一旦确定事务中的所有其他节点也将提交，节点就必须进行提交。
|
||||
如果某些节点提交了事务，但其他节点却放弃了这些事务，那么这些节点就会彼此不一致（如 [图7-3](img/fig7-3.png) 所示）。而且一旦在某个节点上提交了一个事务，如果事后发现它在其它节点上被中止了，它是无法撤回的。出于这个原因，一旦确定事务中的所有其他节点也将提交，节点就必须进行提交。
|
||||
|
||||
事务提交必须是不可撤销的——你不能改变主意，并在事务提交后追溯中止事务。这个规则的原因是，一旦数据被提交，其他事务就可以看到，因此其他客户可能会开始依赖这些数据。这个原则构成了读已提交隔离等级的基础，在“[读已提交](ch7.md#读已提交)”一节中讨论了这个问题。如果一个事务在提交后被允许中止，所有读取提交数据的事务将基于被追溯声明不存在的数据，所以它们也必须恢复。
|
||||
事务提交必须是不可撤销的 —— 事务提交之后，你不能改变主意，并追溯性地中止事务。这个规则的原因是，一旦数据被提交，其结果就对其他事务可见，因此其他客户端可能会开始依赖这些数据。这个原则构成了**读已提交**隔离等级的基础，在“[读已提交](ch7.md#读已提交)”一节中讨论了这个问题。如果一个事务在提交后被允许中止，所有那些读取了**已提交却又被追溯声明不存在数据**的事务也必须回滚。
|
||||
|
||||
（提交事务的效果有可能后续通过另一个补偿事务取消【73,74】，但从数据库的角度来看，这是一个单独的事务，因此任何关于交叉事务正确性的保证是应用自己的问题。）
|
||||
（提交事务的结果有可能通过事后执行另一个补偿事务来取消【73,74】，但从数据库的角度来看，这是一个单独的事务，因此任何关于跨事务正确性的保证都是应用自己的问题。）
|
||||
|
||||
#### 介绍两阶段提交
|
||||
#### 两阶段提交简介
|
||||
|
||||
两阶段提交是一种用于实现跨多个节点的原子事务提交的算法，即确保所有节点提交或所有节点中止。 它是分布式数据库中的经典算法【13,35,75】。 2PC在某些数据库内部使用，并且还以XA事务【76,77】（例如Java Transaction API支持）或通过`WS-AtomicTransaction for SOAP Web`服务的形式提供给应用程序【78,79】。
|
||||
**两阶段提交（two-phase commit）**是一种用于实现跨多个节点的原子事务提交的算法，即确保所有节点提交或所有节点中止。 它是分布式数据库中的经典算法【13,35,75】。 2PC在某些数据库内部使用，也以**XA事务**的形式对应用可用【76,77】（例如Java Transaction API支持）或以SOAP Web服务的`WS-AtomicTransaction` 形式提供给应用程序【78,79】。
|
||||
|
||||
[图9-9](img/fig9-9)说明了2PC的基本流程。 与单节点事务一样，2PC中的提交/终止进程分为两个阶段（因此而得名），而不是单个提交请求。
|
||||
[图9-9](img/fig9-9)说明了2PC的基本流程。2PC中的提交/中止过程分为两个阶段（因此而得名），而不是单节点事务中的单个提交请求。
|
||||
|
||||
|
||||
|
||||
**图9-9 两阶段提交（2PC）的成功执行**
|
||||
|
||||
> #### 不要混淆2PC和2PL
|
||||
> #### 不要把2PC和2PL搞混了
|
||||
>
|
||||
> 两阶段提交（2PC）和两阶段锁定（参阅“[两阶段锁定（2PL）](ch7.md#两阶段锁定（2PL）)”）是两个完全不同的事情。 2PC在分布式数据库中提供原子提交，而2PL提供可序列化的隔离。为了避免混淆，最好把它们看作完全独立的概念，并忽略名称中的不幸的相似性。
|
||||
> 两阶段提交（2PC）和两阶段锁定（参阅“[两阶段锁定（2PL）](ch7.md#两阶段锁定（2PL）)”）是两个完全不同的东西。 2PC在分布式数据库中提供原子提交，而2PL提供可序列化的隔离等级。为了避免混淆，最好把它们看作完全独立的概念，并忽略名称中不幸的相似性。
|
||||
|
||||
2PC使用一个通常不会出现在单节点事务中的新组件：**协调者（coordinator）**（也称为事务管理器）。协调者通常在请求事务的相同应用程序进程（例如，嵌入在Java EE容器中）中实现为库，但也可以是单独的进程或服务。这种协调者的例子包括Narayana，JOTM，BTM或MSDTC。
|
||||
2PC使用一个通常不会出现在单节点事务中的新组件：**协调者（coordinator）**（也称为**事务管理器（transaction manager）**）。协调者通常在请求事务的相同应用程序进程中以库的形式实现（例如，嵌入在Java EE容器中），但也可以是单独的进程或服务。这种协调者的例子包括Narayana，JOTM，BTM或MSDTC。
|
||||
|
||||
正常情况下，2PC事务从应用程序在多个数据库节点上读写数据开始。我们把这些数据库节点称为事务参与者。当应用程序准备提交时，协调者开始阶段1：它发送一个准备请求到每个节点，询问他们是否能够提交。协调者然后跟踪参与者的回应：
|
||||
正常情况下，2PC事务以应用程序在多个数据库节点上读写数据开始。我们称这些数据库节点为**参与者（participants）**。当应用程序准备提交时，协调者开始阶段 1 ：它发送一个**准备（prepare）**请求到每个节点，询问它们是否能够提交。然后协调者会跟踪参与者的响应：
|
||||
|
||||
* 如果所有参与者都回答“是”，表示他们已经准备好提交，那么协调者在阶段2发出**提交（commit）**请求，实际发生提交。
|
||||
* 如果任何参与者回复“否”，则协调者在阶段2中向所有节点发送**中止（abort）**请求。
|
||||
* 如果所有参与者都回答“是”，表示它们已经准备好提交，那么协调者在阶段 2 发出**提交（commit）**请求，然后提交真正发生。
|
||||
* 如果任意一个参与者回复了“否”，则协调者在阶段2 中向所有节点发送**中止（abort）**请求。
|
||||
|
||||
这个过程有点像西方传统婚姻仪式：司仪分别询问新娘和新郎是否要结婚，通常是从两方都收到“我愿意”的答复。收到两者的回复后，司仪宣布这对情侣成为夫妻：事务就提交了，这一幸福事实会广播至所有的参与者中。如果新娘与新郎之一没有回复”我愿意“，婚礼就会中止【73】。
|
||||
|
||||
#### 承诺系统
|
||||
|
||||
从这个简短的描述可能不清楚为什么两阶段提交确保了原子性，而跨几个节点的一阶段提交没有。准备和提交请求当然可以在两阶段的情况下轻易地丢失。 2PC有什么不同？
|
||||
这个简短的描述可能并没有说清楚为什么两阶段提交保证了原子性，而跨多个节点的一阶段提交却没有。在两阶段提交的情况下，准备请求和提交请求当然也可以轻易丢失。 2PC又有什么不同呢？
|
||||
|
||||
为了理解它的工作原理，我们必须更详细地分解这个过程：
|
||||
|
||||
1. 当应用想要开启一个分布式事务时，它向协调者请求一个事务ID。此事务ID是全局唯一的。
|
||||
2. 应用在每个参与者上开始单节点事务，并将全局唯一事务ID附到单节点事务上。所有的读写都是在这些单节点事务之一中完成的。如果在这个阶段出现任何问题（例如，节点崩溃或请求超时），则协调者或任何参与者都可以中止。
|
||||
3. 当应用程序准备提交时，协调者向所有参与者发送一个准备请求，标记为全局事务ID。如果这些请求中的任何一个失败或超时，则协调者向所有参与者发送针对该事务ID的放弃请求。
|
||||
4. 参与者收到准备请求时，确保在任何情况下都可以明确地进行事务。这包括将所有事务数据写入磁盘（出现故障，电源故障或硬盘空间不足以拒绝稍后提交）以及检查是否存在任何冲突或约束违规。通过向协调者回答“是”，节点承诺在没有错误的情况下提交事务。换句话说，参与者放弃了中止事务的权利，但没有实际提交。
|
||||
5. 当协调者收到所有准备请求的答复时，就是否提交或中止事务作出明确的决定（只有在所有参与者投赞成票的情况下才提交）。协调者必须把这个决定写到磁盘上的事务日志中，以便它知道它决定的方式，以防随后发生崩溃。这被称为**提交点（commit point）**。
|
||||
6. 一旦协调者的决定写入磁盘，提交或放弃请求被发送给所有参与者。如果此请求失败或超时，则协调者必须一直重试，直到成功为止。没有更多的事情要做，如果做出决定，那么决定必须执行，不管它需要多少次重试。如果参与者在此期间崩溃，事务将在恢复时进行——由于参与者投票“是”，因此恢复时不能拒绝提交。
|
||||
1. 当应用想要启动一个分布式事务时，它向协调者请求一个事务ID。此事务ID是全局唯一的。
|
||||
2. 应用在每个参与者上启动单节点事务，并在单节点事务上捎带上这个全局事务ID。所有的读写都是在这些单节点事务中各自完成的。如果在这个阶段出现任何问题（例如，节点崩溃或请求超时），则协调者或任何参与者都可以中止。
|
||||
3. 当应用准备提交时，协调者向所有参与者发送一个**准备**请求，并打上全局事务ID的标记。如果任意一个请求失败或超时，则协调者向所有参与者发送针对该事务ID的中止请求。
|
||||
4. 参与者收到准备请求时，需要确保在任意情况下都的确可以提交事务。这包括将所有事务数据写入磁盘（出现故障，电源故障，或硬盘空间不足都不能是稍后拒绝提交的理由）以及检查是否存在任何冲突或违反约束。通过向协调者回答“是”，节点承诺，只要请求，这个事务一定可以不出差错地提交。换句话说，参与者放弃了中止事务的权利，但没有实际提交。
|
||||
5. 当协调者收到所有准备请求的答复时，会就提交或中止事务作出明确的决定（只有在所有参与者投赞成票的情况下才会提交）。协调者必须把这个决定写到磁盘上的事务日志中，如果它随后就崩溃，恢复后也能知道自己所做的决定。这被称为**提交点（commit point）**。
|
||||
6. 一旦协调者的决定落盘，提交或放弃请求会发送给所有参与者。如果这个请求失败或超时，协调者必须永远保持重试，直到成功为止。没有回头路：如果已经做出决定，不管需要多少次重试它都必须被执行。如果参与者在此期间崩溃，事务将在其恢复后提交——由于参与者投了赞成，因此恢复后它不能拒绝提交。
|
||||
|
||||
因此，该协议包含两个关键的“不归路”点：当参与者投票“是”时，它承诺它肯定能够稍后提交（尽管协调者可能仍然选择放弃）。一旦协调者决定，这个决定是不可撤销的。这些承诺保证了2PC的原子性。 （单节点原子提交将这两个事件合并为一个：将提交记录写入事务日志。）
|
||||
因此，该协议包含两个关键的“不归路”点：当参与者投票“是”时，它承诺它稍后肯定能够提交（尽管协调者可能仍然选择放弃）。一旦协调者做出决定，这一决定是不可撤销的。这些承诺保证了2PC的原子性。 （单节点原子提交将这两个事件混为一谈：将提交记录写入事务日志。）
|
||||
|
||||
回到婚姻的比喻，在说“我是”之前，你和你的新娘/新郎有“中止”这个事务的自由，通过回复“不行！”（或者差不多效果的话）。然而，在说“我愿意”之后，你就不能收回那个声明了。如果你说“我愿意”后晕倒了，而你没有听到司仪说“你们现在是夫妻了”，那并不会改变事务已经提交的事实。当你稍后恢复意识时，你可以通过查询司仪的全局事务ID状态来查明你是否已婚，或者你可以等待司仪重试下一次提交请求（因为重试将在你无意识期间一直持续）。
|
||||
回到婚姻的比喻，在说“我是”之前，你和你的新娘/新郎有中止这个事务的自由，通过回复 “没门！”（或者有类似效果的话）。然而在说了“我愿意”之后，你就不能撤回那个声明了。如果你说“我愿意”后晕倒了，没有听到司仪说“你们现在是夫妻了”，那也并不会改变事务已经提交的现实。当你稍后恢复意识时，可以通过查询司仪的全局事务ID状态来确定你是否已经成婚，或者你可以等待司仪重试下一次提交请求（因为重试将在你无意识期间一直持续）。
|
||||
|
||||
#### 协调者失效
|
||||
|
||||
我们已经讨论了在2PC期间如果其中一个参与者或网络发生故障会发生什么情况：如果任何一个准备请求失败或者超时，协调者就中止事务。如果任何提交或中止请求失败，协调者将无条件重试。但是，如果协调者崩溃，会发生什么情况并不太清楚。
|
||||
我们已经讨论了在2PC期间，如果参与者之一或网络发生故障时会发生什么情况：如果任何一个**准备**请求失败或者超时，协调者就会中止事务。如果任何提交或中止请求失败，协调者将无条件重试。但是如果协调者崩溃，会发生什么情况就不太清楚了。
|
||||
|
||||
如果协调者在发送准备请求之前失败，参与者可以安全地中止事务。但是，一旦参与者收到了准备请求并投了“是”，就不能再单方面放弃——必须等待协调者回答事务是否已经发生或中止。如果此时协调者崩溃或网络出现故障，参与者只能等待。参与者在这个状态下的事务是存疑的或不确定的。
|
||||
如果协调者在发送**准备**请求之前失败，参与者可以安全地中止事务。但是，一旦参与者收到了准备请求并投了“是”，就不能再单方面放弃 —— 必须等待协调者回答事务是否已经提交或中止。如果此时协调者崩溃或网络出现故障，参与者什么也做不了只能等待。参与者的这种事务状态称为**存疑（in doubt）**的或**不确定（uncertain）**的。
|
||||
|
||||
情况如[图9-10](img/fig9-10)所示。在这个特定的例子中，协调者实际上决定提交，数据库2收到提交请求。但是，协调者在将提交请求发送到数据库1之前发生崩溃，因此数据库1不知道是否提交或中止。即使超时在这里也没有帮助：如果数据库1在超时后单方面中止，它将最终与提交的数据库2不一致。同样，单方面犯也是不安全的，因为另一个参与者可能已经中止了。
|
||||
情况如[图9-10](img/fig9-10) 所示。在这个特定的例子中，协调者实际上决定提交，数据库2 收到提交请求。但是，协调者在将提交请求发送到数据库1 之前发生崩溃，因此数据库1 不知道是否提交或中止。即使**超时**在这里也没有帮助：如果数据库1 在超时后单方面中止，它将最终与执行提交的数据库2 不一致。同样，单方面提交也是不安全的，因为另一个参与者可能已经中止了。
|
||||
|
||||
|
||||
**图9-10 参与者投赞成票后，协调者崩溃。数据库1不知道是否提交或中止**
|
||||
|
||||
没有协调者的消息，参与者无法知道是否承诺或放弃。原则上，参与者可以相互沟通，找出每个参与者如何投票并达成一致，但这不是2PC协议的一部分。
|
||||
没有协调者的消息，参与者无法知道是提交还是放弃。原则上参与者可以相互沟通，找出每个参与者是如何投票的，并达成一致，但这不是2PC协议的一部分。
|
||||
|
||||
2PC可以完成的唯一方法是等待协调者恢复。这就是为什么协调者必须在向参与者发送提交或中止请求之前将其提交或中止决定写入磁盘上的事务日志：协调者恢复后，通过读取其事务日志来确定所有存疑事务的状态。任何在协调者日志中没有提交记录的事务都会中止。因此，2PC的**提交点**归结为协调者上的常规单节点原子提交。
|
||||
可以完成2PC的唯一方法是等待协调者恢复。这就是为什么协调者必须在向参与者发送提交或中止请求之前，将其提交或中止决定写入磁盘上的事务日志：协调者恢复后，通过读取其事务日志来确定所有存疑事务的状态。任何在协调者日志中没有提交记录的事务都会中止。因此，2PC的**提交点**归结为协调者上的常规单节点原子提交。
|
||||
|
||||
#### 三阶段提交
|
||||
|
||||
两阶段提交被称为阻塞原子提交协议，因为2PC可能卡住，等待协调者恢复。理论上，可以使一个原子提交协议非阻塞，以便在节点失败时不会卡住。但在实践中这个工作并不那么简单。
|
||||
两阶段提交被称为**阻塞（blocking）**原子提交协议，因为存在2PC可能卡住并等待协调者恢复的情况。理论上，可以使一个原子提交协议变为**非阻塞（nonblocking）**的，以便在节点失败时不会卡住。但是让这个协议能在实践中工作并没有那么简单。
|
||||
|
||||
作为2PC的替代方案，已经提出了一种称为三阶段提交（3PC）的算法【13,80】。然而，3PC假定一个有界延迟的网络和有限响应时间的节点；在大多数具有无限网络延迟和进程暂停的实际系统中（见[第8章](ch8.md)），它并不能保证原子性。
|
||||
作为2PC的替代方案，已经提出了一种称为**三阶段提交（3PC）**的算法【13,80】。然而，3PC假定网络延迟有界，节点响应时间有限；在大多数具有无限网络延迟和进程暂停的实际系统中（见[第8章](ch8.md)），它并不能保证原子性。
|
||||
|
||||
通常，非阻塞原子提交需要一个完美的故障检测器【67,71】—— 即一个可靠的机制来判断一个节点是否已经崩溃。在无限延迟的网络中，超时不是可靠的故障检测器，因为即使没有节点崩溃，请求也可能由于网络问题而超时。出于这个原因，2PC仍然被使用，尽管大家都清楚可能存在协调者故障的问题。
|
||||
通常，非阻塞原子提交需要一个**完美的故障检测器（perfect failure detector）**【67,71】—— 即一个可靠的机制来判断一个节点是否已经崩溃。在具有无限延迟的网络中，超时并不是一种可靠的故障检测机制，因为即使没有节点崩溃，请求也可能由于网络问题而超时。出于这个原因，2PC仍然被使用，尽管大家都清楚可能存在协调者故障的问题。
|
||||
|
||||
|
||||
|
||||
@ -678,7 +676,7 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
|
||||
|
||||
分布式事务，尤其是那些通过两阶段提交实现的事务，毁誉参半。一方面，它们被看作是提供一个难以实现的重要的安全保证;另一方面，他们被批评为造成运维问题，造成性能下降，承诺超过他们能够实现的目标【81,82,83,84】。许多云服务由于其导致的运维问题而选择不实现分布式事务【85,86】。
|
||||
|
||||
分布式事务的某些实现会带来严重的性能损失——例如，MySQL中的分布式事务被报告比单节点事务慢10倍以上【87】，所以当人们建议不要使用这些事务时就不足为奇了。两阶段提交所固有的大部分性能成本是由于崩溃恢复所需的额外强制刷盘（`fsync`）【88】以及额外的网络往返。
|
||||
分布式事务的某些实现会带来严重的性能损失—— 例如，MySQL中的分布式事务被报告比单节点事务慢10倍以上【87】，所以当人们建议不要使用这些事务时就不足为奇了。两阶段提交所固有的大部分性能成本是由于崩溃恢复所需的额外强制刷盘（`fsync`）【88】以及额外的网络往返。
|
||||
|
||||
但是，我们不应该直接抛弃分布式事务，而应该更加仔细地审视这些事务，因为从中可以汲取重要的经验教训。首先，我们应该精确地说明“**分布式事务**”的含义。两种截然不同的分布式事务类型经常被混淆：
|
||||
|
||||
@ -739,11 +737,11 @@ XA假定你的应用程序使用网络驱动程序或客户端库来与参与者
|
||||
XA事务解决了保持多个参与者数据系统一致的真实而重要的问题，但正如我们所看到的那样，它们也引入了主要的运维问题。特别是，关键的实现是事务协调者本身就是一种数据库（在其中存储事务结果），因此需要像其他重要数据库一样小心：
|
||||
|
||||
* 如果协调者没有被复制，而是只在一台机器上运行，那么整个系统是一个失效的单点（因为它的失效会导致其他应用程序服务器阻塞在有问题的事务处理的锁上）。令人惊讶的是，许多协调者实现默认情况下不是高度可用，或者只有基本的复制支持。
|
||||
* 许多服务器端应用程序都是在无状态模式下开发的（受到HTTP的青睐），所有持久状态都存储在数据库中，具有应用程序服务器可随意添加和删除的优点。但是，当协调者是应用程序服务器的一部分时，它会改变部署的性质。突然间，协调者的日志成为持久系统状态的关键部分——与数据库本身一样重要，因为协调者日志是为了在崩溃后恢复疑问事务所必需的。这样的应用程序服务器不再是无状态的。
|
||||
* 许多服务器端应用程序都是在无状态模式下开发的（受到HTTP的青睐），所有持久状态都存储在数据库中，具有应用程序服务器可随意添加和删除的优点。但是，当协调者是应用程序服务器的一部分时，它会改变部署的性质。突然间，协调者的日志成为持久系统状态的关键部分—— 与数据库本身一样重要，因为协调者日志是为了在崩溃后恢复疑问事务所必需的。这样的应用程序服务器不再是无状态的。
|
||||
* 由于XA需要与各种数据系统兼容，因此它是必须的最小公分母。例如，它不能检测到不同系统间的死锁（因为这将需要一个标准化的协议来让系统交换每个事务正在等待的锁的信息），而且它不适用于[SSI](ch7.md#可串行快照隔离（SSI） )，因为这需要一个协议来识别不同系统之间的冲突。
|
||||
* 对于数据库内部的分布式事务（而不是XA），限制不是很大，例如SSI的分布式版本是可能的。然而，仍然存在2PC成功进行事务的问题，所有参与者都必须作出回应。因此，如果系统的任何部分损坏，事务也会失败。因此，分布式事务有扩大故障的趋势，这与我们构建容错系统的目标背道而驰。
|
||||
|
||||
这些事实是否意味着我们应该放弃保持几个系统一致的所有希望？不完全是——有其他的方法可以让我们在没有异构分布式事务的痛苦的情况下实现同样的事情。我们将在[第十一章](ch11.md)和[第十二章](ch12.md)回到这些章节。但首先，我们应该总结共识的话题。
|
||||
这些事实是否意味着我们应该放弃保持几个系统一致的所有希望？不完全是——有其他的方法可以让我们在没有异构分布式事务的痛苦的情况下实现同样的事情。我们将在[第11章](ch11.md) 和[第12章](ch12.md) 回到这些章节。但首先，我们应该总结共识的话题。
|
||||
|
||||
|
||||
|
||||
@ -784,7 +782,7 @@ XA事务解决了保持多个参与者数据系统一致的真实而重要的问
|
||||
|
||||
因此，终止属性受到不到一半的节点崩溃或不可达的假设。然而，即使大多数节点出现故障或存在严重的网络问题，大多数共识的实施都能确保始终满足安全属性——同意，完整性和有效性【92】。因此，大规模的中断可能会阻止系统处理请求，但是它不能通过使系统做出无效的决定来破坏共识系统。
|
||||
|
||||
大多数一致性算法假定没有**拜占庭式错误**，正如在“[拜占庭式错误](#拜占庭式错误)”一节中所讨论的那样。也就是说，如果一个节点没有正确地遵循协议（例如，如果它发送矛盾的消息到不同的节点），它可能会破坏协议的安全属性。只要少于三分之一的节点是拜占庭故障【25,93】，就可以对拜占庭故障形成共识，但我们没有地方在本书中详细讨论这些算法。
|
||||
大多数一致性算法假定没有**拜占庭式错误**，正如在“[拜占庭式错误](#拜占庭式错误)”一节中所讨论的那样。也就是说，如果一个节点没有正确地遵循协议（例如，如果它发送矛盾的消息到不同的节点），它可能会破坏协议的安全属性。只要少于三分之一的节点是拜占庭故障【25,93】，就可以对拜占庭故障达成共识，但我们没有地方在本书中详细讨论这些算法。
|
||||
|
||||
#### 共识算法和全序广播
|
||||
|
||||
@ -792,7 +790,7 @@ XA事务解决了保持多个参与者数据系统一致的真实而重要的问
|
||||
|
||||
这些算法中的大多数实际上并不直接使用这里描述的形式化模型（建议和决定单个值，一致同意，完整性，有效性和终止性质）。相反，它们决定了值的顺序，这使得它们成为了全序广播算法，正如本章前面所讨论的那样（参阅“[全序广播](#全序广播)”）。
|
||||
|
||||
请记住，全序广播要求将消息按照相同的顺序准确传送到所有节点。如果仔细思考，这相当于进行了几轮的共识：在每一轮中，节点提出下一个要发送的消息，然后决定下一个要发送的消息总数【67】。
|
||||
请记住，全序广播要求将消息按照相同的顺序准确传送到所有节点。如果仔细思考，这相当于进行了几轮共识：在每一轮中，节点提出下一个要发送的消息，然后决定下一个要发送的消息总数【67】。
|
||||
|
||||
所以，全序广播相当于重复的一轮共识（每个共同的决定对应于一个消息传递）：
|
||||
|
||||
@ -809,7 +807,7 @@ XA事务解决了保持多个参与者数据系统一致的真实而重要的问
|
||||
|
||||
在[第5章](ch5.md)中，我们讨论了单领导者复制（参见“[领导者和追随者](ch5.md#领导者和追随者)”），它将所有的写入操作都交给领导者，并以相同的顺序将他们应用到追随者，从而使副本保持最新状态。这不是基本上全序广播？我们怎么不用担心[第五章](ch5.md)的共识？
|
||||
|
||||
答案取决于如何选择领导者。如果领导人是由你的运营团队中的人员手动选择和配置的，那么你基本上拥有独裁种类的“一致性算法”：只允许一个节点接受写入（即，决定写入的顺序复制日志），如果该节点发生故障，则系统将无法写入，直到运维手动配置其他节点作为主管。这样的制度在实践中可以很好地发挥作用，但是不能达到共识的终止属性，因为它需要人为干预才能取得进展。
|
||||
答案取决于如何选择领导者。如果领导人是由你的运维团队人员手动选择和配置的，那么你基本上拥有独裁类型的“一致性算法”：只允许一个节点接受写入（即，决定写入的顺序复制日志），如果该节点发生故障，则系统将无法写入，直到运维手动配置其他节点作为领导者。这样的制度在实践中效果很好，但是无法达到共识的**终止**属性，因为它需要人为干预才能取得进展。
|
||||
|
||||
一些数据库执行自动领导者选举和故障转移，如果旧领导者失败，则促使追随者成为新的领导者（参见“[处理节点宕机](ch5.md#处理节点宕机)”）。这使我们更接近容错的全面命令播出，从而达成共识。
|
||||
|
||||
@ -839,13 +837,13 @@ XA事务解决了保持多个参与者数据系统一致的真实而重要的问
|
||||
|
||||
节点在决定之前对节点进行投票的过程是一种同步复制。如“[同步与异步复制](ch5.md#同步与异步复制)”中所述，通常将数据库配置为使用异步复制。在这种配置中，一些承诺的数据在故障转移时可能会丢失——但是为了获得更好的性能，许多人选择接受这种风险。
|
||||
|
||||
共识体系总是需要严格的多数来操作。这意味着你至少需要三个节点才能容忍一个故障（其余三个为大多数），或者至少有五个节点容忍两个故障（其余三个为五分之一）。如果网络故障切断了其余节点的某些节点，则只有大部分网络可以继续工作，其余部分将被阻塞（另参阅“[线性一致性的代价](#线性一致性的代价)”（第295页））。
|
||||
共识体系总是需要严格多数来运转。这意味着你至少需要三个节点才能容忍单节点故障（其余三个为大多数），或者至少有五个节点来容忍两个节点发生故障（其余三个为五分之一）。如果网络故障切断了其余节点的某些节点，则只有大部分网络可以继续工作，其余部分将被阻塞（另参阅“[线性一致性的代价](#线性一致性的代价)”）。
|
||||
|
||||
大多数一致性算法假定一组参与投票的节点，这意味着你不能只添加或删除集群中的节点。对共识算法的动态成员扩展允许集群中的节点集随着时间的推移而变化，但是它们比静态成员算法要好得多。
|
||||
|
||||
共识系统通常依靠超时来检测失败的节点。在网络延迟高度变化的环境中，特别是在地理上分布的系统中，经常发生一个节点错误地认为由于暂时的网络问题，导致失败的原因。虽然这个错误不会损害安全属性，但频繁的领导者选举会导致糟糕的表现，因为系统最终会花费更多的时间来选择领导者而不是做任何有用的工作。
|
||||
|
||||
有时，共识算法对网络问题特别敏感。例如，Raft已被证明有不愉快的边缘情况【106】：如果整个网络工作正常，除了一个特定的网络连接一直不可靠，Raft可以进入领导层不断在两个节点之间弹跳的情况，或者目前的领导者不断被迫辞职，所以这个制度从来没有取得进展。其他一致性算法也存在类似的问题，而对不可靠网络更具鲁棒性的设计算法仍然是一个开放的研究问题。
|
||||
有时共识算法对网络问题特别敏感。例如Raft已被证明存在不愉快的边缘情况【106】：如果整个网络工作正常，除了一个特定的网络连接一直不可靠，Raft可以进入领导层不断在两个节点之间弹跳的情况，或者目前的领导者不断被迫辞职，所以这个制度从来没有取得进展。其他一致性算法也存在类似的问题，而对不可靠网络更具鲁棒性的设计算法仍然是一个开放的研究问题。
|
||||
|
||||
### 成员与协调服务
|
||||
|
||||
@ -859,7 +857,7 @@ ZooKeeper模仿Google的Chubby锁定服务【14,98】，不仅实现了全序广
|
||||
|
||||
***线性一致性的原子操作***
|
||||
|
||||
使用原子比较和设置操作，可以实现锁定：如果多个节点同时尝试执行相同的操作，则只有其中一个节点会成功。共识协议保证了操作将是原子性和线性一致性的，即使节点发生故障或网络在任何时候都被中断。分布式锁通常作为一个租约来实现，这个租约有一个到期时间，以便在客户端失败的情况下最终被释放（参阅“[进程暂停](ch8.md#进程暂停)”）。
|
||||
使用原子CAS操作可以实现锁：如果多个节点同时尝试执行相同的操作，则只有一个节点会成功。共识协议保证了操作的原子性和线性一致性，即使节点发生故障或网络在任意时刻中断。分布式锁通常作为一个租约来实现，这个租约有一个到期时间，以便在客户端失败的情况下最终被释放（参阅“[进程暂停](ch8.md#进程暂停)”）。
|
||||
|
||||
***操作的全序***
|
||||
|
||||
@ -883,11 +881,11 @@ ZooKeeper/Chubby模型运行良好的一个例子是，如果你有几个流程
|
||||
|
||||
另一个例子是，当你有一些分区资源（数据库，消息流，文件存储，分布式参与者系统等），并需要决定将哪个分区分配给哪个节点时。当新节点加入群集时，需要将某些分区从现有节点移动到新节点，以便重新平衡负载（参阅“[重新平衡分区](ch6.md#重新平衡分区)”）。当节点被移除或失败时，其他节点需要接管失败节点的工作。
|
||||
|
||||
这些类型的任务可以通过在ZooKeeper中明智地使用原子操作，各种节点和通知来实现。如果正确完成，这种方法允许应用程序自动从故障中恢复，无需人工干预。尽管Apache Curator 【17】等库已经出现在ZooKeeper客户端API的顶层提供了更高级别的工具，但这样做并不容易，但它仍然比尝试从头开始实现必要的一致性算法要好得多，成绩不佳【107】。
|
||||
这些类型的任务可以通过在ZooKeeper中明智地使用原子操作，各种节点和通知来实现。如果正确完成，这种方法允许应用程序自动从故障中恢复，无需人工干预。尽管Apache Curator 【17】等库已经出现在ZooKeeper客户端API的顶层提供了更高层的工具，但这样做并不容易，但它仍然比尝试从头开始实现必要的一致性算法要好得多，成绩不佳【107】。
|
||||
|
||||
应用最初只能在单个节点上运行，但最终可能会增长到数千个节点。试图在如此之多的节点上进行多数选票将是非常低效的。相反，ZooKeeper在固定数量的节点（通常是三到五个）上运行，并在这些节点之间执行其多数票，同时支持潜在的大量客户端。因此，ZooKeeper提供了一种将协调节点（共识，操作排序和故障检测）的一些工作“外包”到外部服务的方式。
|
||||
应用最初只能在单个节点上运行，但最终可能会增长到数千个节点。试图在如此之多的节点上进行多数投票将是非常低效的。相反，ZooKeeper在固定数量的节点（通常是三到五个）上运行，并在这些节点之间执行其多数票，同时支持潜在的大量客户端。因此，ZooKeeper提供了一种将协调节点（共识，操作排序和故障检测）的一些工作“外包”到外部服务的方式。
|
||||
|
||||
通常，由ZooKeeper管理的数据的类型变化十分缓慢：代表“分区7中的节点运行在`10.1.1.23`上”的信息可能会在几分钟或几小时的时间内发生变化。它不是用来存储应用程序的运行时状态的，每秒可能会改变数千甚至数百万次。如果应用程序状态需要从一个节点复制到另一个节点，则可以使用其他工具（如Apache BookKeeper 【108】）。
|
||||
通常，由ZooKeeper管理的数据的类型变化十分缓慢：代表“分区 7 中的节点运行在 `10.1.1.23` 上”的信息可能会在几分钟或几小时的时间内发生变化。它不是用来存储应用程序的运行时状态的，每秒可能会改变数千甚至数百万次。如果应用程序状态需要从一个节点复制到另一个节点，则可以使用其他工具（如Apache BookKeeper 【108】）。
|
||||
|
||||
#### 服务发现
|
||||
|
||||
@ -903,7 +901,7 @@ ZooKeeper和它的小伙伴们可以看作是成员服务研究的悠久历史
|
||||
|
||||
成员资格服务确定哪些节点当前处于活动状态并且是群集的活动成员。正如我们在[第8章](ch8.md)中看到的那样，由于无限的网络延迟，无法可靠地检测到另一个节点是否发生故障。但是，如果你通过一致的方式进行故障检测，那么节点可以就哪些节点应该被认为是存在或不存在达成一致。
|
||||
|
||||
即使它确实存在，仍然可能发生一个节点被错误地宣布死于共识。但是对于一个系统来说，在哪些节点构成当前的成员关系方面是非常有用的。例如，选择领导者可能意味着简单地选择当前成员中编号最小的成员，但如果不同的节点对现有成员的成员有不同意见，则这种方法将不起作用。
|
||||
即使它确实存在，仍然可能发生一个节点被共识错误地宣告死亡。但是对于一个系统来说，在哪些节点构成当前的成员关系方面是非常有用的。例如，选择领导者可能意味着简单地选择当前成员中编号最小的成员，但如果不同的节点对现有成员的成员有不同意见，则这种方法将不起作用。
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 107 KiB After Width: | Height: | Size: 106 KiB |
Loading…
Reference in New Issue
Block a user