Consistency and Consensus (1) - Consistency Guarantees

终於要开始讲建立分散式容错系统会用到的演算法和协定啦！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，顺便看看共识问题的解决方案。

较强的保证代表着会有差一点的效能，但你能期待的是它会比较简单且正确，希了解这些能帮助你做更好的选择。