DDIA第七章格式修复

ddia/ch5.md

@@ -90,7 +90,7 @@
 
 建立跟随者的实际步骤因数据库而异。在某些系统中，这个过程是完全自动化的，而在另外一些系统中，它可能是一个有点神秘的多步骤工作流程，需要由管理员手动执行。
 
-### 处理节点停机
+### 处理节点宕机
 
 系统中的任何节点都可能停机，也许因为意外的故障，也可能是计划内的维护（例如，重启机器以安装内核安全补丁）。对运维而言，能在系统不中断服务的情况下重启单个节点好处多多。我们的目标是，即使个别节点失效，也能保持整个系统运行，并尽可能控制节点停机带来的影响。
 
@@ -213,7 +213,7 @@ PostgreSQL和Oracle等使用这种复制方法[16]。主要缺点是日志记录
 
 **图5-3 用户写入后从旧副本中读取数据。需要写后读(read-after-write)的一致性来防止这种异常**
 
-在这种情况下，我们需要**写后读一致性（read-after-write consistency）**，也称为**读己之写一致性（read-your-writes consistency）**[24]。这是一个保证，如果用户重新加载页面，他们总会看到他们自己提交的任何更新。它不会对其他用户的写入做出承诺：其他用户的更新可能稍等才会看到。它保证用户自己的输入已被正确保存。
+在这种情况下，我们需要**读写一致性（read-after-write consistency）**，也称为**读己之写一致性（read-your-writes consistency）**[24]。这是一个保证，如果用户重新加载页面，他们总会看到他们自己提交的任何更新。它不会对其他用户的写入做出承诺：其他用户的更新可能稍等才会看到。它保证用户自己的输入已被正确保存。
 
 如何在基于领导者的复制系统中实现读后一致性？有各种可能的技术，这里说一些：
 

ddia/ch9.md

@@ -217,13 +217,13 @@
 
 一些共识算法，我们将在本章后面讨论，与单引导者复制相似。然而，共识协议包含措施，以防止裂脑和陈旧的复制品。由于这些细节，协调算法可以安全地实现线性化存储。例如，Zoo-Keeper [21]和etcd [22]就是这样工作的。
 
-***多领导复制（不可线性化）***
+***多主复制（不可线性化）***
 
 具有多引导程序复制的系统通常不是线性化的，因为它们同时在多个节点上处理写入，并将其异步复制到其他节点。由于这个原因，它们可能会产生冲突的写入，需要解析（请参阅第171页的“处理写入冲突”）。这种冲突是缺乏单一数据副本的人为因素。
 
-***无领导复制（可能不是线性化的）***
+***无主复制（可能不是线性化的）***
 
-对于无领导者复制的系统（Dynamo风格;请参阅第177页的“无领导者复制”），有时候人们会声称通过要求法定读写（w + r> n）可以获得“强一致性”。根据法定人数的确切配置，取决于您如何界定强一致性，这是不正确的。
+对于无领导者复制的系统（Dynamo风格;请参阅第177页的“无主复制”），有时候人们会声称通过要求法定读写（w + r> n）可以获得“强一致性”。根据法定人数的确切配置，取决于您如何界定强一致性，这是不正确的。
 
 基于时钟（例如，在Cassandra中;参见第291页上的“依赖于同步时钟”）的“最后写入胜利”冲突解决方法几乎是非线性的，因为时钟时间戳不能保证与时间戳一致由于时钟歪斜而导致的实际事件排序。不规范的法定人数（第183页的“马虎法定人数和暗示交接”）也破坏了线性化的可能性。即使是严格的法定人数，非线性行为也是可能的，如下一节所示。
 
@@ -280,7 +280,9 @@ CAP最初是作为一个经验法则提出的，没有准确的定义，目的
 
 > ### CAP定理没有帮助
 >
-> CAP有时表现为一致性，可用性和分区容忍度：从3中挑选出2个。不幸的是，这样做是误导的[32]，因为网络分区是一种错误，所以它们不是你所拥有的一个选择：他们会发生，不管你喜欢还是不喜欢[38]。
+> CAP有时以这种面目出现：一致性，可用性和分区容忍：三者只能择其二。
+>
+> 个中只能选择从3中挑选出2个。不幸的是，这样做是误导的[32]，因为网络分区是一种错误，所以它们不是你所拥有的一个选择：他们会发生，不管你喜欢还是不喜欢[38]。
 >
 > 在网络正常工作的时候，系统可以提供一致性（线性化）和总体可用性。发生网络故障时，您必须选择线性或总可用性。因此，一个更好的表达CAP的方法可以是一致的，或者在分区时可用[39]。一个更可靠的网络需要减少这个选择，但是在某些时候选择是不可避免的。
 >
@@ -953,9 +955,7 @@ ZooKeeper和朋友们可以看作是成员服务研究的悠久历史的一部
     “[Eventual Consistency Today: Limitations, Extensions, and Beyond](http://queue.acm.org/detail.cfm?id=2462076),” *ACM Queue*, volume 11, number 3, pages 55-63, March 2013.
     [doi:10.1145/2460276.2462076](http://dx.doi.org/10.1145/2460276.2462076)
 
-1.  Prince Mahajan, Lorenzo Alvisi, and Mike Dahlin:
-    “[Consistency, Availability, and Convergence](http://apps.cs.utexas.edu/tech_reports/reports/tr/TR-2036.pdf),” University of Texas at Austin, Department of Computer
-    Science, Tech Report UTCS TR-11-22, May 2011.
+1.  Prince Mahajan, Lorenzo Alvisi, and Mike Dahlin: “[Consistency, Availability, and Convergence](http://apps.cs.utexas.edu/tech_reports/reports/tr/TR-2036.pdf),” University of Texas at Austin, Department of Computer Science, Tech Report UTCS TR-11-22, May 2011.
 
 1.  Alex Scotti:
     “[Adventures in Building Your Own Database](http://www.slideshare.net/AlexScotti1/allyourbase-55212398),” at *All Your Base*, November 2015.
@@ -1108,9 +1108,7 @@ ZooKeeper和朋友们可以看作是成员服务研究的悠久历史的一部
     [doi:10.1145/72981.72982](http://dx.doi.org/10.1145/72981.72982)
 
 1.  Hagit Attiya, Faith Ellen, and Adam Morrison:
-    “[Limitations of Highly-Available Eventually-Consistent Data Stores](http://www.cs.technion.ac.il/people/mad/online-publications/podc2015-replds.pdf),” at *ACM Symposium on Principles of
-    Distributed Computing* (PODC), July 2015.
-    [doi:10.1145/2767386.2767419](http://dx.doi.org/10.1145/2767386.2767419)
+    “[Limitations of Highly-Available Eventually-Consistent Data Stores](http://www.cs.technion.ac.il/people/mad/online-publications/podc2015-replds.pdf),” at *ACM Symposium on Principles of Distributed Computing* (PODC), July 2015. [doi:10.1145/2767386.2767419](http://dx.doi.org/10.1145/2767386.2767419)
 
 1.  Peter Sewell, Susmit Sarkar,
     Scott Owens, et al.: