終於要開始講建立分散式容錯系統會用到的演算法和協定啦！Day 14 ~ Day 20 的內容都是假設 Day 8 ~ Day 13 的鬼故事會發生，像封包遺失、排序錯誤、資料重複、時鐘不精準、網路延遲或者節點隨時死亡等等。

建立分散式容錯系統的好方法就是找到有用保證的通用抽象概念，然後讓應用系統依賴這些抽象，很饒舌我知道，你可以想像成 Day 1 的 Transaction 那樣，它就是個具有 ACID 保證的抽象概念，你的寫入操作不會因為故障、競爭條件 (race condition) 或硬碟錯誤而需要擔心資料是否會部份寫入，transaction 抽象概念隱藏了這些問題。

首先，分散式系統最重要的抽象之一是 共識 (consensus)：讓所有節點一致同意某些事情。

舉例來說，一旦你的系統實做共識，如果 leader 死亡，節點們就可透過共識選出新 leader (2020 Day 21 Handing Node Outages)，我們將會在 Day 20, 21 看看共識演算法的細節。

一致性保證 (Consistency Guarantees)

2020 Day 22 - Problems with Replication Lag 我們看到了一些因為時間差讀取資料的關係，當多個 client 去不同節點讀取回來的資料可能會不同，但資料最終還是會趨於一致，稱 最終一致性 (eventual consistency)，也就是說資料最終會相交於一點，現在大多數副本型資料庫 (replicate database) 最少都會具有此性質。

然而，這是一個非常弱的保證，因為你不知道該等 多久 資料才會一致，當你使用弱保證的副本型資料庫時，你必須了解其限制在哪裡，對它的期望也不能太多，弱保證意味者有些 GY bug 無法重現且難以測試。

在接下來的 7 天將會探討 較強 的分散式一致性模型，有些概念會跟我們在談 Transaction 的 隔離性 有些重疊，但其最大的不同是隔離性是為了避免在競爭條件下多個 transaction 並發寫入，而 分散式一致性模型大多是為了因應在故障和延遲發生時，協調不同副本的狀態。

你有 3 個選項：

• 首先是最強的一致性模型：線性一致性 (linearizability)。
• 再來是為了順序事件的 排序保證 (Ordering Guarantees)。
• 最後一個選項是能以原子方式 commit 分散式 transaction，順便看看共識問題的解決方案。

較強的保證代表著會有差一點的效能，但你能期待的是它會比較簡單且正確，希了解這些能幫助你做更好的選擇。