several translation updates for chapter 8

ch8.md

@@ -586,15 +586,15 @@ while (true) {
 
 ​	同样，我们可以写下我们想要的分布式算法的属性来定义它的正确含义。例如，如果我们正在为一个锁生成防护令牌（参阅“[防护令牌](#防护令牌)”），我们可能要求算法具有以下属性：
 
-***唯一性***
+***唯一性（uniqueness）***
 
 ​	没有两个防护令牌请求返回相同的值。
 
-***单调序列***
+***单调序列（monotonic sequence）***
 
 ​	如果请求 $x$ 返回了令牌 $t_x$，并且请求$y$返回了令牌$t_y$，并且 $x$ 在 $y$ 开始之前已经完成，那么$t_x <t_y$。
 
-***可用性***
+***可用性（availability）***
 
 ​	请求防护令牌并且不会崩溃的节点，最终会收到响应。
 
@@ -602,22 +602,22 @@ while (true) {
 
 #### 安全性和活性
 
-​	为了澄清这种情况，有必要区分两种不同的性质：**安全性（safety）**和**活性（liveness）**。在刚刚给出的例子中，**唯一性（uniqueness）**和**单调序列（monotonic sequence）**是安全属性，但**可用性**是**活性（liveness）**属性。
+​	为了澄清这种情况，有必要区分两种不同的属性：**安全（safety）属性**和**活性（liveness）属性**。在刚刚给出的例子中，**唯一性**和**单调序列**是安全属性，而**可用性**是活性属性。
 
 ​	这两种性质有什么区别？一个试金石就是，活性属性通常在定义中通常包括“**最终**”一词。 （是的，你猜对了——最终一致性是一个活性属性【89】。）
 
-​	安全性通常被非正式地定义为，**没有坏事发生**，而活性通常就类似：**最终好事发生**。但是，最好不要过多地阅读那些非正式的定义，因为好与坏的含义是主观的。安全性和活性的实际定义是精确的和数学的【90】：
+​	安全通常被非正式地定义为：**没有坏事发生**，而活性通常就类似：**最终好事发生**。但是，最好不要过多地阅读那些非正式的定义，因为好与坏的含义是主观的。安全和活性的实际定义是精确的和数学的【90】：
 
 * 如果安全属性被违反，我们可以指向一个特定的安全属性被破坏的时间点（例如，如果违反了唯一性属性，我们可以确定重复的防护令牌被返回的特定操作）。违反安全属性后，违规行为不能被撤销——损失已经发生。
 * 活性属性反过来：在某个时间点（例如，一个节点可能发送了一个请求，但还没有收到响应），它可能不成立，但总是希望在未来能成立（即通过接受答复）。
 
-区分安全性和活性属性的一个优点是可以帮助我们处理困难的系统模型。对于分布式算法，在系统模型的所有可能情况下，要求**始终**保持安全属性是常见的【88】。也就是说，即使所有节点崩溃，或者整个网络出现故障，算法仍然必须确保它不会返回错误的结果（即保证安全性得到满足）。
+区分安全属性和活性属性的一个优点是可以帮助我们处理困难的系统模型。对于分布式算法，在系统模型的所有可能情况下，要求**始终**保持安全属性是常见的【88】。也就是说，即使所有节点崩溃，或者整个网络出现故障，算法仍然必须确保它不会返回错误的结果（即保证安全属性得到满足）。
 
 ​	但是，对于活性属性，我们可以提出一些注意事项：例如，只有在大多数节点没有崩溃的情况下，只有当网络最终从中断中恢复时，我们才可以说请求需要接收响应。部分同步模型的定义要求系统最终返回到同步状态——即任何网络中断的时间段只会持续一段有限的时间，然后进行修复。
 
 #### 将系统模型映射到现实世界
 
-​	安全性和活性属性以及系统模型对于推理分布式算法的正确性非常有用。然而，在实践中实施算法时，现实的混乱事实再一次地让你咬牙切齿，很明显系统模型是对现实的简化抽象。
+​	安全属性和活性属性以及系统模型对于推理分布式算法的正确性非常有用。然而，在实践中实施算法时，现实的混乱事实再一次地让你咬牙切齿，很明显系统模型是对现实的简化抽象。
 
 ​	例如，在崩溃-恢复（crash-recovery）模型中的算法通常假设稳定存储器中的数据在崩溃后可以幸存。但是，如果磁盘上的数据被破坏，或者由于硬件错误或错误配置导致数据被清除，会发生什么情况【91】？如果服务器存在固件错误并且在重新启动时无法识别其硬盘驱动器，即使驱动器已正确连接到服务器，那又会发生什么情况【92】？