From c4da84772c4f03d5696fb74cc71e91d84b0e1cfa Mon Sep 17 00:00:00 2001 From: kimi Date: Thu, 23 Nov 2023 10:20:15 +0800 Subject: [PATCH] =?UTF-8?q?fix:=20zh-tw=20=E6=97=A5=E5=BF=97=20to=20?= =?UTF-8?q?=E6=97=A5=E8=AA=8C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- zh-tw/ch3.md | 4 ++-- zh-tw/ch9.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zh-tw/ch3.md b/zh-tw/ch3.md index bb3d1b4..0861c2d 100644 --- 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 index f046e6c..05f03b5 100644 --- a/zh-tw/ch9.md +++ b/zh-tw/ch9.md @@ -506,7 +506,7 @@ CAP 定理的正式定義僅限於很狹隘的範圍【30】，它只考慮了 1. 在日誌中追加一條訊息，試探性地指明你要宣告的使用者名稱。 2. 讀日誌，並等待你剛才追加的訊息被讀回。[^xi] -4. 檢查是否有任何訊息聲稱目標使用者名稱的所有權。如果這些訊息中的第一條就是你自己的訊息，那麼你就成功了：你可以提交聲稱的使用者名稱（也許是透過向日志追加另一條訊息）並向客戶端確認。如果所需使用者名稱的第一條訊息來自其他使用者，則中止操作。 +4. 檢查是否有任何訊息聲稱目標使用者名稱的所有權。如果這些訊息中的第一條就是你自己的訊息，那麼你就成功了：你可以提交聲稱的使用者名稱（也許是透過向日誌追加另一條訊息）並向客戶端確認。如果所需使用者名稱的第一條訊息來自其他使用者，則中止操作。 [^xi]: 如果你不等待，而是在訊息入隊之後立即確認寫入，則會得到類似於多核 x86 處理器記憶體的一致性模型【43】。該模型既不是線性一致的也不是順序一致的。 @@ -1055,5 +1055,5 @@ ZooKeeper 和它的小夥伴們可以看作是成員資格服務（membership se ------ | 上一章 | 目錄 | 下一章 | -| ---------------------------------- | ------------------------------- | --------------------------------- | +|------------------------------------|---------------------------------|-----------------------------------| | [第八章：分散式系統的麻煩](ch8.md) | [設計資料密集型應用](README.md) | [第三部分：衍生資料](part-iii.md) |