读完文章 Strong consistency models 感觉有必要做个笔记，这篇文章很难，不好懂，几乎每段都要配上百度翻译和 ChatGPT 才能看的懂。为了对得起自己的理解和转头即忘的记忆力（看起来好像是病句...），还是写个笔记记录下，另一方面用自己的话，自己的理解在说一遍也能检查理解的到不到位。

在单进程/线程下程序的执行是按顺序的。顺序就意味着可预测，能保证正确性。

但是，如果多个进程或线程并行/并发访问某个共享资源，由于无法预测它们的执行顺序，就会导致结果的不确定性，无法预测。而且很多错误是很隐晦的，也很难发现，有时候生产环境运行了挺久才发现一个隐藏的并发访问共享资源的问题。

笔者就犯过这样的错，笔者写的 exporter 采集监控数据的时候，由于并发访问共享资源的 bug 导致在生产环境上几个月没有采集到资源指标...

作者在强调并发访问共享资源会导致结果不确定性后开始引出一系列一致性模型。主要有：

• 线性一致性模型；
• 顺序一致性模型；
• 因果一致性模型；
• 串形一致性模型；

首先，线性一致性模型是最强的一致性模型，它要求某个操作一旦完成，后续操作立马就能看到结果，并且所有操作看起来像是在某个瞬间原子执行的一样。线性一致性模型不仅要求顺序性，还要求满足真实时间顺序。

举例来说：

# 并发 a
t1 write(x = 1)
t2 read(x)

# 并发 b
t3 write(x = 2)
t4 read(x)

线性一致性是满足真实时间顺序的。如果 write(x=1) 已经返回成功，那么之后发生的读一定能够看到 x=1 或更新的值，而不会看到更旧的数据。虽然多个操作可能并发执行，但最终结果必须能够解释成符合真实时间顺序的某种串行执行。

因为是时间顺序执行，所以模型需要加锁，需要协调保证顺序性。对于多进程模型来说需要的成本就更高，需要处理网络延时，拥塞，超时的情况也更多。比如 etcd 需要选举出 leader 由 leader 来保证到达的请求是顺序性的，leader 需要沟通各个 follower 来保证结果是正确的。

探讨过线性一致性模型后，作者继续介绍了顺序一致性。相比于线性一致性，其没有时间上的限制，但是有顺序上的要求。

作者举了 YouTube 上传视频的例子来说明异步系统中的顺序问题，这里我用多线程访问共享变量来理解：

# 线程 A
write(x = 1) // 不一定是必须写成功，可以成功可以不成功
read(x)

# 线程 B
write(x = 2) // 不一定是必须写成功，可以成功可以不成功
read(x)

在顺序一致性模型中，每个线程内部的操作顺序必须保持不变。例如线程 A 一定是先 write(x=1) 再 read(x)，线程 B 一定是先 write(x=2) 再 read(x)。

但是不同线程之间谁先谁后并没有时间上的要求。系统只需要保证最终结果能够解释成某种全局顺序即可，而不要求这个顺序一定符合真实时间。

顺序一致性相比于线性一致性放宽了对时间的要求，因此实现时需要协调的内容也会少一些。

接着到因果一致性，这里相比于顺序一致性更加放宽了顺序的要求，不要求所有操作都满足顺序执行，只要求有因果关系的操作顺序执行。

举例来说，发朋友圈和点赞是满足因果一致性的，要先发朋友圈才能点赞，这是自然的因果逻辑。但是张三和李四发朋友圈并不需要顺序执行，它们是无因果关系的，谁在前谁在后并无影响。

然后到了串形一致性（Serializability），这里有意思的点是它开始引入事务的概念：

• 事务内部必须保持顺序；
• 多个事务可以并发执行；
• 但最终结果必须等价于某种串行执行结果。

换句话说，串形一致性关注的是事务之间最终是否能够解释成某种串行顺序，而不关心这个顺序是否符合真实时间。

这个点很有意思，文中举了例子（加上笔者的理解）如下：

# 事务 a
print x if x = 3
# 事务 b
x = 1 if x = nil
# 事务 c
x = 2 if x = 1
# 事务 d
x = 3 if x = 2

在事务内的执行语句是按顺序执行的，但是不同事物的执行顺序没有影响，而且整个系统是可以解释成串形执行的，具体说不管是哪个顺序运行这些事务，最终都可解释为 nil -> 1 -> 2 -> 3 这一个串，最终结果肯定是 3。

最后还有一种最终一致性模型，虽然作者没有介绍，但是感觉还是有必要说一下，笔者理解的是不管顺序，不管时间，只要求最终结果是一致的，当然这个最终的概念也是挺模糊的，什么时候算最终呢？有可能到时间的尽头...

我们可以看下表在加深对上述几种一致性模型的理解：

不局限于上述几种一致性模型的介绍，作者说了 CAP 理论，我们（最起码是我）平时讨论 CAP 理论时，说的 C 往往默认指线性一致性。那么如果降低一致性要求，例如降低到顺序一致性或者串形一致性，是不是就能同时满足 CAP 呢？

作者引用的论文给出的结论是，即便降低到顺序一致性、串形一致性等模型，依然无法做到完全可用（Fully Available）。只有进一步放宽一致性要求，采用更弱的一致性模型，才有可能获得更高的可用性。

具体可以参考作者的文章和作者给出的论文 Highly Available Transactions paper 。

最后说下自己的一些感受。

读完这篇文章后，笔者最大的感受其实不仅是理解各种一致性模型的定义，而是理解了：

一致性越强，系统允许出现的历史越少，需要的协调成本就越高。

像 etcd 这样的系统选择线性一致性，因此需要 Leader、Quorum、Heartbeat、ReadIndex 等机制来保证顺序性。

而像 VictoriaMetrics、Cassandra 等系统则选择更弱的一致性模型，用来换取更高的可用性和吞吐量。

一致性模型并不存在绝对的好坏，更多的是工程上的取舍：

该强一致的地方强一致，该弱一致的地方弱一致。

这也是作者在文章最后想表达的观点：

Anyone who says their consistency model is the only right choice is likely trying to sell something.

总的来说，这篇文章干货很多，看的人脑子一直在转，含金量很高，推荐推荐。