什么是数据库一致性

数据库一致性（Database

Consistency）

是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。

保证数据库的一致性是数据库管理系统的一项功能.比如有两个表(员工\职位),员工表中有员工代码、姓名、职位代码等属性，职位表中有职位代码、职位名称、职位等级等属性。你在其中员工表中进行了插入 *** 作,你插入了一个新员工的信息，而这个新员工的职位是公司新创建的一个职位。如果没有一致性的保证，就会出现有这么一个员工，但是不知道他到底担当什么职责！这个只是它的一个小小方面。

读一致性也是数据库一致性的一个重要方面,在实际中,我们会遇到这种情况:我们对一个表中的某些数据进行了更新 *** 作,,但是还没有进行提交,这时另外一个用户读取表中数据.这个时候就出现了读一致性的问题:到底是读什么时候的数据呢?是更新前的还是更新后的?在DBMS中设有临时表,它用来保存修改前的值,在没有进行提交前读取数据,会读取临时表中的数据,这样一来就保证了数据是一致的.(当前用户看到的是更新后的值)

但是还有一种情况:用户user1对表进行了更新 *** 作,用户user2在user1还没有进行提交前读表中数据,而且是大批量的读取(打个比方:耗时3分钟)而在这3分钟内user1进行了提交 *** 作,那又会产生什么影响呢?这个时候怎么保证读写一致性呢?这个时候DBMS就要保证有足够大的临时表来存放修改前的数值,,以保证user2读取的数据是修改前的一致数据.然后下次再读取时候就是更新后的数据了.

定义：数据库一致性（database

consistency）是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

数据库状态如何变化？每一次数据变更就会导致数据库的状态迁移。如果数据库的初始状态是c0，第一次事务t1的提交就会导致系统生成一个system

change

number（scn），这是数据库状态从c0转变成c1。执行第二个事务t2的时候数据库状态从t1变成t2，以此类推，执行第tn次事务的时候数据库状态由c(n-1)变成cn。

定义一致性主要有2个方面，一致读和一致写。

一致写：事务执行的数据变更只能基于上一个一致的状态，且只能体现在一个状态中。t(n)的变更结果只能基于c(n-1)，c(n-2),

...c(1)状态，且只能体现在c(n)状态中。也就是说，一个状态只能有一个事务变更数据，不允许有2个或者2个以上事务在一个状态中变更数据。至于具体一致写基于哪个状态，需要判断t(n)事务是否和t(n-1)，t(n-2),...t(1)有依赖关系。

一致读：事务读取数据只能从一个状态中读取，不能从2个或者2个以上状态读取。也就是t(n)只能从c(n-1），c(n-2)...

c(1)中的一个状态读取数据，不能一部分数据读取自c(n-1)，而另一部分数据读取自c(n-2)。

摆事实

一致写：

定义100个事务t(1)...t(100)实现相同的逻辑

update

table

set

i=i+1，i的初始值是0，那么并发执行这100个事务之后i的值是多少？可能很容易想到是100。那么怎么从一致性角度去理解呢？

数据库随机调度到t(50)执行，此时数据库状态是c(0)，而其它事务都和t(50)有依赖关系，根据写一致性原理，其它事务必须等到t(50)执行完毕后数据库状态变为c(1)才可以执行。因此数据库利用锁机制阻塞其它事务的执行。直到t(50)执行完毕，数据库状态从c(0)迁移到c(1)。数据库唤醒其它事务后随机调度到t(89)执行，以此类推直到所有事务调度执行完毕，数据库状态最终变为c(100)。

一致读：

还是上面的例子，假设t(1)...t(100)顺序执行，在不同的时机执行select

i

from

table，我们看到i的值是什么？

1.

t(1)的执行过程中。数据库状态尚未迁移，读到的i=0

2.

t(1)执行完毕，t(2)的执行过程中，数据库状态迁移至c(1)，读到的i=1

数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果

常用的一致性模型有：

a、严格一致性（linearizability,

strict/atomic

Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。

b、顺序一致性（sequential

consistency）：所有使用者以同样的顺序看到对同一数据的 *** 作，但是该顺序不一定是实时的。

c、因果一致性（causal

consistency）：只有存在因果关系的写 *** 作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看做对顺序一致性性能的一种优化，但在实现时必须建立与维护因果依赖图，是相当困难的。

d、管道一致性（PRAM/FIFO

consistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写 *** 作可以被其他所有的使用者按照顺序的感知到，而从不同使用者中来的写 *** 作则无需保证顺序，就像一个一个的管道一样。

相对来说比较容易实现。

e、弱一致性（weak

consistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的 *** 作具有顺序一致性，是全局可见的，且只有当没有写 *** 作等待处理时才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据。

f、

释放一致性（release

consistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区，

释放一致性使用两个不同的 *** 作语句进行了区分。需要写入时使用者acquire该对象，写完后release，acquire-release之间形成了一个临界区，提供

释放一致性也就意味着当release *** 作发生后，所有使用者应该可以看到该 *** 作。

g、最终一致性（eventual

consistency）：当没有新更新的情况下，更新最终会通过网络传播到所有副本点，所有副本点最终会一致，也就是说使用者在最终某个时间点前的中间过程中无法保证看到的是新写入的数据。可以采用最终一致性模型有一个关键要求：读出陈旧数据是可以接受的。

h、delta

consistency：系统会在delta时间内达到一致。这段时间内会存在一个不一致的窗口，该窗口可能是因为log

shipping的过程导致。

---