maintain consistency of term 'quorum'

ch5.md

@@ -489,7 +489,7 @@
 
 ![](img/fig5-10.png)
 
-**图5-10 法定人数写入，法定读取，并在节点中断后读修复。**
+**图5-10 法定写入，法定读取，并在节点中断后读修复。**
 
 ​	现在想象一下，不可用的节点重新联机，客户端开始读取它。节点关闭时发生的任何写入都从该节点丢失。因此，如果您从该节点读取数据，则可能会将陈旧（过时）值视为响应。
 
@@ -526,7 +526,7 @@
 > 集群中可能有多于n的节点。（集群的机器数可能多于副本数目），但是任何给定的值只能存储在n个节点上。 这允许对数据集进行分区，从而支持可以放在一个节点上的数据集更大的数据集。 将在第6章回到分区。
 >
 
-仲裁条件$w + r> n$允许系统容忍不可用的节点，如下所示：
+法定人数条件$w + r> n$允许系统容忍不可用的节点，如下所示：
 
 * 如果$w <n$，如果节点不可用，我们仍然可以处理写入。
 * 如果$r <n$，如果节点不可用，我们仍然可以处理读取。

ch9.md

@@ -226,7 +226,7 @@
 
 
 
-​	基于时钟（例如，在Cassandra中；参见“[依赖同步时钟](ch8.md#依赖同步时钟)”）的“最后写入胜利”冲突解决方法几乎可以确定是非线性的，由于时钟偏差，不能保证时钟的时间戳与实际事件顺序一致。[宽松的仲裁](ch5.md#马虎法定人数和暗示交接)也破坏了线性一致的可能性。即使使用严格的法定人数，非线性一致的行为也是可能的，如下节所示。
+​	基于时钟（例如，在Cassandra中；参见“[依赖同步时钟](ch8.md#依赖同步时钟)”）的“最后写入胜利”冲突解决方法几乎可以确定是非线性的，由于时钟偏差，不能保证时钟的时间戳与实际事件顺序一致。[宽松的法定人数](ch5.md#宽松的法定人数与提示移交)也破坏了线性一致的可能性。即使使用严格的法定人数，非线性一致的行为也是可能的，如下节所示。
 
 #### 线性一致性和法定人数
 
@@ -238,7 +238,7 @@
 
 ​	在[图9-6](img/fig9-6.png)中，$x$ 的初始值为0，写入客户端通过向所有三个副本（ $n = 3, w = 3$ ）发送写入将 $x$ 更新为 `1`。客户端A并发地从两个节点组成的法定人群（ $r = 2$ ）中读取数据，并在其中一个节点上看到新值 `1` 。客户端B也并发地从两个不同的节点组成的法定人数中读取，并从两个节点中取回了旧值 `0` 。
 
-​	仲裁条件满足（ $w + r> n$ ），但是这个执行是非线性一致的：B的请求在A的请求完成后开始，但是B返回旧值，而A返回新值。 （又一次，如同Alice和Bob的例子 [图9-1]()）
+​	法定人数条件满足（ $w + r> n$ ），但是这个执行是非线性一致的：B的请求在A的请求完成后开始，但是B返回旧值，而A返回新值。 （又一次，如同Alice和Bob的例子 [图9-1]()）
 
 ​	有趣的是，通过牺牲性能，可以使Dynamo风格的法定人数线性化：读取者必须在将结果返回给应用之前，同步执行读修复（参阅“[读时修复与反熵过程](ch5.md#读时修复与反熵过程)”） ，并且写入者必须在发送写入之前，读取法定数量节点的最新状态【24,25】。然而，由于性能损失，Riak不执行同步读修复【26】。 Cassandra在进行法定人数读取时，**确实**在等待读修复完成【27】；但是由于使用了最后写入胜利的冲突解决方案，当同一个键有多个并发写入时，将不能保证线性一致性。
 

glossary.md

@@ -264,7 +264,7 @@
 
 ### 法定人数（quorum）
 
-在操作完成之前，需要对操作进行投票的最少节点数量。 请参阅第179页上的“读和写的法定人数”。
+在操作完成之前，需要对操作进行投票的最少节点数量。 请参阅第179页上的“读写的法定人数”。