在分布式系统中，我们经常提及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，并且写入的节点不重叠的话，则会存在写冲突。
