From 902baf448cd5325fc5722f1c1ad954924029b74f Mon Sep 17 00:00:00 2001 From: Komoriii Date: Wed, 18 Nov 2020 19:49:19 +0800 Subject: [PATCH] fixed zh-tw translation of "the battle cry" --- zh-tw/ch5.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh-tw/ch5.md b/zh-tw/ch5.md index deddadb..8be509e 100644 --- a/zh-tw/ch5.md +++ b/zh-tw/ch5.md @@ -193,7 +193,7 @@ ​ 不幸的是，當應用程式從非同步從庫讀取時，如果從庫落後，它可能會看到過時的資訊。這會導致資料庫中出現明顯的不一致：同時對主庫和從庫執行相同的查詢，可能得到不同的結果，因為並非所有的寫入都反映在從庫中。這種不一致只是一個暫時的狀態——如果停止寫入資料庫並等待一段時間，從庫最終會趕上並與主庫保持一致。出於這個原因，這種效應被稱為 **最終一致性（eventually consistency）**[^iii]【22,23】 -[^iii]: 道格拉斯·特里（Douglas Terry）等人創造了術語最終一致性。 【24】 並經由Werner Vogels 【22】推廣，成為許多NoSQL專案的戰吼。 然而，不只有NoSQL資料庫是最終一致的：關係型資料庫中的非同步複製追隨者也有相同的特性。 +[^iii]: 道格拉斯·特里（Douglas Terry）等人創造了術語最終一致性。 【24】 並經由Werner Vogels 【22】推廣，成為許多NoSQL專案的標語。 然而，不只有NoSQL資料庫是最終一致的：關係型資料庫中的非同步複製追隨者也有相同的特性。 ​ “最終”一詞故意含糊不清：總的來說，副本落後的程度是沒有限制的。在正常的操作中，**複製延遲（replication lag）**，即寫入主庫到反映至從庫之間的延遲，可能僅僅是幾分之一秒，在實踐中並不顯眼。但如果系統在接近極限的情況下執行，或網路中存在問題，延遲可以輕而易舉地超過幾秒，甚至幾分鐘。