minor translation updates suggested by copilot

Author: yingang

content/tw/ch2.md

@@ -20,7 +20,7 @@ breadcrumbs: false
 * 如何定義和衡量系統的 **效能**（參見 ["描述效能"](/tw/ch2#sec_introduction_percentiles)）；
 * 服務 **可靠** 意味著什麼——即即使出現問題也能繼續正確工作（參見 ["可靠性與容錯"](/tw/ch2#sec_introduction_reliability)）；
 * 透過在系統負載增長時新增計算能力的有效方法，使系統具有 **可伸縮性**（參見 ["可伸縮性"](/tw/ch2#sec_introduction_scalability)）；以及
-* 使系統長期更 **易於維護**（參見 ["可運維性"](/tw/ch2#sec_introduction_maintainability)）。
+* 使系統長期更 **易於維護**（參見 ["可維護性"](/tw/ch2#sec_introduction_maintainability)）。
 
 本章介紹的術語在後續章節中也很有用，當我們深入研究資料密集型系統的實現細節時。然而，抽象定義可能相當枯燥；為了使這些想法更具體，我們將從一個案例研究開始本章，研究社交網路服務可能如何工作，這將提供效能和可伸縮性的實際案例。
 
@@ -68,7 +68,7 @@ SELECT posts.*, users.* FROM posts
 
 如果由於某些特殊事件導致帖子速率激增，我們不必立即進行時間線交付——我們可以將它們排隊，並接受帖子在粉絲的時間線中顯示會暫時花費更長時間。即使在這種負載峰值期間，時間線仍然可以快速載入，因為我們只是從快取中提供它們。
 
-這種預先計算和更新查詢結果的過程稱為 *物化*，時間線快取是 *物化檢視* 的一個例子（我們將在 [後續章節] 中進一步討論這個概念）。物化檢視加速了讀取，但作為回報，我們必須在寫入時做更多的工作。對於大多數使用者來說，寫入成本是適度的，但社交網路還必須考慮一些極端情況：
+這種預先計算和更新查詢結果的過程稱為 *物化*，時間線快取是 *物化檢視* 的一個例子（我們將在 [待補充連結] 中進一步討論這個概念）。物化檢視加速了讀取，但作為回報，我們必須在寫入時做更多的工作。對於大多數使用者來說，寫入成本是適度的，但社交網路還必須考慮一些極端情況：
 
 * 如果使用者關注非常多的賬戶，並且這些賬戶釋出很多內容，該使用者的物化時間線將有很高的寫入率。然而，在這種情況下，使用者實際上不太可能閱讀其時間線中的所有帖子，因此可以簡單地丟棄其時間線的一些寫入，只向用戶顯示他們關注的賬戶的帖子樣本 [^5]。
 * 當擁有大量粉絲的名人賬戶釋出帖子時，我們必須做大量工作將該帖子插入到他們數百萬粉絲的每個首頁時間線中。在這種情況下，丟棄一些寫入是不可接受的。解決這個問題的一種方法是將名人帖子與其他人的帖子分開處理：我們可以透過將名人帖子單獨儲存並在讀取時與物化時間線合併，來節省將它們新增到數百萬時間線的工作。儘管有這些最佳化，在社交網路上處理名人仍然需要大量基礎設施 [^6]。
@@ -93,7 +93,7 @@ SELECT posts.*, users.* FROM posts
 
 > [!TIP] 當過載系統無法恢復時
 
-如果系統接近過載，吞吐量被推到極限附近，它有時會進入惡性迴圈，變得效率更低，從而更加過載。例如，如果有很長的請求佇列等待處理，響應時間可能會增加到客戶端超時並重新發送請求的程度。這導致請求率進一步增加，使問題變得更糟——*重試風暴*。即使負載再次降低，這樣的系統也可能保持過載狀態，直到重新啟動或以其他方式重置。這種現象稱為 *亞穩態故障*，它可能導致生產系統的嚴重中斷 [^7] [^8]。
+如果系統接近過載，吞吐量被推到極限附近，它有時會進入惡性迴圈，變得效率更低，從而更加過載。例如，如果有很長的請求佇列等待處理，響應時間可能會增加到客戶端超時並重新發送請求的程度。這導致請求率進一步增加，使問題變得更糟——*重試風暴*。即使負載再次降低，這樣的系統也可能保持過載狀態，直到重新啟動或以其他方式重置。這種現象稱為 *亞穩態故障（Metastable Failure）*，它可能導致生產系統的嚴重中斷 [^7] [^8]。
 
 為了避免重試使服務過載，你可以在客戶端增加並隨機化連續重試之間的時間（*指數退避* [^9] [^10]），並暫時停止向最近返回錯誤或超時的服務傳送請求（使用 *熔斷器* [^11] [^12] 或 *令牌桶* 演算法 [^13]）。伺服器還可以檢測何時接近過載並開始主動拒絕請求（*負載卸除* [^14]），併發送響應要求客戶端減速（*背壓* [^1] [^15]）。排隊和負載均衡演算法的選擇也可能產生影響 [^16]。
 
@@ -193,7 +193,7 @@ Akamai 最近的一項研究 [^24] 聲稱響應時間增加 100 毫秒將電子
 
 如果系統在發生某些故障時仍繼續向用戶提供所需的服務，我們稱系統為 *容錯的*。如果系統不能容忍某個部分變得有故障，我們稱該部分為 *單點故障*（SPOF），因為該部分的故障會升級導致整個系統的失效。
 
-例如，在社交網路案例研究中，可能發生的故障是在扇出過程中，參與更新物化時間線的機器崩潰或變得不可用。為了使這個過程容錯，我們需要確保另一臺機器可以接管這項任務，而不會錯過任何應該交付的帖子，也不會複製任何帖子。（這個想法被稱為 *精確一次語義*，我們將在 [後續章節] 中詳細研究它。）
+例如，在社交網路案例研究中，可能發生的故障是在扇出過程中，參與更新物化時間線的機器崩潰或變得不可用。為了使這個過程容錯，我們需要確保另一臺機器可以接管這項任務，而不會錯過任何應該交付的帖子，也不會複製任何帖子。（這個想法被稱為 *精確一次語義*，我們將在 [待補充連結] 中詳細研究它。）
 
 容錯總是限於某些型別的某些數量的故障。例如，系統可能能夠容忍最多兩個硬碟驅動器同時故障，或最多三個節點中的一個崩潰。如果所有節點都崩潰，沒有什麼可以做的，這沒有意義容忍任何數量的故障。如果整個地球（及其上的所有伺服器）被黑洞吞噬，容忍該故障將需要在太空中進行網路託管——祝你獲得批准該預算專案的好運。
 
@@ -319,11 +319,11 @@ Akamai 最近的一項研究 [^24] 聲稱響應時間增加 100 毫秒將電子
 
 此外，適合一個負載級別的架構不太可能應對 10 倍的負載。如果你正在開發快速增長的服務，因此很可能你需要在每個數量級的負載增加時重新考慮你的架構。由於應用程式的需求可能會演變，通常不值得提前規劃超過一個數量級的未來伸縮需求。
 
-可伸縮性的一個良好通用原則是將系統分解為可以在很大程度上相互獨立執行的較小元件。這是微服務背後的基本原則（參見 ["微服務與無伺服器"](/tw/ch1#sec_introduction_microservices)）、分片（[第 7 章](/tw/ch7)）、流處理（[後續章節]）和無共享架構。然而，挑戰在於知道在哪裡劃分應該在一起的事物和應該分開的事物之間的界限。微服務的設計指南可以在其他書籍中找到 [^84]，我們在 [第 7 章](/tw/ch7) 中討論無共享系統的分片。
+可伸縮性的一個良好通用原則是將系統分解為可以在很大程度上相互獨立執行的較小元件。這是微服務背後的基本原則（參見 ["微服務與無伺服器"](/tw/ch1#sec_introduction_microservices)）、分片（[第 7 章](/tw/ch7)）、流處理（[待補充連結]）和無共享架構。然而，挑戰在於知道在哪裡劃分應該在一起的事物和應該分開的事物之間的界限。微服務的設計指南可以在其他書籍中找到 [^84]，我們在 [第 7 章](/tw/ch7) 中討論無共享系統的分片。
 
 另一個好原則是不要讓事情變得比必要的更複雜。如果單機資料庫可以完成工作，它可能比複雜的分散式設定更可取。自動伸縮系統（根據需求自動新增或刪除資源）很酷，但如果你的負載相當可預測，手動伸縮的系統可能會有更少的操作意外（參見 ["操作：自動或手動再平衡"](/tw/ch7#sec_sharding_operations)）。具有五個服務的系統比具有五十個服務的系統更簡單。良好的架構通常涉及方法的務實混合。
 
-## 可運維性 {#sec_introduction_maintainability}
+## 可維護性 {#sec_introduction_maintainability}
 
 軟體不會磨損或遭受材料疲勞，因此它不會像機械物體那樣以同樣的方式損壞。但應用程式的要求經常變化，軟體執行的環境發生變化（例如其依賴項和底層平臺），並且它有需要修復的錯誤。
 

content/zh/ch2.md

@@ -20,7 +20,7 @@ breadcrumbs: false
 * 如何定义和衡量系统的 **性能**（参见 ["描述性能"](/ch2#sec_introduction_percentiles)）；
 * 服务 **可靠** 意味着什么——即即使出现问题也能继续正确工作（参见 ["可靠性与容错"](/ch2#sec_introduction_reliability)）；
 * 通过在系统负载增长时添加计算能力的有效方法，使系统具有 **可伸缩性**（参见 ["可伸缩性"](/ch2#sec_introduction_scalability)）；以及
-* 使系统长期更 **易于维护**（参见 ["可运维性"](/ch2#sec_introduction_maintainability)）。
+* 使系统长期更 **易于维护**（参见 ["可维护性"](/ch2#sec_introduction_maintainability)）。
 
 本章介绍的术语在后续章节中也很有用，当我们深入研究数据密集型系统的实现细节时。然而，抽象定义可能相当枯燥；为了使这些想法更具体，我们将从一个案例研究开始本章，研究社交网络服务可能如何工作，这将提供性能和可伸缩性的实际案例。
 
@@ -68,7 +68,7 @@ SELECT posts.*, users.* FROM posts
 
 如果由于某些特殊事件导致帖子速率激增，我们不必立即进行时间线交付——我们可以将它们排队，并接受帖子在粉丝的时间线中显示会暂时花费更长时间。即使在这种负载峰值期间，时间线仍然可以快速加载，因为我们只是从缓存中提供它们。
 
-这种预先计算和更新查询结果的过程称为 *物化*，时间线缓存是 *物化视图* 的一个例子（我们将在 [后续章节] 中进一步讨论这个概念）。物化视图加速了读取，但作为回报，我们必须在写入时做更多的工作。对于大多数用户来说，写入成本是适度的，但社交网络还必须考虑一些极端情况：
+这种预先计算和更新查询结果的过程称为 *物化*，时间线缓存是 *物化视图* 的一个例子（我们将在 [待补充链接] 中进一步讨论这个概念）。物化视图加速了读取，但作为回报，我们必须在写入时做更多的工作。对于大多数用户来说，写入成本是适度的，但社交网络还必须考虑一些极端情况：
 
 * 如果用户关注非常多的账户，并且这些账户发布很多内容，该用户的物化时间线将有很高的写入率。然而，在这种情况下，用户实际上不太可能阅读其时间线中的所有帖子，因此可以简单地丢弃其时间线的一些写入，只向用户显示他们关注的账户的帖子样本 [^5]。
 * 当拥有大量粉丝的名人账户发布帖子时，我们必须做大量工作将该帖子插入到他们数百万粉丝的每个首页时间线中。在这种情况下，丢弃一些写入是不可接受的。解决这个问题的一种方法是将名人帖子与其他人的帖子分开处理：我们可以通过将名人帖子单独存储并在读取时与物化时间线合并，来节省将它们添加到数百万时间线的工作。尽管有这些优化，在社交网络上处理名人仍然需要大量基础设施 [^6]。
@@ -193,7 +193,7 @@ Akamai 最近的一项研究 [^24] 声称响应时间增加 100 毫秒将电子
 
 如果系统在发生某些故障时仍继续向用户提供所需的服务，我们称系统为 *容错的*。如果系统不能容忍某个部分变得有故障，我们称该部分为 *单点故障*（SPOF），因为该部分的故障会升级导致整个系统的失效。
 
-例如，在社交网络案例研究中，可能发生的故障是在扇出过程中，参与更新物化时间线的机器崩溃或变得不可用。为了使这个过程容错，我们需要确保另一台机器可以接管这项任务，而不会错过任何应该交付的帖子，也不会复制任何帖子。（这个想法被称为 *精确一次语义*，我们将在 [后续章节] 中详细研究它。）
+例如，在社交网络案例研究中，可能发生的故障是在扇出过程中，参与更新物化时间线的机器崩溃或变得不可用。为了使这个过程容错，我们需要确保另一台机器可以接管这项任务，而不会错过任何应该交付的帖子，也不会复制任何帖子。（这个想法被称为 *精确一次语义*，我们将在 [待补充链接] 中详细研究它。）
 
 容错总是限于某些类型的某些数量的故障。例如，系统可能能够容忍最多两个硬盘驱动器同时故障，或最多三个节点中的一个崩溃。如果所有节点都崩溃，没有什么可以做的，这没有意义容忍任何数量的故障。如果整个地球（及其上的所有服务器）被黑洞吞噬，容忍该故障将需要在太空中进行网络托管——祝你获得批准该预算项目的好运。
 
@@ -319,11 +319,11 @@ Akamai 最近的一项研究 [^24] 声称响应时间增加 100 毫秒将电子
 
 此外，适合一个负载级别的架构不太可能应对 10 倍的负载。如果你正在开发快速增长的服务，因此很可能你需要在每个数量级的负载增加时重新考虑你的架构。由于应用程序的需求可能会演变，通常不值得提前规划超过一个数量级的未来伸缩需求。
 
-可伸缩性的一个良好通用原则是将系统分解为可以在很大程度上相互独立运行的较小组件。这是微服务背后的基本原则（参见 ["微服务与无服务器"](/ch1#sec_introduction_microservices)）、分片（[第 7 章](/ch7)）、流处理（[后续章节]）和无共享架构。然而，挑战在于知道在哪里划分应该在一起的事物和应该分开的事物之间的界限。微服务的设计指南可以在其他书籍中找到 [^84]，我们在 [第 7 章](/ch7) 中讨论无共享系统的分片。
+可伸缩性的一个良好通用原则是将系统分解为可以在很大程度上相互独立运行的较小组件。这是微服务背后的基本原则（参见 ["微服务与无服务器"](/ch1#sec_introduction_microservices)）、分片（[第 7 章](/ch7)）、流处理（[待补充链接]）和无共享架构。然而，挑战在于知道在哪里划分应该在一起的事物和应该分开的事物之间的界限。微服务的设计指南可以在其他书籍中找到 [^84]，我们在 [第 7 章](/ch7) 中讨论无共享系统的分片。
 
 另一个好原则是不要让事情变得比必要的更复杂。如果单机数据库可以完成工作，它可能比复杂的分布式设置更可取。自动伸缩系统（根据需求自动添加或删除资源）很酷，但如果你的负载相当可预测，手动伸缩的系统可能会有更少的操作意外（参见 ["操作：自动或手动再平衡"](/ch7#sec_sharding_operations)）。具有五个服务的系统比具有五十个服务的系统更简单。良好的架构通常涉及方法的务实混合。
 
-## 可运维性 {#sec_introduction_maintainability}
+## 可维护性 {#sec_introduction_maintainability}
 
 软件不会磨损或遭受材料疲劳，因此它不会像机械物体那样以同样的方式损坏。但应用程序的要求经常变化，软件运行的环境发生变化（例如其依赖项和底层平台），并且它有需要修复的错误。