Vonng · yingang · Nov 23, 2023 · Nov 23, 2023 · Nov 23, 2023
diff --git a/bin/zh-tw.py b/bin/zh-tw.py
@@ -17,6 +17,7 @@ def convert(src_path, dst_path, cfg='s2twp.json'):
                 .replace('倒黴', '倒楣')
                 .replace('區域性性', '區域性')
                 .replace('下麵', '下面')
+                .replace('日志', '日誌')
                 for line in src))
     print("convert %s to %s" % (src_path, dst_path))
 

diff --git a/zh-tw/ch3.md b/zh-tw/ch3.md
@@ -92,7 +92,7 @@ $ cat database
 
 像 Bitcask 這樣的儲存引擎非常適合每個鍵的值經常更新的情況。例如，鍵可能是某個貓咪影片的網址（URL），而值可能是該影片被播放的次數（每次有人點選播放按鈕時遞增）。在這種型別的工作負載中，有很多寫操作，但是沒有太多不同的鍵 —— 每個鍵有很多的寫操作，但是將所有鍵儲存在記憶體中是可行的。
 
-到目前為止，我們只是在追加寫入一個檔案 —— 所以如何避免最終用完硬碟空間？一種好的解決方案是，將日誌分為特定大小的 **段（segment）**，當日志增長到特定尺寸時關閉當前段檔案，並開始寫入一個新的段檔案。然後，我們就可以對這些段進行 **壓縮（compaction）**，如 [圖 3-2](../img/fig3-2.png) 所示。這裡的壓縮意味著在日誌中丟棄重複的鍵，只保留每個鍵的最近更新。
+到目前為止，我們只是在追加寫入一個檔案 —— 所以如何避免最終用完硬碟空間？一種好的解決方案是，將日誌分為特定大小的 **段（segment）**，當日誌增長到特定尺寸時關閉當前段檔案，並開始寫入一個新的段檔案。然後，我們就可以對這些段進行 **壓縮（compaction）**，如 [圖 3-2](../img/fig3-2.png) 所示。這裡的壓縮意味著在日誌中丟棄重複的鍵，只保留每個鍵的最近更新。
 
 ![](../img/fig3-2.png)
 
@@ -114,7 +114,7 @@ $ cat database
 
 * 刪除記錄
 
-  如果要刪除一個鍵及其關聯的值，則必須在資料檔案中追加一個特殊的刪除記錄（邏輯刪除，有時被稱為墓碑，即 tombstone）。當日志段被合併時，合併過程會透過這個墓碑知道要將被刪除鍵的所有歷史值都丟棄掉。
+  如果要刪除一個鍵及其關聯的值，則必須在資料檔案中追加一個特殊的刪除記錄（邏輯刪除，有時被稱為墓碑，即 tombstone）。當日誌段被合併時，合併過程會透過這個墓碑知道要將被刪除鍵的所有歷史值都丟棄掉。
 
 * 崩潰恢復
 

diff --git a/zh-tw/ch9.md b/zh-tw/ch9.md
@@ -506,7 +506,7 @@ CAP 定理的正式定義僅限於很狹隘的範圍【30】，它只考慮了
 
 1. 在日誌中追加一條訊息，試探性地指明你要宣告的使用者名稱。
 2. 讀日誌，並等待你剛才追加的訊息被讀回。[^xi]
-4. 檢查是否有任何訊息聲稱目標使用者名稱的所有權。如果這些訊息中的第一條就是你自己的訊息，那麼你就成功了：你可以提交聲稱的使用者名稱（也許是透過向日志追加另一條訊息）並向客戶端確認。如果所需使用者名稱的第一條訊息來自其他使用者，則中止操作。
+4. 檢查是否有任何訊息聲稱目標使用者名稱的所有權。如果這些訊息中的第一條就是你自己的訊息，那麼你就成功了：你可以提交聲稱的使用者名稱（也許是透過向日誌追加另一條訊息）並向客戶端確認。如果所需使用者名稱的第一條訊息來自其他使用者，則中止操作。
 
 [^xi]: 如果你不等待，而是在訊息入隊之後立即確認寫入，則會得到類似於多核 x86 處理器記憶體的一致性模型【43】。該模型既不是線性一致的也不是順序一致的。