fix many wrongly formatted emphasis

ch5.md

@@ -559,7 +559,7 @@
 * 如果写操作与读操作同时发生，写操作可能仅反映在某些副本上。在这种情况下，不确定读取是返回旧值还是新值。
 * 如果写操作在某些副本上成功，而在其他节点上失败（例如，因为某些节点上的磁盘已满），在小于w个副本上写入成功。所以整体判定写入失败，但整体写入失败并没有在写入成功的副本上回滚。这意味着如果一个写入虽然报告失败，后续的读取仍然可能会读取这次失败写入的值【47】。
 * 如果携带新值的节点失败，需要读取其他带有旧值的副本。并且其数据从带有旧值的副本中恢复，则存储新值的副本数可能会低于w，从而打破法定人数条件。
-* 即使一切工作正常，有时也会不幸地出现关于**时序（timing）** 的边缘情况，我们将在**“[线性一致性和法定人数](ch9.md#线性一致性和法定人数)”中看到这点。
+* 即使一切工作正常，有时也会不幸地出现关于**时序（timing）** 的边缘情况，我们将在“[线性一致性和法定人数](ch9.md#线性一致性和法定人数)”中看到这点。
 
 因此，尽管法定人数似乎保证读取返回最新的写入值，但在实践中并不那么简单。 Dynamo风格的数据库通常针对可以忍受最终一致性的用例进行优化。允许通过参数w和r来调整读取陈旧值的概率，但把它们当成绝对的保证是不明智的。
 

ch9.md

@@ -657,7 +657,7 @@
 
 #### 三阶段提交
 
-​	两阶段提交被称为**阻塞（blocking）**原子提交协议，因为存在2PC可能卡住并等待协调者恢复的情况。理论上，可以使一个原子提交协议变为**非阻塞（nonblocking）**的，以便在节点失败时不会卡住。但是让这个协议能在实践中工作并没有那么简单。
+​	两阶段提交被称为**阻塞（blocking）**- 原子提交协议，因为存在2PC可能卡住并等待协调者恢复的情况。理论上，可以使一个原子提交协议变为**非阻塞（nonblocking）** 的，以便在节点失败时不会卡住。但是让这个协议能在实践中工作并没有那么简单。
 
 ​	作为2PC的替代方案，已经提出了一种称为**三阶段提交（3PC）** 的算法【13,80】。然而，3PC假定网络延迟有界，节点响应时间有限；在大多数具有无限网络延迟和进程暂停的实际系统中（见[第八章](ch8.md)），它并不能保证原子性。
 
@@ -689,7 +689,7 @@
 
 ​	如果消息传递或数据库事务任意一者失败，两者都会中止，因此消息代理可能会在稍后安全地重传消息。因此，通过原子提交**消息处理及其副作用**，即使在成功之前需要几次重试，也可以确保消息被**有效地（effectively）** 恰好处理一次。中止会抛弃部分完成事务所导致的任何副作用。
 
-​	然而，只有当所有受事务影响的系统都使用同样的**原子提交协议（atomic commit protocl）**时，这样的分布式事务才是可能的。例如，假设处理消息的副作用是发送一封邮件，而邮件服务器并不支持两阶段提交：如果消息处理失败并重试，则可能会发送两次或更多次的邮件。但如果处理消息的所有副作用都可以在事务中止时回滚，那么这样的处理流程就可以安全地重试，就好像什么都没有发生过一样。
+​	然而，只有当所有受事务影响的系统都使用同样的**原子提交协议（atomic commit protocol）** 时，这样的分布式事务才是可能的。例如，假设处理消息的副作用是发送一封邮件，而邮件服务器并不支持两阶段提交：如果消息处理失败并重试，则可能会发送两次或更多次的邮件。但如果处理消息的所有副作用都可以在事务中止时回滚，那么这样的处理流程就可以安全地重试，就好像什么都没有发生过一样。
 
 ​	在[第十一章](ch11.md)中将再次回到“恰好一次”消息处理的主题。让我们先来看看允许这种异构分布式事务的原子提交协议。