fix: ch5 inconsistent translation

ch5.md

@@ -683,7 +683,7 @@ LWW 实现了最终收敛的目标，但以 **持久性** 为代价：如果同
 
 合并并发值，本质上是与多主复制中的冲突解决问题相同，我们先前讨论过（请参阅 “[处理写入冲突](#处理写入冲突)”）。一个简单的方法是根据版本号或时间戳（最后写入胜利）来选择一个值，但这意味着丢失数据。所以，你可能需要在应用程序代码中额外做些更聪明的事情。
 
-以购物车为例，一种合理的合并值的方法就是做并集。在 [图 5-14](img/fig5-14.png) 中，最后的两个兄弟是 [牛奶，面粉，鸡蛋，熏肉] 和 [鸡蛋，牛奶，火腿]。注意牛奶和鸡蛋虽然同时出现在两个并发值里，但他们每个只被写过一次。合并的值可以是 [牛奶，面粉，鸡蛋，培根，火腿]，不再有重复了。
+以购物车为例，一种合理的合并值的方法就是做并集。在 [图 5-14](img/fig5-14.png) 中，最后的两个兄弟是 [牛奶，面粉，鸡蛋，培根] 和 [鸡蛋，牛奶，火腿]。注意牛奶和鸡蛋虽然同时出现在两个并发值里，但他们每个只被写过一次。合并的值可以是 [牛奶，面粉，鸡蛋，培根，火腿]，不再有重复了。
 
 然而，如果你想让人们也可以从他们的购物车中 **移除** 东西，而不是仅仅添加东西，那么把并发值做并集可能不会产生正确的结果：如果你合并了两个客户端的购物车，并且只在其中一个客户端里面移除了一个项目，那么被移除的项目将会重新出现在这两个客户端的交集结果中【37】。为了防止这个问题，要移除一个项目时不能简单地直接从数据库中删除；相反，系统必须留下一个具有适当版本号的标记，以在兄弟合并时表明该项目已被移除。这种删除标记被称为 **墓碑（tombstone）**（我们上一次看到墓碑是在 “[散列索引”](ch3.md#散列索引) 章节的日志压缩部分）。
 

zh-tw/ch5.md

@@ -683,7 +683,7 @@ LWW 實現了最終收斂的目標，但以 **永續性** 為代價：如果同
 
 合併併發值，本質上是與多主複製中的衝突解決問題相同，我們先前討論過（請參閱 “[處理寫入衝突](#處理寫入衝突)”）。一個簡單的方法是根據版本號或時間戳（最後寫入勝利）來選擇一個值，但這意味著丟失資料。所以，你可能需要在應用程式程式碼中額外做些更聰明的事情。
 
-以購物車為例，一種合理的合併值的方法就是做並集。在 [圖 5-14](../img/fig5-14.png) 中，最後的兩個兄弟是 [牛奶，麵粉，雞蛋，燻肉] 和 [雞蛋，牛奶，火腿]。注意牛奶和雞蛋雖然同時出現在兩個併發值裡，但他們每個只被寫過一次。合併的值可以是 [牛奶，麵粉，雞蛋，培根，火腿]，不再有重複了。
+以購物車為例，一種合理的合併值的方法就是做並集。在 [圖 5-14](../img/fig5-14.png) 中，最後的兩個兄弟是 [牛奶，麵粉，雞蛋，培根] 和 [雞蛋，牛奶，火腿]。注意牛奶和雞蛋雖然同時出現在兩個併發值裡，但他們每個只被寫過一次。合併的值可以是 [牛奶，麵粉，雞蛋，培根，火腿]，不再有重複了。
 
 然而，如果你想讓人們也可以從他們的購物車中 **移除** 東西，而不是僅僅新增東西，那麼把併發值做並集可能不會產生正確的結果：如果你合併了兩個客戶端的購物車，並且只在其中一個客戶端裡面移除了一個專案，那麼被移除的專案將會重新出現在這兩個客戶端的交集結果中【37】。為了防止這個問題，要移除一個專案時不能簡單地直接從資料庫中刪除；相反，系統必須留下一個具有適當版本號的標記，以在兄弟合併時表明該專案已被移除。這種刪除標記被稱為 **墓碑（tombstone）**（我們上一次看到墓碑是在 “[雜湊索引”](ch3.md#雜湊索引) 章節的日誌壓縮部分）。