diff --git "a/CHAPTER 01\357\274\232SCALE FROM ZERO TO MILLIONS OF USERS.md" "b/CHAPTER 01\357\274\232SCALE FROM ZERO TO MILLIONS OF USERS.md" index 021c776..30a02cc 100644 --- "a/CHAPTER 01\357\274\232SCALE FROM ZERO TO MILLIONS OF USERS.md" +++ "b/CHAPTER 01\357\274\232SCALE 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) diff --git "a/CHAPTER 08\357\274\232DESIGN A URL SHORTENER.md" "b/CHAPTER 08\357\274\232DESIGN A URL SHORTENER.md" index 9cb9d1c..d532d4b 100644 --- "a/CHAPTER 08\357\274\232DESIGN A URL SHORTENER.md" +++ "b/CHAPTER 08\357\274\232DESIGN A URL SHORTENER.md" @@ -207,7 +207,7 @@ URL 重定向的流程总结如下： * 速率限制器：我们可能面临的一个潜在安全问题是恶意用户发送大量的 URL 缩短请求。 速率限制器有助于根据 IP 地址或其他过滤规则过滤掉请求。 如果您想重温有关速率限制的记忆，请参阅“第 4 章：设计速率限制器”。 * Web 服务器扩展：由于 Web 层是无状态的，因此很容易通过添加或删除 Web 服务器来扩展 Web 层。 -* 数据库的扩展。数据库复制和分片是常见的技术。 +* 数据库的扩展。数据库副本和分片是常见的技术。 * 分析。数据对商业成功越来越重要。将分析解决方案整合到 URL 缩短器中，可以帮助回答一些重要的问题，如有多少人点击一个链接？他们何时点击链接？等等。 * 可用性、一致性和可靠性。这些概念是任何大型系统成功的核心。我们在第1章中对它们进行了详细讨论，请对这些主题进行复习记忆 diff --git "a/CHAPTER 09\357\274\232DESIGN A WEB CRAWLER.md" "b/CHAPTER 09\357\274\232DESIGN A WEB CRAWLER.md" index c8df039..924046c 100644 --- "a/CHAPTER 09\357\274\232DESIGN A WEB CRAWLER.md" +++ "b/CHAPTER 09\357\274\232DESIGN A WEB CRAWLER.md" @@ -311,7 +311,7 @@ Disallow: /gp/aw/cr/ * 服务器端渲染：众多的网站使用 JavaScript、AJAX 等脚本来即时生成链接。如果我们直接下载并解析网页，我们将无法检索到动态生成的链接。为了解决这个问题，我们在解析网页之前先进行服务器端的渲染（也叫动态渲染）\[12]。 * 过滤不需要的页面：有限的存储容量和抓取资源，反垃圾信息组件有利于过滤掉低质量和垃圾页面 \[13] \[14]。 -* 数据库复制和分片：复制和分片等技术用于提高数据层的可用性、可扩展性和可靠性。 +* 数据库副本和分片：复制和分片等技术用于提高数据层的可用性、可扩展性和可靠性。 * 水平扩展：对于大规模爬取，需要数百甚至数千台服务器来执行下载任务。 关键是保持服务器无状态。 * 可用性、一致性和可靠性。这些概念是任何大型系统成功的核心。我们在第1章中详细讨论了这些概念。重温一下你对这些主题的记忆。 * 分析：收集和分析数据是任何系统的重要组成部分，因为数据是微调的关键要素。 diff --git "a/CHAPTER 14\357\274\232DESIGN YOUTUBE.md" "b/CHAPTER 14\357\274\232DESIGN YOUTUBE.md" index 0567f1b..247cb43 100644 --- "a/CHAPTER 14\357\274\232DESIGN YOUTUBE.md" +++ "b/CHAPTER 14\357\274\232DESIGN YOUTUBE.md" @@ -385,7 +385,7 @@ CDN 是我们系统的一个重要组成部分。它确保了在全球范围内 在这一章中，我们介绍了 YouTube 等视频流服务的架构设计。如果在面试结束时有多余的时间，这里有几个补充要点。 * 扩展 API 层：因为 API 服务器是无状态的，所以很容易横向扩展 API 层。 -* 扩展数据库：你可以谈谈数据库复制和分片。 +* 扩展数据库：你可以谈谈数据库副本和分片。 * 现场直播：它指的是一个视频如何被记录和实时播放的过程。虽然我们的系统不是专门为直播设计的，但直播和非直播有一些相似之处：都需要上传、编码和流媒体。显著的区别是： * 实时流媒体有更高的延迟要求，所以可能需要不同的流媒体协议。 * 实时流媒体对并行性的要求较低，因为小块的数据已经被实时处理。 diff --git "a/Volume2/CHAPTER 07\357\274\232Hotel Reservation System.md" "b/Volume2/CHAPTER 07\357\274\232Hotel Reservation System.md" index dc0d148..1b3e8a0 100644 --- "a/Volume2/CHAPTER 07\357\274\232Hotel Reservation System.md" +++ "b/Volume2/CHAPTER 07\357\274\232Hotel 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 \ No newline at end of file +[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 \ No newline at end of file