[大数据]来聊聊分布式数据一致性

Base 理论对于 CAP 理论来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计的时候，最常选择的一种设计方式。在实际项目工程中，基于 CAP 理论逐步演化，后来就提出了 Base 理论。

数据一致性

那么我们就借助这么一个小小案例，给大家去描述一下。下图图中描述的就是一个用户去取钱以及去查询的这么一个过程。

上图中，User 代表用，DB1我们数据库集群中的一个节点，DB2 也是我们数据库集群中的另外一个节点，Balance 就是余额。

那当用户进行取钱操作的时候，他的取钱请求发送到了 DB1 这个节点，我们都知道取钱其实就是让数据库里面的这个 Balance 进行减少。我们当前是取 100 块，所以呢其实我们就是把 Balance 从 1000 变成 900。

那么用户取完钱之后，现在他再次发起一个请求，查询一下自己的余额。那么本次他的这个请求，被发送到了这个 DB2 的一个节点。那么此时 DB1 它的数据还没有及时的更新到 DB2 节点上，所以他从 DB2 节点再去查这个Balance 余额的时候，还是 1000，这就造成了一个什么效果。

就是一个用户，他有 1000 块钱，他去取了 100 出来，然后再去查询，发现余额还有 1000，这样是不是肯定不行。所以这其实就会造成整个数据库集群数据不一致的这么一个情况。

那我们接下来为了解决这个问题，我们就必须得保证这个数据一致性，怎么去保证呢？在进行怎么保证数据一致性之前，我们先给大家介绍相关概念。

一般来说，数据一致性可以分为强一致性和弱一致性，强一致性也叫做线性一致性，除此以外，所有其他的一致性都是弱一致性的特殊情况。弱一致性根据不同的业务场景，又可以分解为更细分的模型，不同一致性又有不同的应用场景。

强一致性

强一致性指的是什么呢？它指的是如果数据不一致，就不对外提供数据服务，从而保证用户读取的数据始终是一致的，就是有点强制性。就如用户取钱的这个案例，就是这个 DB1 和 DB2 没有完成数据同步，那么我就不对外提供暴露服务。

它是怎么实现的呢？其实借助的是一个锁机制，比如说我们当前这个例子，用户在操作完 DB1 进行一个取钱操作之后。在 DB1 没有完成与DB2 的数据同步之前，整个这个 DB2 都是处在一个上锁状态，也就是不对外提供一个读操作。是没有办法读取我 DB2 这个数据库中的数据的。这个其实就是一个锁机制。只有当我们 DB1、DB2 数据同步完成之后，DB2 才对外暴露服务，就是你才能去读取 DB2 这个数据库。这其实就是强一致性它的一个体现。

弱一致性

系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。用户读到某一操作对系统数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。

最终一致性

最终一致性其实就是说我就要求最终同步就可以，你不用实时同步。

最终一致性是弱一致性的特例，强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

到达最终一致性的时间 ，就是不一致窗口时间，在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。

单调读一致性（Monotonic-read Consistency） ：如果一个进程读取数据项 x 的值，那么该进程对于 x 后续的所有读操作要么读取到第一次读取的值要么读取到更新的值。即保证客户端不会读取到旧值。

单调写一致性（Monotonic-write Consistency） ：一个进程对数据项 x 的写操作必须在该进程对 x 执行任何后续写操作之前完成。即保证客户端的写操作是串行的。

读写一致性（Read-your-writes Consistency） ：一个进程对数据项 x 执行一次写操作的结果总是会被该进程对 x 执行的后续读操作看见。即保证客户端能读到自己最新写入的值。

写读一致性（Writes-follow-reads Consistency） ：同一个进程对数据项 x 执行的读操作之后的写操作，保证发生在与 x 读取值相同或比之更新的值上。即保证客户端对一个数据项的写操作是基于该客户端最新读取的值。