Merge branch 'master' of https://github.com/Vonng/ddia

ch5.md

@@ -381,7 +381,7 @@
 
 单主数据库按顺序进行写操作：如果同一个字段有多个更新，则最后一个写操作将决定该字段的最终值。
 
-在多主配置中，没有明确的写入顺序，所以最终值应该是什么并不清楚。在 [图 5-7](img/fig5-7.png) 中，在主库 1 中标题首先更新为 B 而后更新为 C；在主库 2 中，首先更新为 C，然后更新为 B。两个顺序都不是 “更正确” 的。
+在多主配置中，没有明确的写入顺序，所以最终值应该是什么并不清楚。在 [图 5-7](img/fig5-7.png) 中，在主库 1 中标题首先更新为 B 而后更新为 C；在主库 2 中，首先更新为 C，然后更新为 B。两种顺序都不比另一种“更正确”。
 
 如果每个副本只是按照它看到写入的顺序写入，那么数据库最终将处于不一致的状态：最终值将是在主库 1 的 C 和主库 2 的 B。这是不可接受的，每个复制方案都必须确保数据在所有副本中最终都是相同的。因此，数据库必须以一种 **收敛（convergent）** 的方式解决冲突，这意味着所有副本必须在所有变更复制完成时收敛至一个相同的最终值。
 
@@ -410,9 +410,9 @@
 
 > #### 自动冲突解决
 >
-> 冲突解决规则可能很快变得复杂，并且自定义代码可能容易出错。亚马逊是一个经常被引用的例子，由于冲突解决处理程序令人意外的效果：一段时间以来，购物车上的冲突解决逻辑将保留添加到购物车的物品，但不包括从购物车中移除的物品。因此，顾客有时会看到物品重新出现在他们的购物车中，即使他们之前已经被移走【37】。
+> 冲突解决规则可能很快变得复杂，并且自定义代码可能容易出错。亚马逊是一个经常被引用的例子，由于冲突解决处理程序而产生令人意外的效果：一段时间以来，购物车上的冲突解决逻辑将保留添加到购物车的物品，但不包括从购物车中移除的物品。因此，顾客有时会看到物品重新出现在他们的购物车中，即使他们之前已经被移走【37】。
 >
-> 已经有一些有趣的研究来自动解决由于数据修改引起的冲突。有几行研究值得一提：
+> 已经有一些有趣的研究来自动解决由于数据修改引起的冲突。有几项研究值得一提：
 >
 > * **无冲突复制数据类型（Conflict-free replicated datatypes，CRDT）**【32,38】是可以由多个用户同时编辑的集合，映射，有序列表，计数器等的一系列数据结构，它们以合理的方式自动解决冲突。一些 CRDT 已经在 Riak 2.0 中实现【39,40】。
 > * **可合并的持久数据结构（Mergeable persistent data structures）**【41】显式跟踪历史记录，类似于 Git 版本控制系统，并使用三向合并功能（而 CRDT 使用双向合并）。
@@ -443,7 +443,7 @@
 
 [^v]: 不要与星型模式混淆（请参阅 “[星型和雪花型：分析的模式](ch3.md#星型和雪花型：分析的模式)”），其中描述了数据模型的结构，而不是节点之间的通信拓扑。
 
-在环形和星形拓扑中，写入可能需要在到达所有副本之前通过多个节点。因此，节点需要转发从其他节点收到的数据更改。为了防止无限复制循环，每个节点被赋予一个唯一的标识符，并且在复制日志中，每个写入都被标记了所有已经过的节点的标识符【43】。当一个节点收到用自己的标识符标记的数据更改时，该数据更改将被忽略，因为节点知道它已经被处理过。
+在环形和星形拓扑中，写入可能需要在到达所有副本之前通过多个节点。因此，节点需要转发从其他节点收到的数据更改。为了防止无限复制循环，每个节点被赋予一个唯一的标识符，并且在复制日志中，每次写入都会使用其经过的所有节点的标识符进行标记【43】。当一个节点收到用自己的标识符标记的数据更改时，该数据更改将被忽略，因为节点知道它已经被处理过。
 
 环形和星形拓扑的问题是，如果只有一个节点发生故障，则可能会中断其他节点之间的复制消息流，导致它们无法通信，直到节点修复。拓扑结构可以重新配置为在发生故障的节点上工作，但在大多数部署中，这种重新配置必须手动完成。更密集连接的拓扑结构（例如全部到全部）的容错性更好，因为它允许消息沿着不同的路径传播，避免单点故障。
 
@@ -476,7 +476,7 @@
 
 假设你有一个带有三个副本的数据库，而其中一个副本目前不可用，或许正在重新启动以安装系统更新。在基于主机的配置中，如果要继续处理写入，则可能需要执行故障切换（请参阅「[处理节点宕机](#处理节点宕机)」）。
 
-另一方面，在无领导配置中，故障切换不存在。[图 5-10](img/fig5-10.png) 显示了发生了什么事情：客户端（用户 1234）并行发送写入到所有三个副本，并且两个可用副本接受写入，但是不可用副本错过了它。假设三个副本中的两个承认写入是足够的：在用户 1234 已经收到两个确定的响应之后，我们认为写入成功。客户简单地忽略了其中一个副本错过了写入的事实。
+另一方面，在无领导配置中，不存在故障转移。[图 5-10](img/fig5-10.png) 显示了发生了什么事情：客户端（用户 1234）并行发送写入到所有三个副本，并且两个可用副本接受写入，但是不可用副本错过了它。假设三个副本中的两个承认写入是足够的：在用户 1234 已经收到两个确定的响应之后，我们认为写入成功。客户简单地忽略了其中一个副本错过了写入的事实。
 
 ![](img/fig5-10.png)