update zh-tw content

zh-tw/ch5.md

@@ -559,7 +559,7 @@
 * 如果寫操作與讀操作同時發生，寫操作可能僅反映在某些副本上。在這種情況下，不確定讀取是返回舊值還是新值。
 * 如果寫操作在某些副本上成功，而在其他節點上失敗（例如，因為某些節點上的磁碟已滿），在小於w個副本上寫入成功。所以整體判定寫入失敗，但整體寫入失敗並沒有在寫入成功的副本上回滾。這意味著如果一個寫入雖然報告失敗，後續的讀取仍然可能會讀取這次失敗寫入的值【47】。
 * 如果攜帶新值的節點失敗，需要讀取其他帶有舊值的副本。並且其資料從帶有舊值的副本中恢復，則儲存新值的副本數可能會低於w，從而打破法定人數條件。
-* 即使一切工作正常，有時也會不幸地出現關於**時序（timing）** 的邊緣情況，我們將在**“[線性一致性和法定人數](ch9.md#線性一致性和法定人數)”中看到這點。
+* 即使一切工作正常，有時也會不幸地出現關於**時序（timing）** 的邊緣情況，我們將在“[線性一致性和法定人數](ch9.md#線性一致性和法定人數)”中看到這點。
 
 因此，儘管法定人數似乎保證讀取返回最新的寫入值，但在實踐中並不那麼簡單。 Dynamo風格的資料庫通常針對可以忍受最終一致性的用例進行最佳化。允許透過引數w和r來調整讀取陳舊值的概率，但把它們當成絕對的保證是不明智的。
 

zh-tw/ch9.md

@@ -657,7 +657,7 @@
 
 #### 三階段提交
 
-​	兩階段提交被稱為**阻塞（blocking）**原子提交協議，因為存在2PC可能卡住並等待協調者恢復的情況。理論上，可以使一個原子提交協議變為**非阻塞（nonblocking）**的，以便在節點失敗時不會卡住。但是讓這個協議能在實踐中工作並沒有那麼簡單。
+​	兩階段提交被稱為**阻塞（blocking）**- 原子提交協議，因為存在2PC可能卡住並等待協調者恢復的情況。理論上，可以使一個原子提交協議變為**非阻塞（nonblocking）** 的，以便在節點失敗時不會卡住。但是讓這個協議能在實踐中工作並沒有那麼簡單。
 
 ​	作為2PC的替代方案，已經提出了一種稱為**三階段提交（3PC）** 的演算法【13,80】。然而，3PC假定網路延遲有界，節點響應時間有限；在大多數具有無限網路延遲和程序暫停的實際系統中（見[第八章](ch8.md)），它並不能保證原子性。
 
@@ -689,7 +689,7 @@
 
 ​	如果訊息傳遞或資料庫事務任意一者失敗，兩者都會中止，因此訊息代理可能會在稍後安全地重傳訊息。因此，透過原子提交**訊息處理及其副作用**，即使在成功之前需要幾次重試，也可以確保訊息被**有效地（effectively）** 恰好處理一次。中止會拋棄部分完成事務所導致的任何副作用。
 
-​	然而，只有當所有受事務影響的系統都使用同樣的**原子提交協議（atomic commit protocl）**時，這樣的分散式事務才是可能的。例如，假設處理訊息的副作用是傳送一封郵件，而郵件伺服器並不支援兩階段提交：如果訊息處理失敗並重試，則可能會發送兩次或更多次的郵件。但如果處理訊息的所有副作用都可以在事務中止時回滾，那麼這樣的處理流程就可以安全地重試，就好像什麼都沒有發生過一樣。
+​	然而，只有當所有受事務影響的系統都使用同樣的**原子提交協議（atomic commit protocol）** 時，這樣的分散式事務才是可能的。例如，假設處理訊息的副作用是傳送一封郵件，而郵件伺服器並不支援兩階段提交：如果訊息處理失敗並重試，則可能會發送兩次或更多次的郵件。但如果處理訊息的所有副作用都可以在事務中止時回滾，那麼這樣的處理流程就可以安全地重試，就好像什麼都沒有發生過一樣。
 
 ​	在[第十一章](ch11.md)中將再次回到“恰好一次”訊息處理的主題。讓我們先來看看允許這種異構分散式事務的原子提交協議。