NoSQL的最终一致性讨论

Posted 2021-05-01 HIT智能数据俱乐部

NoSQL的最终一致性讨论

10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容错性，最多只能两个。在CAP理论的指导下，我们知道只有真正的理解了系统的需求，才有可能利用好CAP理论，进而更好地满足用户的需求。对于一致性，我们有两种视角去看待它，第一种是客户或者开发者视角，此种情况下，客户或者开发者更加关注如何观察到系统的更新；另外一种视角是服务器端视角，此种情况下，主要关注更新操作如何贯穿系统以及系统对更新操作提供什么样的一致性保证。

 一、客户端一致性

为了更好的描述客户端一致性，通过以下的场景来进行模拟，这个场景中包括三个组成部分：

存储系统：存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。

Process A：主要实现从存储系统write和read操作

Process B 和ProcessC ：ProcessB和C是独立于A，并且B和C也相互独立的，它们同时也实现对存储系统的write和read操作。用上面的场景来描述下不同程度的一致性：

(1)强一致性：假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读取操作都将返回最新值。

(2)弱一致性：假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一段时间。

(3)最终一致性：最终一致性是弱一致性的一种特例。假如A首先写入一个值到存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到最A写入的最新值。此种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数，最终一致性方面最出名的系统可以说是DNS系统，当更新一个域名的IP以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都会看到最新的值。

其中最终一致性还有以下几个变体，下面分别描述：

(1) Causal consistency ：如果Process A通知Process B它已经更新了数据，那么Process B的后续读取操作则读取到A写入的最新值，而与A没有因果关系的C则采用最终一致性的语义。

(2)Read-your-writer consistency：如果Process A写入了最新的值，那么Process A的后续操作都会读取到最新值。比如以本论坛为例，当某用户发表一个帖子以后，该用户可以立即看到自己发表的帖子，但是其它用户可能要过一会才可以看到。

(3)Session consistency：此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency。Hibernate的session提供的一致性保证就属于此种一致性。

(4)Monotonic read consistency：此种一致性要求如果Process A已经读取了对象的某个值，那么后续操作将不会读取到更早的值。

(5)Monotonic write consistency：此种一致性保证系统会序列化执行一个Process中的所有写操作。

二、服务器端一致性

在讨论服务器端一致性要求之前，我们首先要明确几个概念：

N：节点的总个数，

W：更新的时候需要确认已经被更新的节点的个数，

R：读取数据的时候读取数据的节点个数。

如果W+R>N，那么分布式系统就会提供强一致性的保证，因为读取数据的节点和被同步写入的节点是有重叠的。在分布式系统中，一般都要有容错性，因此一般N都是大于3的，此时根据CAP理论，一致性，可用性和分区容错性最多只能满足两个，那么我们就需要在一致性和分区容错性之间做一平衡，如果要高的一致性，那么就配置N=W，R=1,这个时候可用性就会大大降低。如果想要高的可用性，那么此时就需要放松一致性的要求，此时可以配置W=1，这样使得写操作延迟最低，同时通过异步的机制更新剩余的(N-W)个节点。

在系统开发过程中，根据CAP理论，可用性和一致性在一个大型分区容错的系统中只能满足一个，因此为了高可用性，我们必须放低一致性的要求，但是不同的系统保证的一致性还是有差别的，这就要求开发者要清楚自己用的系统提供什么样子的最终一致性的保证。

 

 

责任编辑：宋新彤