docs(typo): 修正部分误译

CHAPTER 01：SCALE FROM ZERO TO MILLIONS OF USERS.md

@@ -34,7 +34,7 @@
             "city": "New York",
             "state": "NY",
             "postalCode":10021
-         },		
+         },
 
          "phoneNumbers": [
             "212 555-1234",
@@ -98,11 +98,11 @@
 * 如果服务器1下线，所有流量将被路由到服务器2。这可以防止网站离线，我们还将在服务器池中添加一个新的健康 Web 服务器来平衡负载。
 * 如果网站流量迅速增长，并且两台服务器不足以处理流量，那么负载均衡可以很好的处理这个问题，你只需要向 web 服务器池中添加更多的服务器，负载均衡会自动发送请求给他们。
 
-现在 Web 层看起来很好，那数据层呢？当前设计只有一个数据库，因此不支持故障切换和冗余。数据库复制是解决这些问题的常见技术，让我们来看看吧。
+现在 Web 层看起来很好，那数据层呢？当前设计只有一个数据库，因此不支持故障切换和冗余。数据库副本是解决这些问题的常见技术，让我们来看看吧。
 
-### 数据库复制
+### 数据库副本
 
-引用自维基百科：“数据库复制可适用于许多数据库管理系统，通常在原始数据库(master)与副本数据库(slaves)之间建立主/从关系”。
+引用自维基百科：“数据库副本可适用于许多数据库管理系统，通常在原始数据库(master)与副本数据库(slaves)之间建立主/从关系”。
 
 主数据库通常仅支持写的操作。从数据库从主数据库中复制数据并且仅支持读操作。所有修改数据的命令，如：insert，delete，update 都必须发送到主数据库。
 
@@ -112,7 +112,7 @@
 
 ![](images/chapter1/figure5.jpg)
 
-数据库复制的优势包括：
+数据库副本的优势包括：
 
 * 更好的性能：在这个主/从模型中，所有的写入和更新都发生在主节点，而所有的读操作分布在从节点。这种模型提高了性能，因为它允许并行处理更多的查询。
 * 可靠性：如果你的其中一台数据库被台风、地震等自然灾害破坏，数据仍然会被保留。你无需担心数据丢失，因为数据被复制到多个位置。
@@ -123,7 +123,7 @@
 * 如果只有一个从数据库可用且它离线，读操作将临时指向主数据库。一旦发现问题，一个新的从库将会替换掉旧的从库，如果有多个从数据库是可用的，读操作会被转发到其他健康的从数据库，
 * 如果主数据库离线，一个从库会被提升为新的主库，所有的数据库操作都会临时在新的主库上执行。一个新的从库将会立即替换旧的从库进行数据复制。在生产系统中，提升一个新的主数据库更为复杂，因为从库中的数据可能不是最新的，丢失的数据需要通过运行数据恢复脚本来更新。尽管一些其他的复制方法，如多主复制和循环复制，可能有所帮助，但他们的配置更加复杂；这些讨论将超出本书的讨论范围，有兴趣的读者可以参考列出的参考资料\[4]\[5]。
 
-图1-6展示了在添加负载均衡器和数据库复制后的系统设计。
+图1-6展示了在添加负载均衡器和数据库副本后的系统设计。
 
 ![](images/chapter1/figure6.jpg)
 

CHAPTER 08：DESIGN A URL SHORTENER.md

@@ -207,7 +207,7 @@ URL 重定向的流程总结如下：
 
 * 速率限制器：我们可能面临的一个潜在安全问题是恶意用户发送大量的 URL 缩短请求。 速率限制器有助于根据 IP 地址或其他过滤规则过滤掉请求。 如果您想重温有关速率限制的记忆，请参阅“第 4 章：设计速率限制器”。
 * Web 服务器扩展：由于 Web 层是无状态的，因此很容易通过添加或删除 Web 服务器来扩展 Web 层。
-* 数据库的扩展。数据库复制和分片是常见的技术。
+* 数据库的扩展。数据库副本和分片是常见的技术。
 * 分析。数据对商业成功越来越重要。将分析解决方案整合到 URL 缩短器中，可以帮助回答一些重要的问题，如有多少人点击一个链接？他们何时点击链接？等等。
 * 可用性、一致性和可靠性。这些概念是任何大型系统成功的核心。我们在第1章中对它们进行了详细讨论，请对这些主题进行复习记忆
 

CHAPTER 09：DESIGN A WEB CRAWLER.md

@@ -311,7 +311,7 @@ Disallow: /gp/aw/cr/
 
 * 服务器端渲染：众多的网站使用 JavaScript、AJAX 等脚本来即时生成链接。如果我们直接下载并解析网页，我们将无法检索到动态生成的链接。为了解决这个问题，我们在解析网页之前先进行服务器端的渲染（也叫动态渲染）\[12]。
 * 过滤不需要的页面：有限的存储容量和抓取资源，反垃圾信息组件有利于过滤掉低质量和垃圾页面 \[13] \[14]。
-* 数据库复制和分片：复制和分片等技术用于提高数据层的可用性、可扩展性和可靠性。
+* 数据库副本和分片：复制和分片等技术用于提高数据层的可用性、可扩展性和可靠性。
 * 水平扩展：对于大规模爬取，需要数百甚至数千台服务器来执行下载任务。 关键是保持服务器无状态。
 * 可用性、一致性和可靠性。这些概念是任何大型系统成功的核心。我们在第1章中详细讨论了这些概念。重温一下你对这些主题的记忆。
 * 分析：收集和分析数据是任何系统的重要组成部分，因为数据是微调的关键要素。

CHAPTER 14：DESIGN YOUTUBE.md

@@ -385,7 +385,7 @@ CDN 是我们系统的一个重要组成部分。它确保了在全球范围内
 在这一章中，我们介绍了 YouTube 等视频流服务的架构设计。如果在面试结束时有多余的时间，这里有几个补充要点。
 
 * 扩展 API 层：因为 API 服务器是无状态的，所以很容易横向扩展 API 层。
-* 扩展数据库：你可以谈谈数据库复制和分片。
+* 扩展数据库：你可以谈谈数据库副本和分片。
 * 现场直播：它指的是一个视频如何被记录和实时播放的过程。虽然我们的系统不是专门为直播设计的，但直播和非直播有一些相似之处：都需要上传、编码和流媒体。显著的区别是：
   * 实时流媒体有更高的延迟要求，所以可能需要不同的流媒体协议。
   * 实时流媒体对并行性的要求较低，因为小块的数据已经被实时处理。

Volume2/CHAPTER 07：Hotel Reservation System.md

@@ -10,19 +10,19 @@
 
 酒店预订系统非常复杂，其组件因业务用例而异。在深入设计之前，你应该向面试官询问澄清问题以缩小范围。
 
-**候选人**：系统的规模有多大？  
+**候选人**：系统的规模有多大？
 **面试官**：假设我们是为一个拥有 5,000 家酒店、共 100 万间客房的连锁酒店建立网站。
 
-**候选人**：客户是在预订时支付，还是在到达酒店时支付？  
+**候选人**：客户是在预订时支付，还是在到达酒店时支付？
 **面试官**：为了简单起见，他们在预订时全额支付。
 
-**候选人**：客户仅通过酒店网站预订客房吗？我们需要支持其他预订方式（如电话预订）吗？  
+**候选人**：客户仅通过酒店网站预订客房吗？我们需要支持其他预订方式（如电话预订）吗？
 **面试官**：假设人们可以通过酒店网站或 App 预订客房。
 
-**候选人**：客户可以取消预订吗？  
+**候选人**：客户可以取消预订吗？
 **面试官**：可以。
 
-**候选人**：还有其他需要考虑的事情吗？  
+**候选人**：还有其他需要考虑的事情吗？
 **面试官**：是的，我们允许 10% 的超额预订（overbooking）。如果你不知道的话，超额预订意味着酒店出售的房间数超过了其实际拥有的房间数。酒店这样做是考虑到部分客户会取消预订。
 
 **候选人**：由于时间有限，我假设酒店搜索不在范围内。我们专注于以下功能：
@@ -35,7 +35,7 @@
 
 **面试官**：听起来不错。
 
-**面试官**：还有一件事，酒店价格是动态变化的。客房价格取决于该酒店在给定日期的预计入住率。对于本次面试，我们可以假设每天的价格可能不同。  
+**面试官**：还有一件事，酒店价格是动态变化的。客房价格取决于该酒店在给定日期的预计入住率。对于本次面试，我们可以假设每天的价格可能不同。
 **候选人**：我会记住这一点的。
 
 接下来，你可能想谈谈最重要的非功能性需求。
@@ -225,7 +225,7 @@ POST /v1/reservations
 
 设计 `room_type_inventory` 表还有其他方法，但每个日期一行可以使管理日期范围内的预订和查询变得容易。如图 6 所示，(hotel_id, room_type_id, date) 是复合主键。表中的行是通过查询未来 2 年内所有日期的库存数据预先填充的。我们有一个预定的每日作业，当日期进一步推进时，该作业会预先填充库存数据。
 
-现在我们已经完成了表结构设计，让我们对存储容量做一些估算。正如在估算部分提到的，我们有 5,000 家酒店。假设每家酒店有 20 种房型。那么就是 (5,000 家酒店 x 20 种房型 x 2 年 x 365 天) = 7,300 万行。7,300 万行数据量并不大，单个数据库足以存储这些数据。然而，单台服务器意味着单点故障。为了实现高可用性，我们可以跨多个区域或可用区设置数据库复制。
+现在我们已经完成了表结构设计，让我们对存储容量做一些估算。正如在估算部分提到的，我们有 5,000 家酒店。假设每家酒店有 20 种房型。那么就是 (5,000 家酒店 x 20 种房型 x 2 年 x 365 天) = 7,300 万行。7,300 万行数据量并不大，单个数据库足以存储这些数据。然而，单台服务器意味着单点故障。为了实现高可用性，我们可以跨多个区域或可用区设置数据库副本。
 
 表 4 显示了 “room_type_inventory” 表的样本数据。
 
@@ -544,16 +544,16 @@ Commit
 
 ## 参考资料 (Reference Material)
 
-[1] 微服务：https://en.wikipedia.org/wiki/Microservices  
-[2] 微服务架构有哪些好处？：https://www.appdynamics.com/topics/benefits-of-microservices  
-[3] gRPC: https://www.grpc.io/docs/what-is-grpc/introduction/  
-[4] 来源：Booking.com iOS app  
-[5] 串行化：https://en.wikipedia.org/wiki/Serializability  
-[6] 乐观和悲观记录锁：https://ibm.co/3Eb293O  
-[7] 乐观并发控制：https://en.wikipedia.org/wiki/Optimistic_concurrency_control  
-[8] 变更数据捕获：https://docs.oracle.com/cd/B10500_01/server.920/a96520/cdc.htm  
-[9] Debizium: https://debezium.io/  
-[10] Redis sink: https://bit.ly/3r3AEUD  
-[11] 单体架构：https://microservices.io/patterns/monolithic.html  
-[12] 二阶段提交协议：https://en.wikipedia.org/wiki/Two-phase_commit_protocol  
-[13] Saga: https://microservices.io/patterns/data/saga.html  
+[1] 微服务：https://en.wikipedia.org/wiki/Microservices
+[2] 微服务架构有哪些好处？：https://www.appdynamics.com/topics/benefits-of-microservices
+[3] gRPC: https://www.grpc.io/docs/what-is-grpc/introduction/
+[4] 来源：Booking.com iOS app
+[5] 串行化：https://en.wikipedia.org/wiki/Serializability
+[6] 乐观和悲观记录锁：https://ibm.co/3Eb293O
+[7] 乐观并发控制：https://en.wikipedia.org/wiki/Optimistic_concurrency_control
+[8] 变更数据捕获：https://docs.oracle.com/cd/B10500_01/server.920/a96520/cdc.htm
+[9] Debizium: https://debezium.io/
+[10] Redis sink: https://bit.ly/3r3AEUD
+[11] 单体架构：https://microservices.io/patterns/monolithic.html
+[12] 二阶段提交协议：https://en.wikipedia.org/wiki/Two-phase_commit_protocol
+[13] Saga: https://microservices.io/patterns/data/saga.html