分布式数据库笔记 —— 数据一致性模型

系列笔记来自极客时间课程《分布式数据库30讲》分布式数据库30讲_分布式数据库_数据库_分布式_后端_架构_分布式系统_分布式存储_后端存储_后端开发_DDB-极客时间

零、 基础概念

1. 分布式数据库外部特性

写多读少、低延时、海量并发、海量存储、高可靠性、关系型数据库

2. BASE原则

BASE 代表了三个特性：

• BA 表示基本可用性（BasicallyAvailable）
• S 表示软状态（Soft State）
• E 表示最终一致性（EventualConsistency）

具体含义：

• 基本可用性：系统某些部分出现故障，其余部分依然可用。
• 软状态或柔性事务：数据处理过程中，存在数据状态暂时不一致的情况，但最终会实现事务的一致性。
• 最终一致性：在主副本执行写操作并反馈成功时，不要求其他副本与主副本保持一致，但在一段时间后这些副本最终会追上主副本的进度，重新达到数据状态的一致。也就是说，各副本数据中途可以不一致，但最后一定要是一致的。

一、 一致性

       对于分布式系统而言，一致性是在探讨当系统内的一份逻辑数据存在多个物理的数据副本时，对其执行读写操作会产生什么样的结果，这也符合 CAP 理论对一致性的表述。

       而在数据库领域，一致性与事务密切相关（ACID），研究如何协调事务之间的冲突。

       因此，当我们谈分布式数据库的一致性时，实质上是在谈数据一致性和事务一致性两个方面。

       

       本文主要介绍数据一致性，及其常用模型。

二、 数据一致性

1. 两种观察视角

    状态一致性：数据所处的客观、实际状态所体现的一致性；

    操作一致性：外部用户通过协议约定的操作，能够读取到的数据一致性

2. 状态一致性（强、弱一致性）

        任何变更操作后，数据只有两种状态，所有副本一致或者不一致。

        在某些条件下，不一致的状态是暂时，还会转换到一致的状态（最终一致），所以习惯上大家会把不一致称为“弱一致”。相对的，一致就叫做“强一致”了。

举个例子

        这种模式的副作用体现在以下两点：性能差，可用性问题（任何一台故障均不可用）。

        NoSQL 产品是应用弱一致性的典型代表，但接受度仍然是有限的，这就是BASE 理论中的 E 所代表的最终一致性（Eventually Consistency），弱于最终一致性的产品就几乎没有了。

3. 操作一致性

       最终一致性，在语义上包含了很大的不确定性，所以很多时候并不是直接使用，而是加入一些限定条件，也就衍生出了若干种一致性模型。

• 写后读一致性
• 单调读一致性
• 前缀一致性
• 线性一致性
• 因果一致性 ...

五、 常见操作一致性模型

1. 写后读一致性

        写后读一致性（Read after Write Consistency），也称为“读写一致性”，或“读自己写一致性”（Read My Writes Consistency）

       自己写入成功的任何数据，下一刻一定能读取到，其内容保证与自己最后一次写入完全一致，这就是“读自己写一致性”名字的由来。

2. 单调读一致性

       在小明发布照片后的瞬间，小红也刷新了朋友圈，此时读取到副本 R1，所以小红看到了照片；片刻之后，小红再次刷新，此时读取到的副本是 R2，于是照片消失了。小红以为小明删除了照片，但实际上这完全是程序错误造成的，数据向后回滚，出现了“时光倒流”。想要排除这种异常，系统必须实现单调读一致性。

       单调读一致性（Monotonic Read Consistency）的定义：一个用户一旦读到某个值，就不会读到比这个值更旧的值。

3. 前缀一致性

在一些更复杂的场景下还是会出现时间的扭曲，再用一个例子来说明

       小明和小红的评论分别写入了节点 N1 和 N2，但是它们与 N3 同步数据时，由于网络传输的问题，N3 节点接收数据的顺序与数据写入的顺序并不一致，所以小刚是先看到答案后看到问题。

       显然，问题与答案之间是有因果关系的，但这种关系在复制的过程中被忽略了，于是出现了异常。保持这种因果关系的一致性，被称为前缀读或前缀一致性（Consistent Prefix）。要实现这种一致性，可以考虑在原有的评论数据上增加一种显式的因果关系，这样系统可以据此控制在其他进程的读取顺序。

4. 线性一致性

       在“前缀一致性”的案例中，问题与答案之间存在一种显式声明，但在现实中，多数场景的因果关系更加复杂，也不可能要求全部做显式声明。所以，更可靠的方式是将自然语意的因果关系转变为事件发生的先后顺序。

       线性一致性（Linearizability）就是建立在事件的先后顺序之上的。在线性一致性下，整个系统表现得好像只有一个副本，所有操作被记录在一条时间线上，并且被原子化，这样任意两个事件都可以比较先后顺序。但是，集群中的各个节点不能做到真正的时钟同步，这样节点有各自的时间线。如何将操作记录在一条时间线上呢？这就需要一个绝对时间，也就是全局时钟。

       从产品层面看，主流分布式数据库大多以实现线性一致性为目标，在设计之初或演进过程中纷纷引入了全局时钟，比如 Spanner、TiDB、OceanBase、GoldenDB 和巨杉等等。

       工程实现上，多数产品采用单点授时（TSO），也就是从一台时间服务器获取时间，同时配有高可靠设计； 而 Spanner 以全球化部署为目标，因为 TSO 有部署范围上的限制，所以Spanner 的实现方式是通过 GPS 和原子钟实现的全局时钟，也就是 TrueTime，它可以保证在全球范围内任意节点能同时获得的一个绝对时间，误差在 7 毫秒以内。

5. 因果一致性

        因果一致性的基础是偏序关系，也就是说，部分事件顺序是可以比较的。至少一个节点内部的事件是可以排序的，依靠节点的本地时钟就行了；节点间如果发生通讯，则参与通讯的两个事件也是可以排序的，接收方的事件一定晚于调用方的事件。

        基于这种偏序关系，Leslie Lamport 在论文“Time, Clocks, and the Ordering of Events in a Distributed System”中提出了逻辑时钟的概念。

        借助逻辑时钟仍然可以建立全序关系，当然这个全序关系是不够精确的。因为如果两个事件并不相关，那么逻辑时钟给出的大小关系是没有意义的。多数观点认为，因果一致性弱于线性一致性，但在并发性能上具有优势，也足以处理多数的异常现象，所以也在工业界得到了应用。