fix some format and syntax bugs

ch5.md

@@ -708,7 +708,7 @@
 
 ​	[图5-13](img/fig5-13.png)中的示例只使用一个副本。当有多个副本但没有领导者时，算法如何修改？
 
-​	[图5-13](img/fig5-13.png)使用单个版本号来捕获操作之间的依赖关系，但是当多个副本并发接受写入时，这是不够的。相反，除了对每个键使用版本号之外，还需要在**每个副本**中版本号。每个副本在处理写入时增加自己的版本号，并且跟踪从其他副本中看到的版本号。这个信息指出了要覆盖哪些值，以及保留哪些值作为兄弟。
+​	[图5-13](img/fig5-13.png)使用单个版本号来捕获操作之间的依赖关系，但是当多个副本并发接受写入时，这是不够的。相反，除了对每个键使用版本号之外，还需要在**每个副本**中使用版本号。每个副本在处理写入时增加自己的版本号，并且跟踪从其他副本中看到的版本号。这个信息指出了要覆盖哪些值，以及保留哪些值作为兄弟。
 
 ​	所有副本的版本号集合称为**版本向量（version vector）**【56】。这个想法的一些变体正在使用，但最有趣的可能是在Riak 2.0 【58,59】中使用的**分散版本矢量（dotted version vector）**【57】。我们不会深入细节，但是它的工作方式与我们在购物车示例中看到的非常相似。
 

ch6.md

@@ -140,7 +140,7 @@
 ​	但是，从文档分区索引中读取需要注意：除非您对文档ID做了特别的处理，否则没有理由将所有具有特定颜色或特定品牌的汽车放在同一个分区中。在[图6-4](img/fig6-4.png)中，红色汽车出现在分区0和分区1中。因此，如果要搜索红色汽车，则需要将查询发送到所有分区，并合并所有返回的结果。
 
 
-​	这种查询分区数据库的方法有时被称为**分散/聚集（scatter/gather）**，并且可能会使二级索引上的读取查询相当昂贵。即使并行查询分区，分散/聚集也容易导致尾部延迟放大（参阅“[实践中的百分位点](ch1.md#实践中的百分位点)”）。然而，它被广泛使用：MonDBDB，Riak 【15】，Cassandra 【16】，Elasticsearch 【17】，SolrCloud 【18】和VoltDB 【19】都使用文档分区二级索引。大多数数据库供应商建议您构建一个能从单个分区提供二级索引查询的分区方案，但这并不总是可行，尤其是当在单个查询中使用多个二级索引时（例如同时需要按颜色和制造商查询）。
+​	这种查询分区数据库的方法有时被称为**分散/聚集（scatter/gather）**，并且可能会使二级索引上的读取查询相当昂贵。即使并行查询分区，分散/聚集也容易导致尾部延迟放大（参阅“[实践中的百分位点](ch1.md#实践中的百分位点)”）。然而，它被广泛使用：MongoDB，Riak 【15】，Cassandra 【16】，Elasticsearch 【17】，SolrCloud 【18】和VoltDB 【19】都使用文档分区二级索引。大多数数据库供应商建议您构建一个能从单个分区提供二级索引查询的分区方案，但这并不总是可行，尤其是当在单个查询中使用多个二级索引时（例如同时需要按颜色和制造商查询）。
 
 
 ### 根据关键词(Term)的二级索引
@@ -317,7 +317,7 @@
 我们还讨论了分区和二级索引之间的相互作用。次级索引也需要分区，有两种方法：
 
 * 按文档分区（本地索引），其中二级索引存储在与主键和值相同的分区中。这意味着只有一个分区需要在写入时更新，但是读取二级索引需要在所有分区之间进行分散/收集。
-* 按关键词分区（全局索引），其中二级索引存在不同的分区的。辅助索引中的条目可以包括来自主键的所有分区的记录。当文档写入时，需要更新多个分区中的二级索引；但是可以从单个分区中进行读取。
+* 按关键词分区（全局索引），其中二级索引存在不同的分区中。辅助索引中的条目可以包括来自主键的所有分区的记录。当文档写入时，需要更新多个分区中的二级索引；但是可以从单个分区中进行读取。
 
 最后，我们讨论了将查询路由到适当的分区的技术，从简单的分区负载平衡到复杂的并行查询执行引擎。
 

ch8.md

@@ -137,7 +137,7 @@
 许多系统需要自动检测故障节点。例如：
 
 * 负载平衡器需要停止向已死亡的节点转发请求（即从**移出轮询列表（out of rotation）**）。
-* 在单主复制功能的分布式数据库中，如果主库失效，则需要将从库之一升级为新主库（参阅“[ch5.md#处理节点宕机](处理节点宕机)”）。
+* 在单主复制功能的分布式数据库中，如果主库失效，则需要将从库之一升级为新主库（参阅“[处理节点宕机](ch5.md#处理节点宕机)”）。
 
 不幸的是，网络的不确定性使得很难判断一个节点是否工作。在某些特定的情况下，您可能会收到一些反馈信息，明确告诉您某些事情没有成功：
 
@@ -194,7 +194,7 @@
 
 ​	在这种环境下，您只能通过实验方式选择超时：测量延长的网络往返时间和多台机器的分布，以确定延迟的预期可变性。然后，考虑到应用程序的特性，可以确定**故障检测延迟**与**过早超时风险**之间的适当折衷。
 
-​	更好的一种做法是，系统不是使用配置的常量超时，而是连续测量响应时间及其变化（抖动），并根据观察到的响应时间分布自动调整超时。这可以通过Phi Accrual故障检测器【30】来完成，该检测器例如在Akka和Cassandra 【31】中使用。 TCP重传超时也同样起作用【27】。
+​	更好的一种做法是，系统不是使用配置的常量超时时间，而是连续测量响应时间及其变化（抖动），并根据观察到的响应时间分布自动调整超时时间。这可以通过Phi Accrual故障检测器【30】来完成，该检测器在例如Akka和Cassandra 【31】中使用。 TCP超时重传机制也同样起作用【27】。
 
 ### 同步网络 vs 异步网络