fix zh-tw.py and add comments

bin/zh-tw.py

@@ -11,14 +11,14 @@ def convert(src_path, dst_path, cfg='s2twp.json'):
                 .replace('髮生', '發生')
                 .replace('髮出', '發出')
                 .replace('嚐試', '嘗試')
-                .replace('線上性', '線性')
+                .replace('線上性一致', '在線性一致')    # 优先按“在线”解析了？
                 .replace('復雜', '複雜')
                 .replace('討論瞭', '討論了')
                 .replace('倒黴', '倒楣')
                 .replace('區域性性', '區域性')
-                .replace('下麵', '下面')
-                .replace('日志', '日誌')
-                .replace('真即時間', '真實時間')
+                .replace('下麵條件', '下面條件')        # 优先按“面条”解析了？
+                .replace('當日志', '當日誌')            # 优先按“当日”解析了，没有考虑后面的“日志”？
+                .replace('真即時間', '真實時間')        # 优先按“实时”解析了，没有考虑前面的“真实”？
                 for line in src))
     print("convert %s to %s" % (src_path, dst_path))
 

zh-tw/ch9.md

@@ -69,7 +69,7 @@
 
 線性一致性背後的基本思想很簡單：使系統看起來好像只有一個數據副本。然而確切來講，實際上有更多要操心的地方。為了更好地理解線性一致性，讓我們再看幾個例子。
 
-[圖 9-2](../img/fig9-2.png) 顯示了三個客戶端線性一致資料庫中同時讀寫相同的鍵 `x`。在分散式系統文獻中，`x` 被稱為 **暫存器（register）**，例如，它可以是鍵值儲存中的一個 **鍵**，關係資料庫中的一 **行**，或文件資料庫中的一個 **文件**。
+[圖 9-2](../img/fig9-2.png) 顯示了三個客戶端在線性一致資料庫中同時讀寫相同的鍵 `x`。在分散式系統文獻中，`x` 被稱為 **暫存器（register）**，例如，它可以是鍵值儲存中的一個 **鍵**，關係資料庫中的一 **行**，或文件資料庫中的一個 **文件**。
 
 ![](../img/fig9-2.png)
 
@@ -249,7 +249,7 @@
 
 ![](../img/fig9-7.png)
 
-**圖 9-7 網路中斷迫使線性一致性和可用性之間做出選擇。**
+**圖 9-7 網路中斷迫使在線性一致性和可用性之間做出選擇。**
 
 考慮這樣一種情況：如果兩個資料中心之間發生網路中斷會發生什麼？我們假設每個資料中心內的網路正在工作，客戶端可以訪問資料中心，但資料中心之間彼此無法互相連線。
 
@@ -278,7 +278,7 @@ CAP 最初是作為一個經驗法則提出的，沒有準確的定義，目的
 >
 > CAP 有時以這種面目出現：一致性，可用性和分割槽容錯性：三者只能擇其二。不幸的是這種說法很有誤導性【32】，因為網路分割槽是一種故障型別，所以它並不是一個選項：不管你喜不喜歡它都會發生【38】。
 >
-> 在網路正常工作的時候，系統可以提供一致性（線性一致性）和整體可用性。發生網路故障時，你必須線性一致性和整體可用性之間做出選擇。因此，CAP 更好的表述成：在分割槽時要麼選擇一致，要麼選擇可用【39】。一個更可靠的網路需要減少這個選擇，但是在某些時候選擇是不可避免的。
+> 在網路正常工作的時候，系統可以提供一致性（線性一致性）和整體可用性。發生網路故障時，你必須在線性一致性和整體可用性之間做出選擇。因此，CAP 更好的表述成：在分割槽時要麼選擇一致，要麼選擇可用【39】。一個更可靠的網路需要減少這個選擇，但是在某些時候選擇是不可避免的。
 >
 > 在 CAP 的討論中，術語可用性有幾個相互矛盾的定義，形式化作為一個定理【30】並不符合其通常的含義【40】。許多所謂的 “高可用”（容錯）系統實際上不符合 CAP 對可用性的特殊定義。總而言之，圍繞著 CAP 有很多誤解和困惑，並不能幫助我們更好地理解系統，所以最好避免使用 CAP。
 
@@ -341,13 +341,13 @@ CAP 定理的正式定義僅限於很狹隘的範圍【30】，它只考慮了
 
 * 線性一致性
 
-  線性一致的系統中，操作是全序的：如果系統表現的就好像只有一個數據副本，並且所有操作都是原子性的，這意味著對任何兩個操作，我們總是能判定哪個操作先發生。這個全序在 [圖 9-4](../img/fig9-4.png) 中以時間線表示。
+  在線性一致的系統中，操作是全序的：如果系統表現的就好像只有一個數據副本，並且所有操作都是原子性的，這意味著對任何兩個操作，我們總是能判定哪個操作先發生。這個全序在 [圖 9-4](../img/fig9-4.png) 中以時間線表示。
 
 * 因果性
 
   我們說過，如果兩個操作都沒有在彼此 **之前發生**，那麼這兩個操作是併發的（請參閱 [“此前發生” 的關係和併發](ch5.md#“此前發生”的關係和併發)）。換句話說，如果兩個事件是因果相關的（一個發生在另一個事件之前），則它們之間是有序的，但如果它們是併發的，則它們之間的順序是無法比較的。這意味著因果關係定義了一個偏序，而不是一個全序：一些操作相互之間是有順序的，但有些則是無法比較的。
 
-因此，根據這個定義，線性一致的資料儲存中是不存在併發操作的：必須有且僅有一條時間線，所有的操作都在這條時間線上，構成一個全序關係。可能有幾個請求在等待處理，但是資料儲存確保了每個請求都是在唯一時間線上的某個時間點自動處理的，不存在任何併發。
+因此，根據這個定義，在線性一致的資料儲存中是不存在併發操作的：必須有且僅有一條時間線，所有的操作都在這條時間線上，構成一個全序關係。可能有幾個請求在等待處理，但是資料儲存確保了每個請求都是在唯一時間線上的某個時間點自動處理的，不存在任何併發。
 
 併發意味著時間線會分岔然後合併 —— 在這種情況下，不同分支上的操作是無法比較的（即併發操作）。在 [第五章](ch5.md) 中我們看到了這種現象：例如，[圖 5-14](../img/fig5-14.png) 並不是一條直線的全序關係，而是一堆不同的操作併發進行。圖中的箭頭指明瞭因果依賴 —— 操作的偏序。
 
@@ -492,7 +492,7 @@ CAP 定理的正式定義僅限於很狹隘的範圍【30】，它只考慮了
 
 #### 使用全序廣播實現線性一致的儲存
 
-如 [圖 9-4](../img/fig9-4.png) 所示，線性一致的系統中，存在操作的全序。這是否意味著線性一致與全序廣播一樣？不盡然，但兩者之間有著密切的聯絡 [^x]。
+如 [圖 9-4](../img/fig9-4.png) 所示，在線性一致的系統中，存在操作的全序。這是否意味著線性一致與全序廣播一樣？不盡然，但兩者之間有著密切的聯絡 [^x]。
 
 [^x]: 從形式上講，線性一致讀寫暫存器是一個 “更容易” 的問題。全序廣播等價於共識【67】，而共識問題在非同步的崩潰 - 停止模型【68】中沒有確定性的解決方案，而線性一致的讀寫暫存器 **可以** 在這種模型中實現【23,24,25】。然而，支援諸如 **比較並設定（CAS, compare-and-set）**，或 **自增並返回（increment-and-get）** 的原子操作使它等價於共識問題【28】。因此，共識問題與線性一致暫存器問題密切相關。
 
@@ -506,7 +506,7 @@ CAP 定理的正式定義僅限於很狹隘的範圍【30】，它只考慮了
 
 1. 在日誌中追加一條訊息，試探性地指明你要宣告的使用者名稱。
 2. 讀日誌，並等待你剛才追加的訊息被讀回。[^xi]
-4. 檢查是否有任何訊息聲稱目標使用者名稱的所有權。如果這些訊息中的第一條就是你自己的訊息，那麼你就成功了：你可以提交聲稱的使用者名稱（也許是透過向日誌追加另一條訊息）並向客戶端確認。如果所需使用者名稱的第一條訊息來自其他使用者，則中止操作。
+4. 檢查是否有任何訊息聲稱目標使用者名稱的所有權。如果這些訊息中的第一條就是你自己的訊息，那麼你就成功了：你可以提交聲稱的使用者名稱（也許是透過向日志追加另一條訊息）並向客戶端確認。如果所需使用者名稱的第一條訊息來自其他使用者，則中止操作。
 
 [^xi]: 如果你不等待，而是在訊息入隊之後立即確認寫入，則會得到類似於多核 x86 處理器記憶體的一致性模型【43】。該模型既不是線性一致的也不是順序一致的。