minor translation updates

Author: yingang

content/tw/ch2.md

@@ -13,8 +13,7 @@ breadcrumbs: false
 
 如果你正在構建一個應用程式，你將會被一系列需求所驅動。在你的需求列表中，最重要的可能是應用程式必須提供的功能：需要哪些介面和按鈕，以及每個操作應該做什麼，以實現軟體的目的。這些是你的 ***功能性需求***。
 
-此外，你可能還有一些 ***非功能性需求***：例如，應用程式應該快速、可靠、安全、合規，並且易於維護。
-這些需求可能沒有明確寫下來，因為它們看起來有些顯而易見，但它們與應用程式的功能同樣重要：一個慢得讓人無法忍受或不可靠的應用程式還不如不存在。
+此外，你可能還有一些 ***非功能性需求***：例如，應用程式應該快速、可靠、安全、合規，並且易於維護。這些需求可能沒有明確寫下來，因為它們看起來有些顯而易見，但它們與應用程式的功能同樣重要：一個慢得讓人無法忍受或不可靠的應用程式還不如不存在。
 
 許多非功能性需求，比如安全性，超出了本書的範圍。但我們將考慮一些非功能性需求，本章將幫助你為自己的系統闡明它們：
 
@@ -30,7 +29,7 @@ breadcrumbs: false
 
 想象一下，你被賦予了實現一個類似 X（前身為 Twitter）風格的社交網路的任務，使用者可以釋出訊息並關注其他使用者。這將是對這種服務實際工作方式的巨大簡化 [^1] [^2] [^3]，但它將有助於說明大規模系統中出現的一些問題。
 
-假設使用者每天釋出 5 億條帖子，或平均每秒 5,700 條帖子。偶爾，速率可能飆升至每秒 150,000 條帖子 [^4]。我們還假設平均每個使用者關注 200 人並有 200 個粉絲（儘管範圍非常廣泛：大多數人只有少數粉絲，而少數名人如巴拉克・奧巴馬有超過 1 億粉絲）。
+假設使用者每天釋出 5 億條帖子，或平均每秒 5,700 條帖子。偶爾，速率可能飆升至每秒 150,000 條帖子 [^4]。我們還假設平均每個使用者關注 200 人並有 200 個粉絲（儘管實際的範圍要大得多：大多數人只有少數粉絲，而少數名人如巴拉克・奧巴馬有超過 1 億粉絲）。
 
 ### 表示使用者、帖子與關注關係 {#id20}
 

content/v1/ch8.md

@@ -171,7 +171,7 @@ breadcrumbs: false
 在驾驶汽车时，由于交通拥堵，道路交通网络的通行时间往往不尽相同。同样，计算机网络上数据包延迟的可变性通常是由于排队【25】：
 
 * 如果多个不同的节点同时尝试将数据包发送到同一目的地，则网络交换机必须将它们排队并将它们逐个送入目标网络链路（如 [图 8-2](/v1/ddia_0802.png) 所示）。在繁忙的网络链路上，数据包可能需要等待一段时间才能获得一个插槽（这称为网络拥塞）。如果传入的数据太多，交换机队列填满，数据包将被丢弃，因此需要重新发送数据包 - 即使网络运行良好。
-* 当数据包到达目标机器时，如果所有 CPU 内核当前都处于繁忙状态，则来自网络的传入请求将被操作系统排队，直到应用程序准备好处理它为止。根据机器上的负载，这可能需要一段任意的时间。
+* 当数据包到达目标机器时，如果所有 CPU 核心当前都处于繁忙状态，则来自网络的传入请求将被操作系统排队，直到应用程序准备好处理它为止。根据机器上的负载，这可能需要一段任意的时间。
 * 在虚拟化环境中，正在运行的操作系统经常暂停几十毫秒，因为另一个虚拟机正在使用 CPU 核心。在这段时间内，虚拟机不能从网络中消耗任何数据，所以传入的数据被虚拟机监视器 【26】排队（缓冲），进一步增加了网络延迟的可变性。
 * TCP 执行 **流量控制**（flow control，也称为 **拥塞避免**，即 congestion avoidance，或 **背压**，即 backpressure），其中节点会限制自己的发送速率以避免网络链路或接收节点过载【27】。这意味着甚至在数据进入网络之前，在发送者处就需要进行额外的排队。
 

content/v1_tw/ch7.md

@@ -801,7 +801,7 @@ WHERE room_id = 123 AND
 
 當事務寫入資料庫時，它必須在索引中查詢最近曾讀取受影響資料的其他事務。這個過程類似於在受影響的鍵範圍上獲取寫鎖，但鎖並不會阻塞事務直到其他讀事務完成，而是像警戒線一樣只是簡單通知其他事務：你們讀過的資料可能不是最新的啦。
 
-在 [圖 7-11](/v1/ddia_0711.png) 中，事務 43 通知事務 42 其先前讀已過時，反之亦然。事務 42 首先提交併成功，儘管事務 43 的寫影響了 42 ，但因為事務 43 尚未提交，所以寫入尚未生效。然而當事務 43 想要提交時，來自事務 42 的衝突寫入已經被提交，所以事務 43 必須中止。
+在 [圖 7-11](/v1/ddia_0711.png) 中，事務 42 通知事務 43 其先前讀已過時，反之亦然。事務 42 首先提交併成功，儘管事務 43 的寫影響了 42 ，但因為事務 43 尚未提交，所以寫入尚未生效。然而當事務 43 想要提交時，來自事務 42 的衝突寫入已經被提交，所以事務 43 必須中止。
 
 #### 可序列化快照隔離的效能
 

content/zh/ch2.md

@@ -13,8 +13,7 @@ breadcrumbs: false
 
 如果你正在构建一个应用程序，你将会被一系列需求所驱动。在你的需求列表中，最重要的可能是应用程序必须提供的功能：需要哪些界面和按钮，以及每个操作应该做什么，以实现软件的目的。这些是你的 ***功能性需求***。
 
-此外，你可能还有一些 ***非功能性需求***：例如，应用程序应该快速、可靠、安全、合规，并且易于维护。
-这些需求可能没有明确写下来，因为它们看起来有些显而易见，但它们与应用程序的功能同样重要：一个慢得让人无法忍受或不可靠的应用程序还不如不存在。
+此外，你可能还有一些 ***非功能性需求***：例如，应用程序应该快速、可靠、安全、合规，并且易于维护。这些需求可能没有明确写下来，因为它们看起来有些显而易见，但它们与应用程序的功能同样重要：一个慢得让人无法忍受或不可靠的应用程序还不如不存在。
 
 许多非功能性需求，比如安全性，超出了本书的范围。但我们将考虑一些非功能性需求，本章将帮助你为自己的系统阐明它们：
 
@@ -30,7 +29,7 @@ breadcrumbs: false
 
 想象一下，你被赋予了实现一个类似 X（前身为 Twitter）风格的社交网络的任务，用户可以发布消息并关注其他用户。这将是对这种服务实际工作方式的巨大简化 [^1] [^2] [^3]，但它将有助于说明大规模系统中出现的一些问题。
 
-假设用户每天发布 5 亿条帖子，或平均每秒 5,700 条帖子。偶尔，速率可能飙升至每秒 150,000 条帖子 [^4]。我们还假设平均每个用户关注 200 人并有 200 个粉丝（尽管范围非常广泛：大多数人只有少数粉丝，而少数名人如巴拉克・奥巴马有超过 1 亿粉丝）。
+假设用户每天发布 5 亿条帖子，或平均每秒 5,700 条帖子。偶尔，速率可能飙升至每秒 150,000 条帖子 [^4]。我们还假设平均每个用户关注 200 人并有 200 个粉丝（尽管实际的范围要大得多：大多数人只有少数粉丝，而少数名人如巴拉克・奥巴马有超过 1 亿粉丝）。
 
 ### 表示用户、帖子与关注关系 {#id20}