Merge pull request #100 from LiminCode/master

fix missing translation

ch10.md

@@ -153,7 +153,7 @@ top5.each{|count, url| puts "#{count} #{url}" }                   # 5
 
 ​	在Unix中，这种接口是一个**文件（file）**（更准确地说，是一个文件描述符）。一个文件只是一串有序的字节序列。因为这是一个非常简单的接口，所以可以使用相同的接口来表示许多不同的东西：文件系统上的真实文件，到另一个进程（Unix套接字，stdin，stdout）的通信通道，设备驱动程序（比如`/dev/audio`或`/dev/lp0`），表示TCP连接的套接字等等。很容易将这些设计视为理所当然的，但实际上能让这些差异巨大的东西共享一个统一的接口是非常厉害的，这使得它们可以很容易地连接在一起[^ii]。
 
-[^ii]: 统一接口的另一个例子是URL和HTTP，这是Web的基石。 一个URL标识一个网站上的一个特定的东西（资源），你可以链接到任何其他网站的任何网址。 具有网络浏览器的用户因此可以通过跟随链接在网站之间无缝跳转，即使服务器可能由完全不相关的组织维护。 这个原则现在似乎非常明显，但它却是网络取能取得今天成就的关键。 之前的系统并不是那么统一：例如，在公告板系统（BBS）时代，每个系统都有自己的电话号码和波特率配置。 从一个BBS到另一个BBS的引用必须以电话号码和调制解调器设置的形式；用户将不得不挂断，拨打其他BBS，然后手动找到他们正在寻找的信息。 这是不可能的直接链接到另一个BBS内的一些内容。
+[^ii]: 统一接口的另一个例子是URL和HTTP，这是Web的基石。 一个URL标识一个网站上的一个特定的东西（资源），你可以链接到任何其他网站的任何网址。 具有网络浏览器的用户因此可以通过跟随链接在网站之间无缝跳转，即使服务器可能由完全不相关的组织维护。 这个原则现在似乎非常明显，但它却是网络取能取得今天成就的关键。 之前的系统并不是那么统一：例如，在公告板系统（BBS）时代，每个系统都有自己的电话号码和波特率配置。 从一个BBS到另一个BBS的引用必须以电话号码和调制解调器设置的形式；用户将不得不挂断，拨打其他BBS，然后手动找到他们正在寻找的信息。 直接链接到另一个BBS内的一些内容当时是不可能的。
 
 ​	按照惯例，许多（但不是全部）Unix程序将这个字节序列视为ASCII文本。我们的日志分析示例使用了这个事实：`awk`，`sort`，`uniq`和`head`都将它们的输入文件视为由`\n`（换行符，ASCII `0x0A`）字符分隔的记录列表。 `\n`的选择是任意的 —— 可以说，ASCII记录分隔符`0x1E`本来就是一个更好的选择，因为它是为了这个目的而设计的【14】，但是无论如何，所有这些程序都使用相同的记录分隔符允许它们互操作。
 
@@ -529,7 +529,7 @@ top5.each{|count, url| puts "#{count} #{url}" }                   # 5
 
 ## MapReduce之后
 
-​	虽然MapReduce在二十世纪二十年代后期变得非常流行，并受到大量的炒作，但它只是分布式系统的许多可能的编程模型之一。对于不同的数据量，数据结构和处理类型，其他工具可能更适合表示计算。
+​	虽然MapReduce在2000年代后期变得非常流行，并受到大量的炒作，但它只是分布式系统的许多可能的编程模型之一。对于不同的数据量，数据结构和处理类型，其他工具可能更适合表示计算。
 
 ​	不管如何，我们在这一章花了大把时间来讨论MapReduce，因为它是一种有用的学习工具，它是分布式文件系统的一种相当简单明晰的抽象。在这里，**简单**意味着我们能理解它在做什么，而不是意味着使用它很简单。恰恰相反：使用原始的MapReduce API来实现复杂的处理工作实际上是非常困难和费力的 —— 例如，任意一种连接算法都需要你从头开始实现【37】。
 

ch9.md

@@ -466,7 +466,7 @@
 
 ### 全序广播
 
-​	如果你的程序只运行在单个CPU核上，那么定义一个操作全序是很容易的：可以简单地就是CPU执行这些操作的顺序。但是在分布式系统中，让所有节点对同一个全局操作顺序达成一致可能相当棘手。在上一节中，我们讨论了按时间戳或序列号进行排序，但发现它还不如单主复制给力（如果你使用时间戳排序来实现唯一性约束，而且不能容忍任何错误）。
+​	如果你的程序只运行在单个CPU核上，那么定义一个操作全序是很容易的：可以简单地就是CPU执行这些操作的顺序。但是在分布式系统中，让所有节点对同一个全局操作顺序达成一致可能相当棘手。在上一节中，我们讨论了按时间戳或序列号进行排序，但发现它还不如单主复制给力（如果你使用时间戳排序来实现唯一性约束，就不能容忍任何错误，因为你必须要从每个节点都获取到最新的序列号）。
 
 ​	如前所述，单主复制通过选择一个节点作为主库来确定操作的全序，并在主库的单个CPU核上对所有操作进行排序。接下来的挑战是，如果吞吐量超出单个主库的处理能力，这种情况下如何扩展系统；以及，如果主库失效（“[处理节点宕机](#处理节点宕机)”），如何处理故障切换。在分布式系统文献中，这个问题被称为**全序广播（total order broadcast）**或**原子广播（atomic broadcast）**[^ix]【25,57,58】。
 
@@ -552,7 +552,7 @@
 
 ​	**共识**是分布式计算中最重要也是最基本的问题之一。从表面上看似乎很简单：非正式地讲，目标只是**让几个节点达成一致（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)），我们终于准备好解决共识问题了。
 
 节点能达成一致，在很多场景下都非常重要，例如：