ch9 50%

README.md

@@ -128,7 +128,8 @@
 All contribution will give proper credit. 贡献者需要同意[法律声明](#法律声明)所叙内容。
 
 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)
+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) by @[MuAlex](https://github.com/Vonng/ddia/commits?author=MuAlex) 
 
 
 

ch5.md

@@ -596,9 +596,9 @@ PostgreSQL和Oracle等使用这种复制方法【16】。主要缺点是日志
 
 在所有常见的Dynamo实现中，松散法定人数是可选的。在Riak中，它们默认是启用的，而在Cassandra和Voldemort中它们默认是禁用的【46,49,50】。
 
-#### 多数据中心操作
+#### 运维多个数据中心
 
-我们先前讨论了跨数据中心复制作为多主复制的用例（请参阅第162页的“[多重复制]()”）。无主复制还适用于多数据中心操作，因为它旨在容忍冲突的并发写入，网络中断和延迟尖峰。
+我们先前讨论了跨数据中心复制作为多主复制的用例（参阅“[多主复制](#多主复制)”）。无主复制还适用于多数据中心操作，因为它旨在容忍冲突的并发写入，网络中断和延迟尖峰。
 
 Cassandra和Voldemort在正常的无主模型中实现了他们的多数据中心支持：副本的数量n包括所有数据中心的节点，在配置中，您可以指定每个数据中心中您想拥有的副本的数量。无论数据中心如何，每个来自客户端的写入都会发送到所有副本，但客户端通常只等待来自其本地数据中心内的法定节点的确认，从而不会受到跨数据中心链路延迟和中断的影响。对其他数据中心的高延迟写入通常被配置为异步发生，尽管配置有一定的灵活性【50,51】。
 

ch8.md

@@ -484,15 +484,15 @@ while(true){
 
 这个问题就是我们先前在“[进程暂停](#进程暂停)”中讨论过的一个例子：如果持有租约的客户端暂停太久，它的租约将到期。另一个客户端可以获得同一文件的租约，并开始写入文件。当暂停的客户端回来时，它认为（不正确）它仍然有一个有效的租约，并继续写入文件。结果，客户的写入冲突和损坏的文件。
 
-#### 击剑令牌
+#### 防护令牌
 
-当使用锁或租约来保护对某些资源（如[图8-4](img/fig8-4.png)中的文件存储）的访问时，需要确保一个被误认为自己是“天选者”的节点不能中断系统的其它部分。实现这一目标的一个相当简单的技术就是**屏蔽（fencing）**，如[图8-5]()所示
+当使用锁或租约来保护对某些资源（如[图8-4](img/fig8-4.png)中的文件存储）的访问时，需要确保一个被误认为自己是“天选者”的节点不能中断系统的其它部分。实现这一目标的一个相当简单的技术就是**防护（fencing）**，如[图8-5]()所示
 
 ![](img/fig8-5.png)
 
 **图8-5 只允许以增加屏蔽令牌的顺序进行写操作，从而保证存储安全**
 
-我们假设每次锁定服务器授予锁或租约时，它还会返回一个**屏蔽令牌（fencing token）**，这个数字在每次授予锁定时都会增加（例如，由锁定服务增加）。然后，我们可以要求客户端每次向存储服务发送写入请求时，都必须包含当前的屏蔽令牌。
+我们假设每次锁定服务器授予锁或租约时，它还会返回一个**防护令牌（fencing token）**，这个数字在每次授予锁定时都会增加（例如，由锁定服务增加）。然后，我们可以要求客户端每次向存储服务发送写入请求时，都必须包含当前的屏蔽令牌。
 
 在[图8-5](img/fig8-5.png)中，客户端1以33的令牌获得租约，但随后进入一个长时间的停顿并且租约到期。客户端2以34的令牌（该数字总是增加）获取租约，然后将其写入请求发送到存储服务，包括34的令牌。稍后，客户端1恢复生机并将其写入存储服务，包括其令牌值33.但是，存储服务器会记住它已经处理了一个具有更高令牌编号（34）的写入，因此它会拒绝带有令牌33的请求。