数据库中的一致性

数据库领域在发展过程中产生的与一致性相关的经典概念：

事务的 ACID 属性

• 原子性：事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，要么全部执行，要么全部不执行。
  任何一项操作失败都将导致整个事务失败，同时其他已经被执行的操作都将被撤销并回滚。只有所有的操作全部成功，整个事务才算是成功完成。

• 一致性：事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。换句话说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。

• 隔离性：事务的隔离性是指在并发环境中，并发的事务是相互隔离的，事务之间互不干扰。
  在标准的SQL规范中，定义的4个事务隔离级别，不同隔离级别对事务的处理不同。4个隔离级别分别是：未授权读取、授权读取、可重复读取和串行化。

• 持久性：事务的持久性又称为永久性，是指一个事务一旦提交，对数据库中对应数据的状态变更就应该是永久性的。即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态。

分布式系统的 CAP 理论

一个分布式系统不可能同时满足一致性（C:Consistency）、可用性（A:Availability）和分区容错性（P:Partition tolerance）这三个基本要求，最多只能满足其中的两项。

• 一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性

• 可用性：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。

• 分区容忍性：分区容错性要求一个分布式系统需要具备如下特性：分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

在分布式系统中，无法避免P，所以需要在一致性和可用性之间平衡系统。这里的平衡是各方面、各粒度的平衡。

从 CAP 到 BASE

BASE是Basically Available(基本可用）、Soft state(软状态）和Eventually consistent(最终一致性）三个短语的简写。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方法来使系统达到最终一致性。

• 基本可用：分布式系统在出现不可预知故障的时候，允许损失部分可用性
• 软状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

系统一致性可以从客户端和服务器两个角度进行观察

客户端角度

从客户端的角度观察，有以下4个角色：
一个存储系统：黑盒，保证持久性和可用性
进程A：读写存储系统数据
进程B和C：与A独立，可读写，BC之间也是独立的，可以交换信息。

客户端角度一致性规定的是观察者（A、B、C）看到的对数据对象的更新操作。

分为以下几种：

• 强一致：
  当一个更新完成后，后续所有的访问都能看到更新之后的值。

• 弱一致性：
  系统不保证后续的访问能返回更新的值，在返回新值前需要保证一定的条件，这短时间叫不一致窗口。这种一致性在实际应用中提到的不多，我的理解是弱一致性系统需要给出一个确定的不一致窗口的值。

• 最终一致性：
  很多一致性协议都属于最终一致性，最终一致性是弱一致性的特例。当没有更新操作后，存储系统保证最终会将新值返回给所有访问者。当不考虑失败时，不一致窗口可以通过一些度量值计算出来。

• 因果一致性（最终一致性变种）：
  如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。

• 读己之所写（最终一致性变种）：
  总能读到自己写进去的新值。因为自己写了相当于通知了自己，是因果一致性的特例。

• 会话一致性（最终一致性变种）：
  这是因果一致性模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。

• 单调读一致（最终一致性变种）：
  如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

• 单调写一致（最终一致性变种）：
  系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

• K-possibility一致（新概念）：
  保证读出来的数据有一定的概率是最近写的k个版本中的一个。

• t-possibility一致（新概念）：
  保证在写操作提交后经过t秒后读出旧数据的概率不超过一定值。

服务器角度

这个角度主要观察副本和读写策略。如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。

定义：

• N：副本总数
• W：写副本数（当有W个副本写成功，就视为写操作成功）
• R：读副本数（当读到了R个副本，就视为读操作成功）

一致性度量：

• W+R>N：强一致。抽屉原理，总能读到一个新的副本。
• W+R<=N：弱一致。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。当写成功的节点少于W，则写失败。

更多例子：

• 如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性，而且优化了读场景，随便读一个副本就可以。
• 那些关心容错而不关心一致性的系统，设置W=1。
• 如果N=R,W=1，只需要一个节点写入成功即可，是优化了写入效率，写性能比较高。但是在节点失效时不能保证持久性。
• 如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突

在很多类似Google的Dynamo系统中，都可以配置读写策略，来适应场景的需求。

参考资料

• • Werner Vogels:
    Eventually Consistent.  ACM Queue 6(6): 14-19 (2008)
     
• Douglas B. Terry, Alan J. Demers, Karin Petersen, Mike Spreitzer, Marvin Theimer, Brent B. Welch:
  Session Guarantees for Weakly Consistent Replicated Data. PDIS 1994: 140-149
• 微信 2016-12-14 LBD 大数据架构之路
  https://mp.weixin.qq.com/s?__biz=MzI0NDI0MTgyOA==&mid=2652037708&idx=1&sn=d27ef7604d35b26d5f059696baa63dab&chksm=f2868687c5f10f915b924456abe1598e3efcc3ea88dc284b921761e09187cd6fccd8d1e97eb3&mpshare=1&scene=1&srcid=1214yu12nsFDkDLAMGkmL6OA&key=564c3e9811aee0abd712dca3624301ee72d2b277e592d6b87e04eb69580098a8fef7baa18edcd9ee428edac8ef51d1d32a4b4f9f9fda18d376d61698f395bf707b2520b9a5f856f10254bc98e116d2b8&ascene=0&uin=NzUyMTIxMTgx&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.12.2+build(16C67)&version=12010210&nettype=WIFI&fontScale=100&pass_ticket=jEuoJarcHevcqoXdERdChwuMnF3bCl3m3BZjxaVxfv3hTgBT%2FNx%2FOEAgzwXkhkEx