fix several section links

skyran1278 · Jan 20, 2022 · 34fdbe2 · 34fdbe2
1 parent 7f7bcad
commit 34fdbe2
Show file tree

Hide file tree

Showing 6 changed files with 6 additions and 6 deletions.
diff --git a/ch1.md b/ch1.md
@@ -256,7 +256,7 @@
 
 人们经常讨论 **纵向伸缩**（scaling up，也称为垂直伸缩，即 vertical scaling，转向更强大的机器）和 **横向伸缩**（scaling out，也称为水平伸缩，即 horizontal scaling，将负载分布到多台小机器上）之间的对立。跨多台机器分配负载也称为 “**无共享（shared-nothing）**” 架构。可以在单台机器上运行的系统通常更简单，但高端机器可能非常贵，所以非常密集的负载通常无法避免地需要横向伸缩。现实世界中的优秀架构需要将这两种方法务实地结合，因为使用几台足够强大的机器可能比使用大量的小型虚拟机更简单也更便宜。
 
-有些系统是 **弹性（elastic）** 的，这意味着可以在检测到负载增加时自动增加计算资源，而其他系统则是手动伸缩（人工分析容量并决定向系统添加更多的机器）。如果负载 **极难预测（highly unpredictable）**，则弹性系统可能很有用，但手动伸缩系统更简单，并且意外操作可能会更少（请参阅 “[分区再平衡](ch6.md# 分区再平衡)”）。
+有些系统是 **弹性（elastic）** 的，这意味着可以在检测到负载增加时自动增加计算资源，而其他系统则是手动伸缩（人工分析容量并决定向系统添加更多的机器）。如果负载 **极难预测（highly unpredictable）**，则弹性系统可能很有用，但手动伸缩系统更简单，并且意外操作可能会更少（请参阅 “[分区再平衡](ch6.md#分区再平衡)”）。
 
 跨多台机器部署 **无状态服务（stateless services）** 非常简单，但将带状态的数据系统从单节点变为分布式配置则可能引入许多额外复杂度。出于这个原因，常识告诉我们应该将数据库放在单个节点上（纵向伸缩），直到伸缩成本或可用性需求迫使其改为分布式。
 

diff --git a/ch5.md b/ch5.md
@@ -622,7 +622,7 @@ Dynamo 风格的数据库允许多个客户端同时写入相同的 Key，这意
 
 即使写入没有自然的排序，我们也可以强制任意排序。例如，可以为每个写入附加一个时间戳，挑选最 **“最近”** 的最大时间戳，并丢弃具有较早时间戳的任何写入。这种冲突解决算法被称为 **最后写入胜利（LWW, last write wins）**，是 Cassandra 【53】唯一支持的冲突解决方法，也是 Riak 【35】中的一个可选特征。
 
-LWW 实现了最终收敛的目标，但以 **持久性** 为代价：如果同一个 Key 有多个并发写入，即使它们报告给客户端的都是成功（因为它们被写入 w 个副本），也只有一个写入将存活，而其他写入将被静默丢弃。此外，LWW 甚至可能会删除不是并发的写入，我们将在的 “[有序事件的时间戳](ch8.md# 有序事件的时间戳)” 中讨论。
+LWW 实现了最终收敛的目标，但以 **持久性** 为代价：如果同一个 Key 有多个并发写入，即使它们报告给客户端的都是成功（因为它们被写入 w 个副本），也只有一个写入将存活，而其他写入将被静默丢弃。此外，LWW 甚至可能会删除不是并发的写入，我们将在的 “[有序事件的时间戳](ch8.md#有序事件的时间戳)” 中讨论。
 
 有一些情况，如缓存，其中丢失的写入可能是可以接受的。如果丢失数据不可接受，LWW 是解决冲突的一个很烂的选择。
 

diff --git a/ch7.md b/ch7.md
@@ -72,7 +72,7 @@ ACID 原子性的定义特征是：**能够在错误时中止事务，丢弃该
 
 * 在 [第五章](ch5.md) 中，我们讨论了副本一致性，以及异步复制系统中的最终一致性问题（请参阅 “[复制延迟问题](ch5.md#复制延迟问题)”）。
 * [一致性哈希](ch6.md#一致性哈希) 是某些系统用于重新分区的一种分区方法。
-* 在 [CAP 定理](ch9.md#CAP 定理) 中，一致性一词用于表示 [线性一致性](ch9.md#线性一致性)。
+* 在 [CAP 定理](ch9.md#CAP定理) 中，一致性一词用于表示 [线性一致性](ch9.md#线性一致性)。
 * 在 ACID 的上下文中，**一致性** 是指数据库在应用程序的特定概念中处于 “良好状态”。
 
 很不幸，这一个词就至少有四种不同的含义。

diff --git a/zh-tw/ch1.md b/zh-tw/ch1.md
@@ -256,7 +256,7 @@
 
 人們經常討論 **縱向伸縮**（scaling up，也稱為垂直伸縮，即 vertical scaling，轉向更強大的機器）和 **橫向伸縮**（scaling out，也稱為水平伸縮，即 horizontal scaling，將負載分佈到多臺小機器上）之間的對立。跨多臺機器分配負載也稱為 “**無共享（shared-nothing）**” 架構。可以在單臺機器上執行的系統通常更簡單，但高階機器可能非常貴，所以非常密集的負載通常無法避免地需要橫向伸縮。現實世界中的優秀架構需要將這兩種方法務實地結合，因為使用幾臺足夠強大的機器可能比使用大量的小型虛擬機器更簡單也更便宜。
 
-有些系統是 **彈性（elastic）** 的，這意味著可以在檢測到負載增加時自動增加計算資源，而其他系統則是手動伸縮（人工分析容量並決定向系統新增更多的機器）。如果負載 **極難預測（highly unpredictable）**，則彈性系統可能很有用，但手動伸縮系統更簡單，並且意外操作可能會更少（請參閱 “[分割槽再平衡](ch6.md# 分割槽再平衡)”）。
+有些系統是 **彈性（elastic）** 的，這意味著可以在檢測到負載增加時自動增加計算資源，而其他系統則是手動伸縮（人工分析容量並決定向系統新增更多的機器）。如果負載 **極難預測（highly unpredictable）**，則彈性系統可能很有用，但手動伸縮系統更簡單，並且意外操作可能會更少（請參閱 “[分割槽再平衡](ch6.md#分割槽再平衡)”）。
 
 跨多臺機器部署 **無狀態服務（stateless services）** 非常簡單，但將帶狀態的資料系統從單節點變為分散式配置則可能引入許多額外複雜度。出於這個原因，常識告訴我們應該將資料庫放在單個節點上（縱向伸縮），直到伸縮成本或可用性需求迫使其改為分散式。
 

diff --git a/zh-tw/ch5.md b/zh-tw/ch5.md
@@ -622,7 +622,7 @@ Dynamo 風格的資料庫允許多個客戶端同時寫入相同的 Key，這意
 
 即使寫入沒有自然的排序，我們也可以強制任意排序。例如，可以為每個寫入附加一個時間戳，挑選最 **“最近”** 的最大時間戳，並丟棄具有較早時間戳的任何寫入。這種衝突解決演算法被稱為 **最後寫入勝利（LWW, last write wins）**，是 Cassandra 【53】唯一支援的衝突解決方法，也是 Riak 【35】中的一個可選特徵。
 
-LWW 實現了最終收斂的目標，但以 **永續性** 為代價：如果同一個 Key 有多個併發寫入，即使它們報告給客戶端的都是成功（因為它們被寫入 w 個副本），也只有一個寫入將存活，而其他寫入將被靜默丟棄。此外，LWW 甚至可能會刪除不是併發的寫入，我們將在的 “[有序事件的時間戳](ch8.md# 有序事件的時間戳)” 中討論。
+LWW 實現了最終收斂的目標，但以 **永續性** 為代價：如果同一個 Key 有多個併發寫入，即使它們報告給客戶端的都是成功（因為它們被寫入 w 個副本），也只有一個寫入將存活，而其他寫入將被靜默丟棄。此外，LWW 甚至可能會刪除不是併發的寫入，我們將在的 “[有序事件的時間戳](ch8.md#有序事件的時間戳)” 中討論。
 
 有一些情況，如快取，其中丟失的寫入可能是可以接受的。如果丟失資料不可接受，LWW 是解決衝突的一個很爛的選擇。
 

diff --git a/zh-tw/ch7.md b/zh-tw/ch7.md
@@ -72,7 +72,7 @@ ACID 原子性的定義特徵是：**能夠在錯誤時中止事務，丟棄該
 
 * 在 [第五章](ch5.md) 中，我們討論了副本一致性，以及非同步複製系統中的最終一致性問題（請參閱 “[複製延遲問題](ch5.md#複製延遲問題)”）。
 * [一致性雜湊](ch6.md#一致性雜湊) 是某些系統用於重新分割槽的一種分割槽方法。
-* 在 [CAP 定理](ch9.md#CAP 定理) 中，一致性一詞用於表示 [線性一致性](ch9.md#線性一致性)。
+* 在 [CAP 定理](ch9.md#CAP定理) 中，一致性一詞用於表示 [線性一致性](ch9.md#線性一致性)。
 * 在 ACID 的上下文中，**一致性** 是指資料庫在應用程式的特定概念中處於 “良好狀態”。
 
 很不幸，這一個詞就至少有四種不同的含義。