本文為 Design Data Intensive Applications 的書摘 + 個人心得。
終於要開始講建立分散式容錯系統會用到的演算法和協定啦！聊聊像像封包遺失、排序錯誤、資料重複、時鐘不精準、網路延遲或者節點隨時死亡等的鬼故事發生時該怎麼做，
建立分散式容錯系統的好方法就是找到有用保證的通用抽象概念，然後讓應用系統依賴這些抽象，很饒舌我知道，你可以想像成先前介紹的 Transaction 那樣，它就是個具有 ACID 保證的抽象概念，你的寫入操作不會因為故障、競爭條件 (race condition) 或硬碟錯誤而需要擔心資料是否會部份寫入，transaction 抽象概念隱藏了這些問題。
首先，分散式系統最重要的抽象之一是 共識 (consensus)：讓所有節點一致同意某些事情。
舉例來說，一旦你的系統實做共識，如果 leader 死亡，節點們就可透過共識選出新 leader (Leaders and Followers – Handing Node Outages)，我們將在之後看看共識演算法的細節。
一致性保證 (Consistency Guarantees)
在 Leaders and Followers – Problems with Replication Lag 小節中我們看到了一些因為時間差讀取資料的關係，當多個 client 去不同節點讀取回來的資料可能會不同，但資料最終還是會趨於一致，稱 最終一致性 (eventual consistency)，也就是說資料最終會相交於一點，現在大多數副本型資料庫 (replicate database) 最少都會具有此性質。
然而，這是一個非常弱的保證，因為你不知道該等 多久 資料才會一致，當你使用弱保證的副本型資料庫時，你必須了解其限制在哪裡，對它的期望也不能太多，弱保證意味者有些 GY bug 無法重現且難以測試。
在接下來的 7 天將會探討 較強 的分散式一致性模型，有些概念會跟我們在談 Transaction 的 隔離性 有些重疊，但其最大的不同是隔離性是為了避免在競爭條件下多個 transaction 並發寫入，而 分散式一致性模型大多是為了因應在故障和延遲發生時，協調不同副本的狀態。
你有 3 個選項：
- 首先是最強的一致性模型：線性一致性 (linearizability)。
- 再來是為了順序事件的 排序保證 (Ordering Guarantees)。
- 最後一個選項是能以原子方式 commit 分散式 transaction，順便看看共識問題的解決方案。
較強的保證代表著會有差一點的效能，但你能期待的是它會比較簡單且正確，希了解這些能幫助你做更好的選擇。
