数据库事务浅析

ACID

一个数据库事务通常包含了一个序列的对数据库的读/写操作。它的存在包含有以下两个目的:

  1. 为数据库操作序列提供了一个从失败中恢复到正常状态的方法,同时提供了数据库即使在异常状态下仍能保持一致性的方法。
  2. 当多个应用程序在并发访问数据库时,可以在这些应用程序之间提供一个隔离方法,以防止彼此的操作互相干扰。

上面对数据库事务的定义摘自维基百科。先不用着急的去理解这个定义的具体含义,我们从事务的四个特性来逐步了解什么是事务。

数据库事务拥有以下四个特性,习惯上被称之为ACID特性。

  1. 原子性(Atomicity):事务作为一个整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行。

  2. 一致性(Consistency):事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。

  3. 隔离性(Isolation):多个事务并发执行时,一个事务的执行不应影响其他事务的执行。

  4. 持久性(Durability):已被提交的事务对数据库的修改应该永久保存在数据库中。

用一个转账的例子来解释,这个例子被用烂了,却很经典:

从A账户向B账户转账100元,可能分为以下几个步骤:

  1. 读取A账户,将A账户余额减100

  2. A 账户余额写回数据库

  3. 读取B账户,将B账户余额加100

  4. B账户余额写回数据库

  • 一致性

    什么叫数据一致性?通常是由我们自己来定义的。在上面的场景中,就是在转账的前后,A账户和B账户的总额保持不变。

    再举一个例子,之前做过一个版本管理系统,用户发布一个的版本(上传若干附件),版本记录表就要插入一行记录,相对应的,附件表也要插入若干的记录(一对多的关系)。对于这两个表的操作,要么全做,要么不做,如果附件表插入了记录,而版本记录表没有操作,不符合一致性定义;如果版本记录表插入了一条记录,而附件表没有插入记录或者插入记录少了几条,也不符合一致性的定义。想要保持一致性,那么需要对这两个表的插入操作都放在同一个事务内进行。

    在事务处理的ACID属性中,一致性是最基本的属性,其它的三个属性都为了保证一致性而存在的。

  • 原子性

    上面的转账的四个步骤要么全做,要么不做。假如做完第一步之后,计算机突然断电了,那么数据库重启之后就需要执行一个crash
    recovery的过程,之前的所有操作都应该回滚到执行事务之前的状态。即A向B转账的操作失败了。

    上面提到,其他三个属性都是为了保持一致性而存在。只要原子性是否就可以保证一致性?答案当然是否定的。

    比如,事务1 A向B转账100元,在第一步执行完毕之后,恰好另外一个事务2操作是C向A转账200元,并且已经执行完毕,此时执行事务1的第二步,将A账户余额写回数据库,此时事务2的执行结果就被事务1覆盖掉了,造成了数据的不一致(A + B + C 的账户总额保持一致)。

    可见,即使事务1最终执行完毕,满足了原子性,因为另一个事务的影响,还是造成了数据的不一致状态。原子性并不能保证一致性。

    那么,为什么会看到网上还有许多人再问原子性和一致性的问题呢?

    我认为是程序员很容易从数据库事务原子性联想到做应用时多线程并发时的原子性。多线程并发时的原子性基本靠锁来维持,我们认为,有了锁的保护,临界区的资源就不可以被另一个线程访问了。事实上,数据库事务原子性与锁关系不大,锁涉及到了事务的另一个特性:隔离性。

  • 隔离性

    就像在上面谈到的,事务1 与事务2 并行发生,造成了数据的不一致状态。隔离性用来解决这个问题。

    事务隔离性可以保证:如果在A给B转账的同时,有另外一个事务执行了C给B转账的操作,那么当两个事务都结束的时候,B账户里面的钱应该是A转给B的钱加上C转给B的钱再加上自己原有的钱。

  • 持久性

    持久性比较容易理解。即,一旦事务提交(转账成功),所有的数据都会被写入数据库,落地到磁盘。账户中的钱就真的发生了变化。

事务隔离性

从上文可以看出,当并发事务同时访问一个资源时,有可能导致数据不一致,因此需要一种机制来将数据访问顺序化,以保证数据库数据的一致性。锁就是其中的一种机制。我们通过使用锁来保证事务隔离性。

为了理解下面提到的隔离级别,我们简单认识一下数据库中的几种锁:

  • 从锁粒度划分

    表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。

    行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。

    页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。

  • 从锁性质划分

    读锁(S 锁):如果事务A对数据T加了该锁之后,其他事务可以并发读取T(获取该数据的读锁),但任何事务都不能对数据T进行修改(获取数据上的写锁),直到已释放所有读锁。

    写锁(X 锁):如果事务A对数据T加上写锁后,则其他事务不能再对T加任任何类型的锁。获得写锁的事务既能读数据,又能修改数据。

    意向锁: 设计目的主要是为了在一个事务中揭示下一行将要被请求锁的类型。参考

    更新锁:引入它是因为多数数据库在实现加X锁时是执行了如下流程:先加S锁,添加成功后尝试更换为X锁。这时如果有两个事务同时加了S锁,尝试换X锁,就会发生死锁。因此增加U锁,U锁代表有更新意向,只允许有一个事务拿到U锁,该事务在发生写后U锁变X锁,未写时看做S锁。

隔离级别

我们知道了并发事务的隔离性靠锁机制来实现,很多DBMS定义了多个不同的"事务隔离等级"来控制锁的程度和并发能力。

SQL定义的标准隔离级别有四种,从高到底依次为:

  • 可序列化(Serializable)

  • 可重复读(Repeatable reads)

  • 提交读(Read committed)

  • 未提交读(Read uncommitted)

随着数据库隔离级别的提高,数据的并发能力也会有所下降。

下面了解一下这几种隔离级别在数据库中可能的实现。注意,下面的实现都是基于传统数据库,而不是MVCC的。

未提交读

  • 锁机制:

    事务在读数据的时候并未对数据加锁;

    事务在修改数据的时候对数据增加行级S锁。

  • 举例:

Transaction 1 Transaction 2
select * from users where id = 1 // will read 20
update users set age = 21 where id = 1
select age from users where is = 1 // will read 21
roll back

事务一在读取某行数据的时候并未加任何锁,事务二也能对这行数据进行读取和更新;

事务二在更新某行数据的时候对这行数据加了S锁,事务一可以对这行数据进行读取,因此看到了事务二未提交的更改;

事务二更新某行数据对这行数据加了S锁,事务一不能对这行数据进行更新,直到事务二结束。

可以看到,事务一第二次查询看到了事务二未提交的更改,之后这些数据被事务二进行了回滚,于是事务一查询到的数据就成了脏数据,这种现象称之为脏读

未提交读会造成脏读。

提交读

  • 锁机制

    事务对当前被读取的数据加行级S锁(读到时才加),一旦读完该行就释放S锁;

    事务在更新某数据时,必须先对其加行级X锁,直到事务结束才释放。

  • 举例

Transaction 1 Transaction 2
select * from users where id =1 //will read 20
update users set age = 21 where id =1; commit
select * from users where id = 1 //will read 21

事务二在更新数据的时候对数据加了X锁,直到事务结束才释放。所以事务一读取不到事务二未提交的数据。

事务二结束后事务一读取到了与第一次读取中不一致的数据。造成了事务一中两次读取的结果不一致,产生了不可重复读问题。

可重复读

  • 锁机制

    事务对当前被读取的数据加行级S锁,直到事务结束才释放;

    事务在更新某数据时,对其加行级X锁,直到事务结束才释放。

  • 举例

Transaction 1 Transaction 2
select * from users where id =1; commit
update users set age = 21 where id =1; commit

事务一在读取数据时,对数据加了S锁,直到事务结束才释放。因此在此期间,事务二只能读取该数据,不能更新。这样保证了事务一在整个事务期间,无论读取多少次该数据,结果都是一致的,解决了不可重复读的问题。

事务二在更新数据时对数据加了X锁,直到事务结束才释放,在此期间事务一都无法访问和更新该数据,解决了脏读的问题。

Transaction 1 Transaction 2
select * from users where age between 20 and 30
insert into users values(3, 'bob', 25); commit
select * from users where age between 20 and 30

上面的例子中:

事务一查询年龄20到30之间的用户,假设取到10条数据,那么对这10条数据加上了行级S锁;

事务二插入一条数据。由于此时没有任何事务对表添加了表级锁,因此顺利插入;

事务一再一次查询年龄20到30之间的用户,发现与第一次读取时的数据不一致了,多出了一条数据。

这种现象就是幻读。这是一种特殊的不可重复读现象。

可序列化

  • 锁机制

    事务对当前被读取的数据加表级S锁,直到事务结束才释放;

    事务在更新某数据时,对其加表级X锁,直到事务结束才释放。

事务一在读取表记录时,事务二也可以读取该表,但不能对表进行更新、删除、插入等操作;

事务一在更新表记录时,事务二不能够读取该表的任何记录,也不能对表进行更新操作。

可序列化隔离级别避免了脏读、不可重复读和幻读,是最高的隔离级别。

参考

理解MySql事务隔离机制、锁以及各种锁协议,mysql事务

事务并发的可能问题与其解决方案

Innodb中的事务隔离级别和锁的关系

深入分析事务的隔离级别

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,723评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,080评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,604评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,440评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,431评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,499评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,893评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,541评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,751评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,547评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,619评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,320评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,890评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,896评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,137评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,796评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,335评论 2 342

推荐阅读更多精彩内容