深入浅出数据库事务

前言

说到数据库事务，很多人就会想事务的ACID即原子性，一致性，隔离性，持久性，以及事物的四个隔离级别，但是并不是很明白为什么要用这四个特性来保证事务，以及事务的隔离级别是怎么产生的？包括LZ之前看《高性能MySQL》关于事务的介绍也是一脸蒙蔽，因为太抽象了。偶然在慕课网上看到《在线分布式数据库原理与实践》这个视频，讲的挺不错的。特地总结一波，分享一下，相信读完本文你可以轻松理解这些概念

事务简介

我们在写Java程序，遇到并发问题时，会想到用锁来解决。数据库遇到并发问题怎么解决呢？答案就是事务，事务的本质就是锁和并发的结合体

单个事务单元

举个例子Bob给smith转账100块，会有如下几个操作

这里需要对Bob账户和Smith账户进行加锁保证只有一个线程可以操作这些账户

例如，这里线程1进去以后，线程2和线程3就会在外面等待，这样就保证了只有线程1能看到中间状态，如从Bob账户减去100还没来得及给Smith账户加上，此时Bob账户为0，Smith账户也为0，而线程2和3只能看到要么Bob有100块，要么Smith有100块。这样事务就保证了一致性，即要么Bob有100块，要么Smith有100块，而不会有中间状态

一组事务单元

假如我们现在有3个事务单元
Bob给Smith100块
Smith给joe100块
Smith给Bob100块

因为有对共同账户的锁定，所以在上一个事务没有完成时，下个事务只能排队等待，这样性能是很低的
前人总结了事务单元之间的Happen-before关系，只有如下四种
读写，写读，读读，写写
事务如何保证上面四种操作的逻辑顺序的同时用最快的速度完成？

排队法（序列化读写）

将所有的请求放到一个队列里面，从队头执行到队尾、
优势：不需要冲突控制

排他锁（针对同一个单元的访问进行控制）

原来我们是将所有的请求放在一个队列，能不能放在不同队列中呢？例如Bob给Smith100块，Joe给Lisa100块，这个2个不同的事务单元，完全可以并行起来，如何做呢？直接加锁就可以

如果Bob给Smith100块，Smith给Bob100块，因为这2个事务有共享单元，所以不能并行

读写锁

上面我们已经提到事务之间的Happen-before关系只有四种，读写，写读，读读，写写，如果把读锁和写锁分离开，就可以让读并行，对于读多写少的任务就可以提高并行度

MVCC

现在主流的数据库实现是MVCC（多版本并发控制）
本质就是copy on write，能够做到写不阻塞读
MVCC能够做到写读不冲突，读读不冲突，读写也不冲突，唯一冲突的就是写和写，这样系统并发读就可以非常高

MVCC 提供了时点（point in time）一致性视图。MVCC 并发控制下的读事务一般使用时间戳或者事务 ID去标记当前读的数据库的状态（版本），读取这个版本的数据。读、写事务相互隔离，不需要加锁。读写并存的时候，写操作会根据目前数据库的状态，创建一个新版本，并发的读则依旧访问旧版本的数据

一句话讲，MVCC就是用 同一份数据临时保留多版本的方式 ，实现并发控制

深入单机事务

我们来看一下事务的ACID（原子性，一致性，隔离性，持久性）

原子性

原子性：一个事务要么同时成功，要么同时失败
以前面的Bob给Smith转账为例，我们换一个视角，从数据库角度看，数据库存储的版本有哪几个？

如上图列出了所有的状态，以第二个步骤为例，转账时发现Smith这个账户并不存在，则状态需要回滚到ver1，该怎么回滚呢？其实当每次操作时，数据库会记录回滚段（即上图的undo信息），当需要回滚时按照undo信息回滚即可，假如ver3事务提交超时，则先将ver3回滚到ver2，再将ver2回滚到ver1即可，这就是事务的原子性，即要么Bob有100块，Smith有0块，要么Bob有0块，Smith有100块

原子性的语意只保证记了一个回滚段，这个回滚段能回滚到之前的版本，接着来说一致性，为什么需要一致性呢？接着上面再举个例子

假如说执行到ver2的时候，有另外一个进程将Smith的钱加到300，那么当事务1回滚的时候，会将Smith的钱改为0，Smith的300块就不翼而飞了，但是从原子性的定义来说它并不关心这个事，它只负责记录undo日志能回滚就行

一致性

一致性的核心是Can（happen before）

如图，当多个事务单元执行时，视点关系有三种，一个事务在另一个事务之前或者之后发生（视点1和视点2），和两个事务同时发生（视点3），上文已经说到当事务1执行到ver2时，事务2对Smith账户进行了修改，当事务1回滚的时候会造成数据不一致的情况，为了避免这种情况，所以事务1会在操作时加锁，这样就会将视点3的请求上移到视点1，因为视点3获取不到Bob和Smith的锁，被迫等待。

这样做其实就是将所有的请求排队的过程，当然不是一个队列，因为会将锁下退到每个数据之上的，上文已经提到，一致性能保证看到系统内的所有更改，但是如果这样做，系统的并发是上不来的。例如，如果有一个事务锁定了这2个账号，其他所有的对这个2个账号的操作都不可能并行，只能等在外面。这样系统不得不选择另外一个概念，隔离性。

隔离性

隔离性：以性能为理由，对一致性的破坏
事务的隔离级别有4个SERIALIZABLE（可串行化），REPEATABLE READ(可重复读)，READ COMMITTED（提交读）,READ UNCOMMITTED（未提交读）,

排他锁

如果要保证一致性，只要保证事务的happen-before关系即可，但是当要保证对一个事务单元的绝对的强一致性，只有将所有的事务排队，这就是隔离级别中的可串性化（SERIALIZABLE），用排他锁保证单位时间只能有一个事务进来，当然性能非常低

读写锁

读写锁有2个隔离级别，可重复读（REPEATABLE READ），提交读（READ COMMITTED），这2个隔离级别是怎么产生的？

读写锁有一个很重要的概念（或者选择），读锁能不能被写锁升级，即当对一个事务单元加了一个读锁的时候，如果有新的写进来，这个读要不要放开，让写进去。

当读锁不能被写锁升级时，只能做到读读可并行，即可重读级别，这样并不能完美的提高系统性能，于是有另外一个隔离级别出来，这个隔离级别就是读已提交。

提交读这个隔离级别，读锁可以被写锁升级，如当2个读针对一个事务单元加了一个读锁的时候，一个新的写来了，允许写请求将读锁升级为写请求，这样可以做到读读并行，读写并行（写读还不能哦）

说一下可重复读和读已提交的区别，如果事务有2个并行的读，第二个人可以读到之前一个人读到的数据，这就叫可重复读。但如果读写可以并行，会出现如下情况，第一次读到版本号为1的数据，第二次写是并行的，可以更新到这个数据，如果再次读这个数据，可能读到的数据版本是不同的，于是就会出现不可重复读。

只加写锁，不加读锁

未提交读这个隔离级别就是只加写锁，不加读锁，这样可以做到读读并行，读写并行，写读并行
读读并行，读写并行

写读并行（由上一步转化）

写读并行（由上一步转化）

问题：可能读到写过程中的数据，因为读没有加锁，只加了一个写锁，所以可能读到内部没有提交完成的数据，所以一般不用这个隔离级别，因为会读到中间状态

持久性

事务完成以后，该事务对数据库所做的更改便持久的保存在数据库之中

后记

最后附上《高性能MySQL》中对隔离级别的定义，加深理解

READ UNCOMMITTED（未提交读）

在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。

READ COMMITTED（提交读）

大多数数据库系统的默认隔离级别都是READ COMMTTED（但MySQL不是）。READ COMMITTED满足前面提到的隔离性的简单定义：一个事务开始时，只能"看见"已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候叫做不可重复读（nonrepeatble read），因为两次执行同样的查询，可能会得到不一样的结果

REPEATABLE READ(可重复读)

REPEATABLE READ解决了脏读的问题。该隔离级别保证了在同一个事务中多次读取同样记录结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（Phantom Read）的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）。InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。

SERIALIZABLE（可串行化）

SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE会在读取每一行数据都加锁，所以可能导致大量的超时和锁争用问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
READ UNCOMMITTED	Yes	Yes	Yes	No
READ COMMITTED	No	Yes	Yes	No
REPEATABLE READ	No	No	Yes	No
SERIALIZABLE	No	No	No	Yes

简单总结一下：
原子性，张三给李四转钱，要么成功，要么失败
一致性，张三给李四转钱，张三和李四2个人总的钱数是不变的
隔离性，为了提高多个事务的并发度而提出的一个概念，定义多个事务同时执行的影响程度
持久性，对数据的更改持久化在数据库中

参考博客

[1]https://www.imooc.com/learn/272
数据库的四个隔离级别
[2]https://blog.csdn.net/u011296485/article/details/77675781
MVCC实现
[3]https://www.cnblogs.com/YFYkuner/p/5178684.html
视频地址
[4]https://www.imooc.com/learn/272