consistency 这个词在不同的环境下有着不同的含义,各个方向都在使用,导致很难理解:
- 多副本的一致性,即distirbuted
- 一致性hash.
- CAP理论的一致性
- ACID里的一致性
而这几个一致性的含义都不相同。结合各种资料,自己做个总结方便查阅。
一、事务的ACID中的C
第一种理解
首先来解释下ACID中的Consistency怎么解决。参考文献【1】中的sleep deep解释得很好。
直接复制过来:
请看下面Wikipedia中关于数据库事务一致性的定义
Consistency ensures that a transaction can only bring the database
from one valid state to another, maintaining database invariants: any
data written to the database must be valid according to all defined
rules, including constraints, cascades,triggers, and any combination
thereof. This prevents database corruption by an illegal transaction,
but does not guarantee that a transaction is correct.
我对这段话的理解:
- 数据库事务的一致性是指:保证事务只能把数据库从一个有效(正确)的状态“转移”到另一个有效(正确)的状态。那么,什么是数据库的有效(正确)的状态?满足给这个数据库pred-defined的一些规则的状态都是
valid 的。这些规则有哪些呢,比如说constraints, cascades,triggers
及它们的组合等。具体到某个表的某个字段,比如你在定义表的时候,给这个字段的类型是number类型,并且它的值不能小于0,那么你在某个
transaction 中给这个字段插入(更改)为一个 String
值或者是负值是不可以的,这不是一个“合法”的transaction,也就是说它不满足我们给数据库定义的一些规则(约束条件)。
“This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct. ” 这又怎么理解呢?在数据库的角度来看,它只关心 transaction 符不符合定义好的规则,符合的就是legal的,不符合的就是illegal的。transaction 是否正确是从应用层的角度来看的,数据库并不知道你应用层的逻辑意义,它不保证应用层的transaction的正确性,这个逻辑正确性是由应用层的programmer来保证的。 这么说估计还是抽象,那么看下面我们熟知的转账的例子。
Table: Account
Columns: Name(string), Balance(int)
约束条件:无执行下面一个事务(A,B的初始余额均为1000,A给B转账1200)
- 往表Account插入数据(A,1000)
- 往表Account插入数据 (B,1000)
- A给B转账1200,更新A的余额为-200,(A,-200)
- B的余额增加1200,更新B的余额为2200(B,2200)
那么,数据库会认为这个 transaction 合不合法呢?也就是它满不满足我们给数据库的定义的规则呢?答案就是这个 transaction 是合法的,因为你定义表的时候没有约定 Balance 不能小于0。虽然我们从应用层的角度来看,这个transaction是不正确的,因为它不符合逻辑- balance不能小于0. 但我们数据库只关心你的 transaction 满不满足你的数据库定义的rule,不关心它具有什么业务的逻辑,这个业务逻辑是应该由应用层来理解并处理的。
修改一下上面这个例子
Table: Account
Columns: Name(string), Balance(int)
约束条件:Balance >= 0执行下面一个事务(A,B的初始余额均为1000,A给B转账1200)
- 往表Account插入数据(A,1000)
- 往表Account插入数据 (B,1000)
- A给B转账1200,更新A的余额为-200,(A,-200)
- B的余额增加1200,更新B的余额为2200(B,2200)
注意,这里增加了约束条件Balance > 0, 上面的这个transaction违反了规则Balance>=0,那么这个事务数据库认为它是非法的,不满足一致性的要求,所以数据库执行这个事务会失败。
所以,一句话总结,数据库事务中的consistency就是:
事务的一致性只是与数据库预先定义的约束有关,满足了约束即满足了一致性
第二种理解
The database remains in a consistent state at all times — after each
commit or rollback, and while transactions are in progress. If related
data is being updated across multiple tables, queries see either all
old values or all new values, not a mix of old and new values.
直接来理解就是:当事务中有一个操作失败,所有更改过的数据全部都要回滚。
这与原子性有些类似:
原子性:一个事务内的所有操作是一个整体,要么全部成功,要么全部失败
参考文献【2】的理解是:
- 原子性侧重的是事务内操作的整体性,要么全部成功,要么全部失败
- 一致性侧重的是数据库数据的一致性,数据库的数据要么处于事务前的状态,要么处于事务后的状态
注:这里的感觉就是我们论文中的consistency。
二、CAP理论的C
CAP理论是在分布式集群环境下讨论的。
这里的C简单来说就是:是指在分布式环境中引入数据复制机制之后,数据一致性就是指在对一个副本数据进行更新的时候,必须确保也能够更新其他的副本,否则不同副本之间的数据将不一致。
参考文献【3】非常生动详细地解释了CAP理论。
参考文献【3】例子说明不同场景事实上要求的一致性级别不同。一致性级别可分为:
- 强一致性:也叫做线性一致性
- 弱一致性:所有其他的一致性都是弱一致性的特殊情况
所谓强一致性,即复制是同步的,弱一致性,即复制是异步的。
参考文献【4】更具体地解释了弱一致性中多种概念。
参考文献【5】解释了因果一致性。