fix: typo

ch1.md

@@ -384,7 +384,7 @@
 
 **可维护性（Maintainability）**有许多方面，但实质上是关于工程师和运维团队的生活质量的。良好的抽象可以帮助降低复杂度，并使系统易于修改和适应新的应用场景。良好的可操作性意味着对系统的健康状态具有良好的可见性，并拥有有效的管理手段。
 
-不幸的是，使应用可靠、可扩展或可持续并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
+不幸的是，使应用可靠、可扩展或可维护并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
 
 在本书后面的[第三部分](part-iii.md)中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（如[图1-1](img/fig1-1.png)中的例子）
 

ch12.md

@@ -18,7 +18,7 @@
 
 ## 数据集成
 
-本书中反复出现的主题是，对于任何给定的问题，都有几种解决方案，所有这些解决方案都有不同的优点，缺点和折衷。例如，在[第3章](ch3.md)讨论存储引擎时，我们看到了日志结构存储，B树和列式存储。在[第5章](ch5.md)讨论复制时，我们看到了单领导，多领导和无领导的方法。
+本书中反复出现的主题是，对于任何给定的问题，都有几种解决方案，所有这些解决方案都有不同的优点，缺点和折衷。例如，在[第3章](ch3.md)讨论存储引擎时，我们看到了日志结构存储，B树和列存储。在[第5章](ch5.md)讨论复制时，我们看到了单领导，多领导和无领导的方法。
 
 如果你有一个问题，例如“我想存储一些数据并稍后再查询”，那么没有一个正确的解决方案，但是在不同的情况下，每种方法都是适当的。软件实现通常必须选择一种特定的方法。要使一个代码路径健壮并且很好地尝试在一个软件中执行所有操作几乎可以保证实现效果很差，这很难。
 

ch5.md

@@ -199,7 +199,7 @@ PostgreSQL和Oracle等使用这种复制方法【16】。主要缺点是日志
 
 因为滞后时间太长引入的不一致性，可不仅是一个理论问题，更是应用设计中会遇到的真实问题。本节将重点介绍三个由复制延迟问题的例子，并简述解决这些问题的一些方法。
 
-### 读已之写
+### 读己之写
 
 许多应用程序让用户提交一些数据，然后查看他们提交的内容。可能是用户数据库中的记录，也可能是对讨论主题的评论，或其他类似的内容。提交新数据时，必须将其发送给领导者，但是当用户查看数据时，可以从追随者读取。如果数据经常被查看，但只是偶尔写入，这是非常合适的。
 

ch8.md

@@ -18,7 +18,7 @@
 
 最近几章中反复出现的主题是，系统如何处理错误的事情。例如，我们讨论了**副本故障转移**（“[处理节点中断](#ch5.md#处理节点宕机)”），**复制延迟**（“[复制延迟问题](ch6.md#复制延迟问题)”）和事务控制（“[弱隔离级别](ch7.md#弱隔离级别)”）。当我们了解可能在实际系统中出现的各种边缘情况时，我们会更好地处理它们。
 
-但是，尽管我们已经谈了很多错误，但最后几章仍然过于乐观。现实更加黑暗。我们现在将悲观主义最大化，假设任何可能出错的东西**都会**出错[^i]。（经验丰富的系统运维会告诉你，这是一个合理的假设。如果你问得好，他们可能会一边治疗心理创伤一边告诉你一些可怕的故事）
+但是，尽管我们已经谈了很多错误，但之前几章仍然过于乐观。现实更加黑暗。我们现在将悲观主义最大化，假设任何可能出错的东西**都会**出错[^i]。（经验丰富的系统运维会告诉你，这是一个合理的假设。如果你问得好，他们可能会一边治疗心理创伤一边告诉你一些可怕的故事）
 
 [^i]: 除了一个例外：我们将假定故障是非拜占庭式的（参见“[拜占庭故障](#拜占庭故障)”）。
 

ch9.md

@@ -35,7 +35,7 @@
 
 大多数复制的数据库至少提供了**最终一致性**，这意味着如果你停止向数据库写入数据并等待一段不确定的时间，那么最终所有的读取请求都会返回相同的值【1】。换句话说，不一致性是暂时的，最终会自行解决（假设网络中的任何故障最终都会被修复）。最终一致性的一个更好的名字可能是**收敛（convergence）**，因为我们预计所有的复本最终会收敛到相同的值【2】。
 
-然而，这是一个非常弱的保证——它并没有说什么什么时候副本会收敛。在收敛之前，读操作可能会返回任何东西或什么都没有【1】。例如，如果你写入了一个值，然后立即再次读取，这并不能保证你能看到刚跟写入的值，因为读请求可能会被路由到另外的副本上。（参阅“[读己之写](ch5.md#读己之写)” ）。
+然而，这是一个非常弱的保证 —— 它并没有说什么什么时候副本会收敛。在收敛之前，读操作可能会返回任何东西或什么都没有【1】。例如，如果你写入了一个值，然后立即再次读取，这并不能保证你能看到刚跟写入的值，因为读请求可能会被路由到另外的副本上。（参阅“[读己之写](ch5.md#读己之写)” ）。
 
 对于应用程序开发人员而言，最终一致性是很困难的，因为它与普通单线程程序中变量的行为有很大区别。如果将一个值赋给一个变量，然后很快地再次读取，你不会认为可能读到旧的值，或者读取失败。数据库表面上看起来像一个你可以读写的变量，但实际上它有更复杂的语义【3】。
 
@@ -114,7 +114,7 @@
 
 在[图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≠v_{old}$ ，则操作应该保持寄存器不变并返回一个错误。 $r$ 是数据库的响应（正确或错误）。
 
 [图9-4]()中的每个操作都在我们认为执行操作的时候用竖线标出（在每个操作的条柱之内）。这些标记按顺序连在一起，其结果必须是一个有效的寄存器读写序列（**每次读取都必须返回最近一次写入设置的值**）。
 
@@ -216,7 +216,7 @@
 
 ***共识算法（线性一致）***
 
-一些在本章后面讨论的共识算法，与单领导者复制类似。然而，共识协议包含防止脑裂和陈旧副本的措施。由于这些细节，协调算法可以安全地实现线性一致性存储。例如，Zookeeper 【21】和etcd 【22】就是这样工作的。
+一些在本章后面讨论的共识算法，与单领导者复制类似。然而，共识协议包含防止脑裂和陈旧副本的措施。由于这些细节，共识算法可以安全地实现线性一致性存储。例如，Zookeeper 【21】和etcd 【22】就是这样工作的。
 
 ***多主复制（非线性一致）***
 
@@ -252,7 +252,7 @@
 
 一些复制方法可以提供线性一致性，另一些复制方法则不能，因此深入地探讨线性一致性的优缺点是很有趣的。
 
-我们已经在[第五章中讨论了不同复制方法的一些用例。例如对多数据中心的复制而言，多主复制通常是理想的选择（参阅“[运维多个数据中心](ch5.md#运维多个数据中心)”）。[图9-7](img/fig9-7.png)说明了这种部署的一个例子。
+我们已经在[第五章](ch5.md)中讨论了不同复制方法的一些用例。例如对多数据中心的复制而言，多主复制通常是理想的选择（参阅“[运维多个数据中心](ch5.md#运维多个数据中心)”）。[图9-7](img/fig9-7.png)说明了这种部署的一个例子。
 
 ![](img/fig9-7.png)
 
@@ -358,7 +358,7 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
 
 因此，根据这个定义，在线性一致的数据存储中是不存在并发操作的：必须有且仅有一条时间线，所有的操作都在这条时间线上，构成一个全序关系。可能有几个请求在等待处理，但是数据存储确保了每个请求都是在唯一时间线上的某个时间点自动处理的，不存在任何并发。
 
-并发意味着时间线会分岔然后合并——在这种情况下，不同分支上的操作是无法比较的（即并发操作）。在[第五章](ch5.md)中我们看到了这种现象：例如，[图5-14](img/fig5-14.md) 并不是一条直线的全序关系，而是一堆不同的操作并发进行。图中的箭头指明了因果依赖——操作的偏序。
+并发意味着时间线会分岔然后合并 —— 在这种情况下，不同分支上的操作是无法比较的（即并发操作）。在[第五章](ch5.md)中我们看到了这种现象：例如，[图5-14](img/fig5-14.md) 并不是一条直线的全序关系，而是一堆不同的操作并发进行。图中的箭头指明了因果依赖 —— 操作的偏序。
 
 如果你熟悉像Git这样的分布式版本控制系统，那么其版本历史与因果关系图极其相似。通常，一个**提交（Commit）**发生在另一个提交之后，在一条直线上。但是有时你会遇到分支（当多个人同时在一个项目上工作时），**合并（Merge）**会在这些并发创建的提交相融合时创建。
 
@@ -450,7 +450,7 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
 
 虽然兰伯特时间戳定义了一个与因果一致的全序，但它还不足以解决分布式系统中的许多常见问题。
 
-例如，考虑一个需要确保用户名能唯一标识用户帐户的系统。如果两个用户同时尝试使用相同的用户名创建帐户，则其中一个应该成功，另一个应该失败。 （我们之前在“[领导者与锁定]](ch8.md#领导者与锁定)”中提到过这个问题。）
+例如，考虑一个需要确保用户名能唯一标识用户帐户的系统。如果两个用户同时尝试使用相同的用户名创建帐户，则其中一个应该成功，另一个应该失败。 （我们之前在“[领导者与锁定](ch8.md#领导者与锁定)”中提到过这个问题。）
 
 乍看之下，似乎操作的全序关系足以解决这一问题（例如使用兰伯特时间戳）：如果创建了两个具有相同用户名的帐户，选择时间戳较小的那个作为胜者（第一个抓到用户名的人），并让带有更大时间戳者失败。由于时间戳上有全序关系，所以这个比较总是可行的。
 
@@ -538,7 +538,7 @@ CAP定理的正式定义仅限于很狭隘的范围【30】，它只考虑了一
 
 该算法很简单：每个要通过全序广播发送的消息首先对线性一致寄存器执行**自增并返回**操作。然后将从寄存器获得的值作为序列号附加到消息中。然后你可以将消息发送到所有节点（重新发送任何丢失的消息），而收件人将按序列号连续发送消息。
 
-请注意，与兰伯特时间戳不同，通过自增线性一致性寄存器获得的数字形式上是一个没有间隙的序列。因此，如果一个节点已经发送了消息 4 并且接收到序列号为 6 的传入消息，则它知道它在传递消息 6 之前必须等待消息 5 。兰伯特时间戳则与之不同 ——事实上，这是全序广播和时间戳排序间的关键区别。
+请注意，与兰伯特时间戳不同，通过自增线性一致性寄存器获得的数字形式上是一个没有间隙的序列。因此，如果一个节点已经发送了消息 4 并且接收到序列号为 6 的传入消息，则它知道它在传递消息 6 之前必须等待消息 5 。兰伯特时间戳则与之不同 —— 事实上，这是全序广播和时间戳排序间的关键区别。
 
 实现一个带有原子性**自增并返回**操作的线性一致寄存器有多困难？像往常一样，如果事情从来不出差错，那很容易：你可以简单地把它保存在单个节点内的变量中。问题在于处理当该节点的网络连接中断时的情况，并在该节点失效时能恢复这个值【59】。一般来说，如果你对线性一致性的序列号生成器进行深入过足够深入的思考，你不可避免地会得出一个共识算法。