漫谈分布式系统(12) -- 弱一致性也有用武之地

---

这是《漫谈分布式系统》系列的第 12 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。  

先污染后治理的一致性

前面几篇文章，大致介绍了几种预防类的分布式数据一致性算法，包括单主同步、2PC/3PC、Quorum 类（Paxos/Raft/ZAB）等。

这类算法为了追求强一致性，都一定程度牺牲了性能和可用性。

但性能和可用性也是非常重要的，太慢的系统，或者失去可用性的系统，很多时候都是无法接受的。

而反过来，有时候，强一致性却并不是必须的。

这篇文章，我们就一起看下，第二种分布式数据一致性算法 -- 先污染后治理类算法，及其实际应用场景。

弱一致性模型

预防类的一致性算法，想要提供的是强一致性保证，整个系统始终像一个单副本（single-copy）系统一样。

而先污染后整理的一致性算法，提供的是弱一致性，允许系统出现某不一致，对外也体现为一个多副本（multi-copy）的分布式系统。

当然，弱一致性也只是妥协，并且是局部或暂时的妥协。从应用的角度看，自然还是希望得到一致性结果的。

粗略的看，弱一致性可以分为以下几种模型：

• 以客户端为中心的一致性（Client-Centric Consistency）

• 最终一致性（Eventural Consistency）

• 因果一致性（Causal Consistency）

第一种，以客户端为中心的一致性，说难听点，是一种推卸责任的一致性。

在这个模型下，分布式系统不能说弃不一致性不顾，但至少没有承担主要作用，而是把责任丢给了客户端。

客户端需要自己维护一个数据缓存，来保存从服务端读到的不同版本的数据。当读请求指向旧副本时，直接使用缓存中的数据。

很显然，这个模型只是尽力去避免读到旧数据，不能保证每次读到的真的就是最新的数据。

第二种，最终一致性，是一种很玄学的一致性。

这个模型提供的是一个非常弱的保证：虽然过程中数据会出现分歧，但最终会达到一致。

但是究竟多久叫「最终」？没有标准答案。

看起来，像前面文章提到的单主同步模型一样，又是一种「尽可能」（best-effort）的一致性，只不过这次体现在时间上。

虽然很玄，但在现实系统面对的性能和可用性高压下，却得到了非常广泛的实现和应用。

第三种，因果一致性，是一种有说服力的一致性。

在这个模型下，分布式系统尝试提供的保证是，如果事件 B 的发生必须以事件 A 发生为前提，或者说 B 发生在 A 之后，那系统将收敛于 B。

这就解决了类似我们前面文章举过的 答案比问题先出现 的怪异情况。

因果一致性固然没有强一致性好，但从实用的角度说，对很多时候对应用而言已经够用了。

从实现上看，因果一致性，可以看做一种特殊的最终一致性。

上面列的三种分类只是示例，并不是说没有其他的分法，我们有些基本的认识即可，不必在概念上过多纠结。

冲突解决

既然弱一致性允许出现冲突，又想要尽量保证一致性，那解决冲突就成了核心问题。

下面就一起看下几种典型的冲突解决办法。

Last Write Wins

采用这个方法，系统总是用更新的数据覆盖旧数据。

这是个非常常见的办法，在单机系统里就是这么干的。

但是单机系统的顺序性是非常好确定的，所有事件都在同一个地方排好队按顺序处理。

但是分布式系统却是分散的，又怎么去定义谁是 first 谁是 last 呢？

最常见的办法有两种：

• 一种是给每个事件一个时间戳，通过时间戳来比较先后。

• 另一种是给每个事件一个递增的标识，通过比较标识大小确定先后，本质上和时间戳一样。

这两种办法都很