What is Consistency
一致性（Consistency）一直是分布式系统里一个很重要的话题。
在存储系统中，为了避免数据丢失，我们都会对数据进行持久化。
对数据进行持久化可以避免宕机带来的数据丢失问题，但是不能解决单机永久性故障的问题。存储系统作为基础设施，在单机上持久化是远远不够的，我们需要将数据复制到多台机器上以提升系统的可用性和可靠性。
一旦数据被复制到多个节点，那么就产生了一致性的问题。
系统需要定义一组协议来规定用户读写多副本的行为，这组协议称之为一致性模型（Consistency Model）。在分布式系统领域，谈论一致性时通常谈论的都是一致性模型。
Consistency Model
不同的一致性模型对系统的行为和表现有不同的约束。
Strict Consistency
Strict Consistency是最强的一致性模型，要求任何读取操作都能读取到最新的值，换句话说，要求任何写入操作立即同步给所有进程。在分布式系统中，数据的同步是需要时间的，因此在分布式系统下无法严格实现Strict Consistency。除非让所有的读写操作都只在一个进程的一个线程中执行或者，读写操作被锁保护起来。(根据CAP的原理，这个一致性模型在没有牺牲可用性的前提下是不能得到满足的。 性能也是不可接受的：所有的写操作需要同步到所有节点之后再返回给客户端。)
Strict Consistency如上图所示，在时间轴上，一旦有进行写入了x=1，其他进程立即能读到x=1的值。
-
在W(x)1之后，W(x)2之前，所有进程读取到的x的值一定是1
-
在W(x)2之后，W(x)3之前，所有进程读取到的x的值一定是2
-
在W(x)3之后，所有进程读取到的x的值一定是3
Sequential Consistency
Sequential Consistency是比Strict Consistency弱一些的一致性模型，要求：
-
进程内，对同一个变量的读写保持顺序
-
进程间，“看到”的变量的变更顺序是一致的（不要求和“物理时间”下的顺序保持一致）
以Consistency Model中的例子举例，“看到”以下几种数据的变更顺序都是满足Sequential Consistency的：
-
x=1, x=2, x=3：满足Strict Consistency，自然满足Sequential Consistency
-
x=2, x=1, x=3：满足了P1中同一个变量的变更顺序，不同进程“看到”的顺序一致
-
x=1, x=3, x=2：同上
（进程间的事件的顺序可以参看《Time, Clocks, and the Ordering of Events in a Distributed System》）
Linearizable Consistency
Linearizable Consistency比Sequential Consistency更严格一些：
-
进程内，对同一个变量的读写操作保持顺序
-
进程间，“看到”的变量的变更顺序和全局“物理时钟”下的顺序是一致的
即Linearizable Consistency是Sequential Consistency的特例，除了满足所有进程读到的变更顺序是相同，还要求这个顺序和全局时钟下的顺序是一致的。
和全局时钟下的顺序保持一致容易理解，即事件的顺序和它们在客观的物理时间下发生的时间顺序是一致的。但是如果事件是并发发生的，如何满足这个顺序要求：
如上图，P0的write x=1操作和P1的read x=0/1有重叠的部分，那么之间的先后关系是怎样的？
对于并发的情况Linearizable Consistency并不要求他们之间有确定的顺序，即认为P0的write x=1先于P1的read x=0/1或者P1的read x=0/1先于P0的write x=1都是合理的，但是P0~P3进程看到的这两个操作的顺序必须是确定的、一致的。
上图的例子中，满足以下情况的序列都是满足Linearizable Consistency的：
-
w1 r1 r1 r1（P0->P1->P2->P3或P0->P1->P3->P2）
-
r0 w1 r1 r1（P1->P0->P2->P3或P1->P0->P3->P2）
-
r0 r0 w1 r1（P1->P2->P0->P3）
以上三种一致性模型：Strict Consistency、Linearizable Consistency、Sequential Consistency都是强一致模型。
Causal Consistency
Causal Consistency是一种弱一致性模型，仅要求有因果关系的操作顺序性得到保证，非因果关系的操作顺序性没有要求。
具体如下：
-
本地顺序：统一进程中，事件的执行顺序即为本地的因果顺序
-
异地顺序：如果读操作返回的是写操作的值，那么该写操作一定在读操作之前
-
闭包传递：如果a->b，b->c，那么a->c
（Lamport在《Time, Clocks, and the Ordering of Events in a Distributed System》中描述的happen-before关系及其传递闭包）
腾讯朋友圈的例子
在infoq分享的腾讯朋友圈的设计中，他们在设计数据一致性的时候，使用了因果一致性这个模型。用于保证对同一条朋友圈的回复的一致性，比如这样的情况：
-
A发了朋友圈内容为梅里雪山的图片。
-
B针对内容a回复了评论：“这里是哪里？”
-
C针对B的评论进行了回复：“这里是梅里雪山”
那么，这条朋友圈的显示中，显然C针对B的评论，应该在B的评论之后，这是一个因果关系，而其他没有因果关系的数据，可以允许不一致。
微信的做法是：
-
每个数据中心，都自己生成唯一的、递增的数据ID，确保能排重。在下图的示例中，有三个数据中心，数据中心1生成的数据ID模1为0，数据中心1生成的数据ID模2为0，数据中心1生成的数据ID模3为0，这样保证了三个数据中心的数据ID不会重复全局唯一。
-
每条评论都比本地看到所有全局ID大，这样来确保因果关系。
上图是Causal Consistency在微信朋友圈中的应用。
比Causal Consistency更弱的一致性模型还有Eventual Consistency（最终一致），比如MySQL的异步复制。
Eventual Consistency：存储系统保证如果没有新的写操作，那么最终，所有的读操作都能读到一致的数据，这里强调对一个数据项的修改最终会收敛。
总结
本文简单的描述了分布式系统中一致性问题的由来，并介绍了几种一致性模型。其中，Strict Consistency要求最为严格，是现实环境中难以满足的一种一致性模型，除非牺牲可用性。Linearizable Consistency略弱于Strict Consistency，不要求写入操作立即可见，但是要求写入操作保持和全局时钟下的顺序一致。Sequential Consistency则更弱一些，不要求写入操作保持和全局时钟下的顺序一致，但是要求所有进程看到的写入操作的顺序是一致的。Strict Consistency、Linearizable Consistency、Sequential Consistency都被认为是强一致的模型。
Causal Consistency被认为是一种若一致模型，它只要求有因果关系的事件之间保持顺序，详细可以参看Lamport在《Time, Clocks, and the Ordering of Events in a Distributed System》中描述的happen-before关系及其传递闭包。
Eventual Consistency是最终一致，只要求在没有新写入的情况下，最终所有数据达成一致，常见于一些异步复制的系统。
最后
蚂蚁中间件团队是服务于整个蚂蚁金服集团的核心技术团队，打造了世界领先的金融级分布式架构的基础中间件平台。我们是隶属于蚂蚁中间件的通信中间件团队，致力于打造金融级的分布式消息中间件。
如果你对分布式消息中间件、流计算框架、高可靠存储系统的设计和研发有兴趣，请通过公众号留下你的信息，我会和你联系详聊。
