数据一致性基本知识
发布于 10 天前 作者 yan 29 次浏览

在分布式系统中,我们经常提及CAP定理,即一致性(Consistency)、可用性(Availability)和分区容忍性(Partition tolerance)。在本文中,我们将对数据一致性这一知识进行基本回顾。数据一致性无论是在平时工作中的系统设计,还是在面试中进行知识考查,都是很重要的知识点。

一致性,顾名思义,就是数据保持一致,可以理解为在分布式系统中的多个节点中数据的值是一致的。在本文中,我们主要讨论两种比较常见的一致性,强一致性和弱一致性。

  • 强一致性 也称为原子一致性,线性一致性。即任意时刻,所有节点中的数据应该是一样的。任何节点的读操作都能读取到某个数据的最近一次写的数据,系统中的所有进程,看到的操作顺序,都和全局时钟下的顺序一致。
  • 弱一致性 弱一致性包含很多种不同的实现,目前分布式系统中广泛实现的是最终一致性。最终一致性是弱一致性的一种特例,保证用户最终能够读取到某个数据的更新。

两种一致性的示例

下图展示最终一致性的复制概念。节点B和节点C是两个副本,尽管这两个副本总是可以读取数据,但是不保证副本中的值和最近的一次更新一致。例如,在图中,数据X被写入节点A中,节点B和C含有数据X的副本,节点B可以读取到数据X的更新值,但是节点C依然读取到旧的数据X的值。在一段时间后,节点C会更新数据X。

与之相反,传统的关系型数据库通常是基于强一致性的概念。这就意味着在数据更新以后,更改后的数据马上会被所有人看到。但是强一致性也是有代价的,为了保证强一致性,开发者必须在可扩展性(Scalability)和性能上做出妥协。简单来说,数据要在更新或者复制过程中上锁,用以确保没有其他的进程会对同一个数据进行更新。下图展示了一个强一致性。在数据X的更新被写入节点A以后,节点B和C的数据X读取都被阻塞,直到所有节点的数据X都被更新。

两种一致性的选择

目前主流的分布式非关系型数据库都提供了不同一致性的选择,以适应不同的用户场景。例如,对于“哪些用户给你的微博点赞”以及“在某一时刻你的在线好友列表”这些应用场景,强一致性并非必须。那么对于这些场景,最终一致性可以提供很好的可扩展性以及性能。而对于“用户是否完成了付款流程”或者“在一局在线游戏对战中玩家获得的点数”等场景,强一致性则是必须的。

由上面的例子中我们可以看出,对于有大量实体的场景,最终一致性是最佳模型。例如如果在一个查询中,结果的数目很大,那么用户体验并不会因为多几个结果或者少几个结果而受到影响,比如我们上面提到的“哪些用户给你的微博点赞”这一场景。相反,对于结果中实体数目比较小并且场景涉及的其他数据比较少,那么强一致性则是必要的。比如上文提到的“在一局在线对战中玩家获得的点数”,因为只涉及这一局对战中的其他玩家,那么对某一位玩家的忽略将会造成最终点数的不准确,从而影响用户的体验。

数据一致性的形式化表达

对于分布式数据系统,我们定义如下的参数 N — 数据复制的份数 W — 更新数据是需要保证写完成的节点数 R — 读取数据的时候需要读取的节点数

  • 如果W+R>N:则是强一致性,写的节点和读的节点重叠。例如对于典型的一主一备同步复制的关系型数据库。N=2,W=2,R=1,则不管读的是主库还是备库的数据,都是一致的。
  • 如果W+R<=N:则是弱一致性。例如对于一主一备异步复制的关系型数据库,N=2,W=1,R=1,则如果读的是备库,就可能无法读取主库已经更新过的数据,所以是弱一致性。    对于分布式系统,为了保证高可用性,一般设置N>=3。不同的N,W,R组合,是在可用性和一致性之间取一个平衡,以适应不同的应用场景。

如果N=W,R=1,任何一个写节点失效,都会导致写失败,因此可用性会降低,但是由于数据分布的N个节点是同步写入的,因此可以保证强一致性。如果N=R,W=1,只需要一个节点写入成功即可,写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据,因此是弱一致性。这种情况下,如果W<(N+1)/2,并且写入的节点不重叠的话,则会存在写冲突。

回到顶部