fix cross links in v1 content

Author: yingang

content/v1/_index.md

@@ -52,32 +52,32 @@ PostgreSQL 专家，数据库老司机，云计算泥石流。
 
 ## 目录
 
-### [序言](/preface)
+### [序言](/v1/preface)
 
-### [第一部分：数据系统基础](/part-i)
+### [第一部分：数据系统基础](/v1/part-i)
 
 * [第一章：可靠性、可伸缩性和可维护性](/v1/ch1)
 * [第二章：数据模型与查询语言](/v1/ch2)
 * [第三章：存储与检索](/v1/ch3)
 * [第四章：编码与演化](/v1/ch4)
 
-### [第二部分：分布式数据](/part-ii)
+### [第二部分：分布式数据](/v1/part-ii)
 
 * [第五章：复制](/v1/ch5)
 * [第六章：分区](/v1/ch6)
 * [第七章：事务](/v1/ch7)
 * [第八章：分布式系统的麻烦](/v1/ch8)
 * [第九章：一致性与共识](/v1/ch9)
 
-### [第三部分：衍生数据](/part-iii)
+### [第三部分：衍生数据](/v1/part-iii)
 
 * [第十章：批处理](/v1/ch10)
 * [第十一章：流处理](/v1/ch11)
 * [第十二章：数据系统的未来](/v1/ch12)
 
-### [术语表](/glossary)
+### [术语表](/v1/glossary)
 
-### [后记](/colophon)
+### [后记](/v1/colophon)
 
 <br>
 

content/v1/ch1.md

@@ -359,7 +359,7 @@ breadcrumbs: false
 
 不幸的是，使应用可靠、可伸缩或可维护并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
 
-在本书后面的 [第三部分](/part-iii) 中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（如 [图 1-1](/v1/ddia_0101.png) 中的例子）
+在本书后面的 [第三部分](/v1/part-iii) 中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（如 [图 1-1](/v1/ddia_0101.png) 中的例子）
 
 
 ## 参考文献

content/v1/ch10.md

@@ -201,7 +201,7 @@ MapReduce 有点像 Unix 工具，但分布在数千台机器上。像 Unix 工
 
 [^iv]: 一个不同之处在于，对于 HDFS，可以将计算任务安排在存储特定文件副本的计算机上运行，而对象存储通常将存储和计算分开。如果网络带宽是一个瓶颈，从本地磁盘读取有性能优势。但是请注意，如果使用纠删码（Erasure Coding），则会丢失局部性，因为来自多台机器的数据必须进行合并以重建原始文件【20】。
 
-与网络连接存储（NAS）和存储区域网络（SAN）架构的共享磁盘方法相比，HDFS 基于 **无共享** 原则（请参阅 [第二部分](/part-ii) 的介绍）。共享磁盘存储由集中式存储设备实现，通常使用定制硬件和专用网络基础设施（如光纤通道）。而另一方面，无共享方法不需要特殊的硬件，只需要通过传统数据中心网络连接的计算机。
+与网络连接存储（NAS）和存储区域网络（SAN）架构的共享磁盘方法相比，HDFS 基于 **无共享** 原则（请参阅 [第二部分](/v1/part-ii) 的介绍）。共享磁盘存储由集中式存储设备实现，通常使用定制硬件和专用网络基础设施（如光纤通道）。而另一方面，无共享方法不需要特殊的硬件，只需要通过传统数据中心网络连接的计算机。
 
 HDFS 在每台机器上运行了一个守护进程，它对外暴露网络服务，允许其他节点访问存储在该机器上的文件（假设数据中心中的每台通用计算机都挂载着一些磁盘）。名为 **NameNode** 的中央服务器会跟踪哪个文件块存储在哪台机器上。因此，HDFS 在概念上创建了一个大型文件系统，可以使用所有运行有守护进程的机器的磁盘。
 

content/v1/ch11.md

@@ -254,7 +254,7 @@ Apache Kafka 【17,18】、Amazon Kinesis Streams 【19】和 Twitter 的 Distri
 
 #### 变更数据捕获的实现
 
-我们可以将日志消费者叫做 **衍生数据系统**，正如在 [第三部分](/part-iii) 的介绍中所讨论的：存储在搜索索引和数据仓库中的数据，只是 **记录系统** 数据的额外视图。变更数据捕获是一种机制，可确保对记录系统所做的所有更改都反映在衍生数据系统中，以便衍生系统具有数据的准确副本。
+我们可以将日志消费者叫做 **衍生数据系统**，正如在 [第三部分](/v1/part-iii) 的介绍中所讨论的：存储在搜索索引和数据仓库中的数据，只是 **记录系统** 数据的额外视图。变更数据捕获是一种机制，可确保对记录系统所做的所有更改都反映在衍生数据系统中，以便衍生系统具有数据的准确副本。
 
 从本质上说，变更数据捕获使得一个数据库成为领导者（被捕获变化的数据库），并将其他组件变为追随者。基于日志的消息代理非常适合从源数据库传输变更事件，因为它保留了消息的顺序（避免了 [图 11-2](/v1/ddia_1102.png) 的重新排序问题）。
 

content/v1/ch2.md

@@ -147,7 +147,7 @@ JSON 表示比 [图 2-1](/v1/ddia_0201.png) 中的多表模式具有更好的 **
 
 [^ii]: 关于关系模型的文献区分了几种不同的规范形式，但这些区别几乎没有实际意义。一个经验法则是，如果重复存储了可以存储在一个地方的值，则模式就不是 **规范化（normalized）** 的。
 
-> 数据库管理员和开发人员喜欢争论规范化和非规范化，让我们暂时保留判断吧。在本书的 [第三部分](/part-iii)，我们将回到这个话题，探讨系统的方法用以处理缓存，非规范化和衍生数据。
+> 数据库管理员和开发人员喜欢争论规范化和非规范化，让我们暂时保留判断吧。在本书的 [第三部分](/v1/part-iii)，我们将回到这个话题，探讨系统的方法用以处理缓存，非规范化和衍生数据。
 
 不幸的是，对这些数据进行规范化需要多对一的关系（许多人生活在一个特定的地区，许多人在一个特定的行业工作），这与文档模型不太吻合。在关系数据库中，通过 ID 来引用其他表中的行是正常的，因为连接很容易。在文档数据库中，一对多树结构没有必要用连接，对连接的支持通常很弱 [^iii]。
 

content/v1/ch5.md

@@ -13,7 +13,7 @@ math: true
 > —— 道格拉斯・亚当斯（1992）
 
 
-复制意味着在通过网络连接的多台机器上保留相同数据的副本。正如在 [第二部分](/part-ii) 的介绍中所讨论的那样，我们希望能复制数据，可能出于各种各样的原因：
+复制意味着在通过网络连接的多台机器上保留相同数据的副本。正如在 [第二部分](/v1/part-ii) 的介绍中所讨论的那样，我们希望能复制数据，可能出于各种各样的原因：
 
 * 使得数据与用户在地理上接近（从而减少延迟）
 * 即使系统的一部分出现故障，系统也能继续工作（从而提高可用性）
@@ -189,7 +189,7 @@ math: true
 
 ## 复制延迟问题
 
-容忍节点故障只是需要复制的一个原因。正如在 [第二部分](/part-ii) 的介绍中提到的，其它原因还包括可伸缩性（处理比单个机器更多的请求）和延迟（让副本在地理位置上更接近用户）。
+容忍节点故障只是需要复制的一个原因。正如在 [第二部分](/v1/part-ii) 的介绍中提到的，其它原因还包括可伸缩性（处理比单个机器更多的请求）和延迟（让副本在地理位置上更接近用户）。
 
 基于领导者的复制要求所有写入都由单个节点处理，但只读查询可以由任何一个副本来处理。所以对于读多写少的场景（Web 上的常见模式），一个有吸引力的选择是创建很多从库，并将读请求分散到所有的从库上去。这样能减小主库的负载，并允许由附近的副本来处理读请求。
 
@@ -288,7 +288,7 @@ math: true
 
 如果应用程序开发人员不必担心微妙的复制问题，并可以信赖他们的数据库 “做了正确的事情”，那该多好呀。这就是 **事务（transaction）** 存在的原因：**数据库通过事务提供强大的保证**，所以应用程序可以更加简单。
 
-单节点事务已经存在了很长时间。然而在走向分布式（复制和分区）数据库时，许多系统放弃了事务，声称事务在性能和可用性上的代价太高，并断言在可伸缩系统中最终一致性是不可避免的。这个叙述有一些道理，但过于简单了，本书其余部分将提出更为细致的观点。我们将在 [第七章](/v1/ch7) 和 [第九章](/v1/ch9) 回到事务的话题，并将在 [第三部分](/part-iii) 讨论一些替代机制。
+单节点事务已经存在了很长时间。然而在走向分布式（复制和分区）数据库时，许多系统放弃了事务，声称事务在性能和可用性上的代价太高，并断言在可伸缩系统中最终一致性是不可避免的。这个叙述有一些道理，但过于简单了，本书其余部分将提出更为细致的观点。我们将在 [第七章](/v1/ch7) 和 [第九章](/v1/ch9) 回到事务的话题，并将在 [第三部分](/v1/part-iii) 讨论一些替代机制。
 
 
 ## 多主复制

content/v1/ch6.md

@@ -23,7 +23,7 @@ breadcrumbs: false
 
 通常情况下，每条数据（每条记录，每行或每个文档）属于且仅属于一个分区。有很多方法可以实现这一点，本章将进行深入讨论。实际上，每个分区都是自己的小型数据库，尽管数据库可能支持同时进行多个分区的操作。
 
-分区主要是为了 **可伸缩性**。不同的分区可以放在不共享集群中的不同节点上（请参阅 [第二部分](/part-ii) 关于 [无共享架构](/part-ii#无共享架构) 的定义）。因此，大数据集可以分布在多个磁盘上，并且查询负载可以分布在多个处理器上。
+分区主要是为了 **可伸缩性**。不同的分区可以放在不共享集群中的不同节点上（请参阅 [第二部分](/v1/part-ii) 关于 [无共享架构](/v1/part-ii#无共享架构) 的定义）。因此，大数据集可以分布在多个磁盘上，并且查询负载可以分布在多个处理器上。
 
 对于在单个分区上运行的查询，每个节点可以独立执行对自己的查询，因此可以通过添加更多的节点来扩大查询吞吐量。大型，复杂的查询可能会跨越多个节点并行处理，尽管这也带来了新的困难。
 

content/v1/ch8.md

@@ -95,7 +95,7 @@ breadcrumbs: false
 
 ## 不可靠的网络
 
-正如在 [第二部分](/part-ii) 的介绍中所讨论的那样，我们在本书中关注的分布式系统是无共享的系统，即通过网络连接的一堆机器。网络是这些机器可以通信的唯一途径 —— 我们假设每台机器都有自己的内存和磁盘，一台机器不能访问另一台机器的内存或磁盘（除了通过网络向服务器发出请求）。
+正如在 [第二部分](/v1/part-ii) 的介绍中所讨论的那样，我们在本书中关注的分布式系统是无共享的系统，即通过网络连接的一堆机器。网络是这些机器可以通信的唯一途径 —— 我们假设每台机器都有自己的内存和磁盘，一台机器不能访问另一台机器的内存或磁盘（除了通过网络向服务器发出请求）。
 
 **无共享** 并不是构建系统的唯一方式，但它已经成为构建互联网服务的主要方式，其原因如下：相对便宜，因为它不需要特殊的硬件，可以利用商品化的云计算服务，通过跨多个地理分布的数据中心进行冗余可以实现高可靠性。
 
@@ -639,7 +639,7 @@ Web 应用程序确实需要预期受终端用户控制的客户端（如 Web 
 
 如果你习惯于在理想化的数学完美的单机环境（同一个操作总能确定地返回相同的结果）中编写软件，那么转向分布式系统的凌乱的物理现实可能会有些令人震惊。相反，如果能够在单台计算机上解决一个问题，那么分布式系统工程师通常会认为这个问题是平凡的【5】，现在单个计算机确实可以做很多事情【95】。如果你可以避免打开潘多拉的盒子，把东西放在一台机器上，那么通常是值得的。
 
-但是，正如在 [第二部分](/part-ii) 的介绍中所讨论的那样，可伸缩性并不是使用分布式系统的唯一原因。容错和低延迟（通过将数据放置在距离用户较近的地方）是同等重要的目标，而这些不能用单个节点实现。
+但是，正如在 [第二部分](/v1/part-ii) 的介绍中所讨论的那样，可伸缩性并不是使用分布式系统的唯一原因。容错和低延迟（通过将数据放置在距离用户较近的地方）是同等重要的目标，而这些不能用单个节点实现。
 
 在本章中，我们也转换了几次话题，探讨了网络、时钟和进程的不可靠性是否是不可避免的自然规律。我们看到这并不是：有可能给网络提供硬实时的响应保证和有限的延迟，但是这样做非常昂贵，且导致硬件资源的利用率降低。大多数非安全关键系统会选择 **便宜而不可靠**，而不是 **昂贵和可靠**。
 

content/v1/ch9.md

@@ -919,7 +919,7 @@ ZooKeeper 和它的小伙伴们可以看作是成员资格服务（membership se
 
 本章引用了大量关于分布式系统理论的研究。虽然理论论文和证明并不总是容易理解，有时也会做出不切实际的假设，但它们对于指导这一领域的实践有着极其重要的价值：它们帮助我们推理什么可以做，什么不可以做，帮助我们找到反直觉的分布式系统缺陷。如果你有时间，这些参考资料值得探索。
 
-这里已经到了本书 [第二部分](/part-ii) 的末尾，第二部介绍了复制（[第五章](/v1/ch5)）、分区（[第六章](/v1/ch6)）、事务（[第七章](/v1/ch7)）、分布式系统的故障模型（[第八章](/v1/ch8)）以及最后的一致性与共识（[第九章](/v1/ch9)）。现在我们已经奠定了扎实的理论基础，我们将在 [第三部分](/part-iii) 再次转向更实际的系统，并讨论如何使用异构的组件积木块构建强大的应用。
+这里已经到了本书 [第二部分](/v1/part-ii) 的末尾，第二部介绍了复制（[第五章](/v1/ch5)）、分区（[第六章](/v1/ch6)）、事务（[第七章](/v1/ch7)）、分布式系统的故障模型（[第八章](/v1/ch8)）以及最后的一致性与共识（[第九章](/v1/ch9)）。现在我们已经奠定了扎实的理论基础，我们将在 [第三部分](/v1/part-iii) 再次转向更实际的系统，并讨论如何使用异构的组件积木块构建强大的应用。
 
 
 ## 参考文献

content/v1/contrib.md

@@ -15,7 +15,7 @@ PostgreSQL 专家，数据库老司机，云计算泥石流。
 
 ## 校订与维护
 
-YinGang [@yingang](https://github.com/yingang) 对本书进行了全文校订，并持续维护。
+Yin Gang [@yingang](https://github.com/yingang) 对本书进行了全文校订，并持续维护。
 
 ## 繁体中文版本
 
@@ -29,8 +29,8 @@ YinGang [@yingang](https://github.com/yingang) 对本书进行了全文校订，
 1. [序言初翻修正](https://github.com/Vonng/ddia/commit/afb5edab55c62ed23474149f229677e3b42dfc2c) by [@seagullbird](https://github.com/Vonng/ddia/commits?author=seagullbird)
 2. [第一章语法标点校正](https://github.com/Vonng/ddia/commit/973b12cd8f8fcdf4852f1eb1649ddd9d187e3644) by [@nevertiree](https://github.com/Vonng/ddia/commits?author=nevertiree)
 3. [第六章部分校正](https://github.com/Vonng/ddia/commit/d4eb0852c0ec1e93c8aacc496c80b915bb1e6d48) 与[第十章的初翻](https://github.com/Vonng/ddia/commit/9de8dbd1bfe6fbb03b3bf6c1a1aa2291aed2490e) by [@MuAlex](https://github.com/Vonng/ddia/commits?author=MuAlex)
-4. [第一部分](/part-i)前言，[ch2](/v1/ch2)校正 by [@jiajiadebug](https://github.com/Vonng/ddia/commits?author=jiajiadebug)
-5. [词汇表](/glossary)、[后记](/colophon)关于野猪的部分 by [@Chowss](https://github.com/Vonng/ddia/commits?author=Chowss)
+4. [第一部分](/v1/part-i)前言，[ch2](/v1/ch2)校正 by [@jiajiadebug](https://github.com/Vonng/ddia/commits?author=jiajiadebug)
+5. [词汇表](/v1/glossary)、[后记](/v1/colophon)关于野猪的部分 by [@Chowss](https://github.com/Vonng/ddia/commits?author=Chowss)
 6. [繁體中文](https://github.com/Vonng/ddia/pulls)版本与转换脚本 by [@afunTW](https://github.com/afunTW)
 7. 多处翻译修正 by [@songzhibin97](https://github.com/Vonng/ddia/commits?author=songzhibin97) [@MamaShip](https://github.com/Vonng/ddia/commits?author=MamaShip) [@FangYuan33](https://github.com/Vonng/ddia/commits?author=FangYuan33)