数据库事务

数据库事务

在关系型数据库中，事务的重要性不言而喻，只要对数据库稍有了解的人都知道事务具有 ACID 四个基本属性，我们只要将ACID 弄清楚，数据库事务也就掌握了。

1. 原子性（Atomicity）

这个最好理解。

事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，只允许出现两种状态之一。

• 全部执行成功
• 全部执行失败

任何一项操作都会导致整个事务的失败，同时其它已经被执行的操作都将被撤销并回滚，只有所有的操作全部成功，整个事务才算是成功完成。

mysql数据库的原子是通过Undo log来实现。UndoLog的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为UndoLog）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态

2. 一致性（Consistency）

 这个是最难实现的。

事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处以一致性状态。对于这个概念，它的第一层意思就是对于数据完整性的约束，包括主键约束、引用约束以及一些约束检查等等，在事务的执行的前后以及过程中不会违背对数据完整性的约束，所有对数据库写入的操作都应该是合法的，并不能产生不合法的数据状态。

3. 隔离性（Isolation）

这个是最难理解的。

事务的隔离性是指在并发环境中，并发的事务是互相隔离的，一个事务的执行不能被其它事务干扰。也就是说，不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间。

要想真正的做到操作之间完全没有任何干扰是很难的，于是乎，每天上班打酱油的数据库专家们，开始动脑筋了，“我们要制定一个规范，让各个数据库厂商都支持我们的规范！”，这个规范就是：事务隔离级别（Transaction Isolation Level）。能定义出这样牛逼的规范真的挺不容易的，其实说白了就四个级别：

1. READ_UNCOMMITTED 可读未提交
2. READ_COMMITTED 可读已提交
3. REPEATABLE_READ 可重复读
4. SERIALIZABLE 串行化

从上往下，级别越来越高，并发性越来越差，安全性越来越高，反之则反。

 

其实，定义这四个级别就是为了解决数据在高并发下所产生的问题，那又有哪些问题呢？

1. Dirty Read（脏读）
2. Unrepeatable Read（不可重复读）
3. Phantom Read（幻读）

首先看看“脏读”，看到“脏”这个字，我就想到了恶心、肮脏。数据怎么可能脏呢？其实也就是我们经常说的“垃圾数据”了。比如说，有两个事务，它们在并发执行（也就是竞争）。看看以下这个表格，您一定会明白我在说什么：

 

时间	事务 A（存款）	事务 B（取款）
T1	开始事务
T2		开始事务
T3		查询余额（1000 元）
T4		取出 1000 元（余额 0 元）
T5	查询余额（0 元）
T6		撤销事务（余额恢复为 1000 元）
T7	存入 500 元（余额 500 元）
T8	提交事务

余额应该为 1500 元才对！请看 T5 时间点，事务 A 此时查询余额为 0 元，这个数据就是脏数据，它是事务 B 造成的，明显事务没有进行隔离，渗过来了，乱套了。

所以脏读这件事情是非常要不得的，一定要解决掉！让事务之间隔离起来才是硬道理。

那第 2 条，不可重复读又怎么解释呢？还是用类似的例子来说明：

 

时间	事务 A（存款）	事务 B（取款）
T1	开始事务
T2		开始事务
T3		查询余额（1000 元）
T4	查询余额（1000 元）
T5		取出 1000 元（余额 0 元）
T6		提交事务
T7	查询余额（0 元）

事务 A 其实除了查询了两次以外，其他什么事情都没有做，结果钱就从 1000 变成 0 了，这就是重复读了。可想而知，这是别人干的，不是我干的。其实这样也是合理的，毕竟事务 B 提交了事务，数据库将结果进行了持久化，所以事务 A 再次读取自然就发生了变化。

这种现象基本上是可以理解的，但在有些变态的场景下却是不允许的。毕竟这种现象也是事务之间没有隔离所造成的，但我们对于这种问题，似乎可以忽略。

最后一条，幻读。我去！Phantom 这个单词不就是“幽灵、鬼魂”吗？刚看到这个单词时，真的把我的小弟弟都给惊呆了。怪不得这里要翻译成“幻读”了，总不能翻译成“幽灵读”、“鬼魂读”吧。其实意义就是鬼在读，不是人在读，或者说搞不清楚为什么，它就变了，很晕，真的很晕。还是用一个示例来说话吧：

时间	事务 A（统计总存款）	事务 B（存款）
T1	开始事务
T2		开始事务
T3	统计总存款（10000 元）
T4		存入 100 元
T5		提交事务
T6	统计总存款（10100 元）

银行工作人员，每次统计总存款，都看到不一样的结果。不过这也确实也挺正常的，总存款增多了，肯定是这个时候有人在存钱。但是如果银行系统真的这样设计，那算是玩完了。这同样也是事务没有隔离所造成的，但对于大多数应用系统而言，这似乎也是正常的，可以理解，也是允许的。银行里那些恶心的那些系统，要求非常严密，统计的时候，甚至会将所有的其他操作给隔离开，这种隔离级别就算非常高了（估计要到 SERIALIZABLE 级别了）。

归纳一下，以上提到了事务并发所引起的跟读取数据有关的问题，各用一句话来描述一下：

1. 脏读：事务 A 读取了事务 B 未提交的数据，并在这个基础上又做了其他操作。
2. 不可重复读：事务 A 读取了事务 B 已提交的更改数据。
3. 幻读：事务 A 读取了事务 B 已提交的新增数据。

第一条是坚决抵制的，后两条在大多数情况下可不作考虑。

这就是为什么必须要有事务隔离级别这个东西了，它就像一面墙一样，隔离不同的事务。看下面这个表格，您就清楚了不同的事务隔离级别能处理怎样的事务并发问题：

 

事务隔离级别	脏读	不可重复读	幻读
READ_UNCOMMITTED	允许	允许	允许
READ_COMMITTED	禁止	允许	允许
REPEATABLE_READ	禁止	禁止	允许
SERIALIZABLE	禁止	禁止	禁止

   MySQL的默认事务隔离级别是：Repeatable Read

  SQL Server的默认事务隔离级别是：Read Commited

  Oracle数据库支持Read Commited 和 Serializable这两种事务隔离级别。Oracle 默认使用的是Read Commited

数据库的隔离性是通过锁来实现的。

锁一般可以分为两类，一个是悲观锁，一个是乐观锁，悲观锁一般就是我们通常说的数据库锁机制，乐观锁一般是指用户自己实现的一种锁机制，比如hibernate实现的乐观锁甚至编程语言也有乐观锁的思想的应用。

悲观锁：顾名思义，就是很悲观，它对于数据被外界修改持保守态度，认为数据随时会修改，所以整个数据处理中需要将数据加锁。悲观锁一般都是依靠关系数据库提供的锁机制，事实上关系数据库中的行锁，表锁不论是读写锁都是悲观锁。

悲观锁按照使用性质划分：

• 共享锁（Share locks简记为S锁）：也称读锁，事务A对对象T加s锁，其他事务也只能对T加S，多个事务可以同时读，但不能有写操作，直到A释放S锁。

• 排它锁（Exclusivelocks简记为X锁）：也称写锁，事务A对对象T加X锁以后，其他事务不能对T加任何锁，只有事务A可以读写对象T直到A释放X锁。

• 更新锁（简记为U锁）：用来预定要对此对象施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；当被读取的对象将要被更新时，则升级为X锁，主要是用来防止死锁的。因为使用共享锁时，修改数据的操作分为两步，首先获得一个共享锁，读取数据，然后将共享锁升级为排它锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个对象申请了共享锁，在修改数据的时候，这些事务都要将共享锁升级为排它锁。这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申请更新锁，在数据修改的时候再升级为排它锁，就可以避免死锁。

悲观锁按照作用范围划分：

• 行锁：锁的作用范围是行级别，数据库能够确定那些行需要锁的情况下使用行锁，如果不知道会影响哪些行的时候就会使用表锁。举个例子，一个用户表user，有主键id和用户生日birthday当你使用update … where id=?这样的语句数据库明确知道会影响哪一行，它就会使用行锁，当你使用update … where birthday=?这样的的语句的时候因为事先不知道会影响哪些行就可能会使用表锁。
• 表锁：锁的作用范围是整张表。

乐观锁：顾名思义，就是很乐观，每次自己操作数据的时候认为没有人回来修改它，所以不去加锁，但是在更新的时候会去判断在此期间数据有没有被修改，需要用户自己去实现。既然都有数据库提供的悲观锁可以方便使用为什么要使用乐观锁呢？对于读操作远多于写操作的时候，大多数都是读取，这时候一个更新操作加锁会阻塞所有读取，降低了吞吐量。最后还要释放锁，锁是需要一些开销的，我们只要想办法解决极少量的更新操作的同步问题。换句话说，如果是读写比例差距不是非常大或者你的系统没有响应不及时，吞吐量瓶颈问题，那就不要去使用乐观锁，它增加了复杂度，也带来了额外的风险。

乐观锁实现方式：

• 版本号（记为version）：就是给数据增加一个版本标识，在数据库上就是表中增加一个version字段，每次更新把这个字段加1，读取数据的时候把version读出来，更新的时候比较version，如果还是开始读取的version就可以更新了，如果现在的version比老的version大，说明有其他事务更新了该数据，并增加了版本号，这时候得到一个无法更新的通知，用户自行根据这个通知来决定怎么处理，比如重新开始一遍。这里的关键是判断version和更新两个动作需要作为一个原子单元执行，否则在你判断可以更新以后正式更新之前有别的事务修改了version，这个时候你再去更新就可能会覆盖前一个事务做的更新，造成第二类丢失更新，所以你可以使用update … where … and version=”old version”这样的语句，根据返回结果是0还是非0来得到通知，如果是0说明更新没有成功，因为version被改了，如果返回非0说明更新成功。
• 时间戳（timestamp）：和版本号基本一样，只是通过时间戳来判断而已，注意时间戳要使用数据库服务器的时间戳不能是业务系统的时间。
• 待更新字段：和版本号方式相似，只是不增加额外字段，直接使用有效数据字段做版本控制信息，因为有时候我们可能无法改变旧系统的数据库表结构。假设有个待更新字段叫count,先去读取这个count,更新的时候去比较数据库中count的值是不是我期望的值（即开始读的值），如果是就把我修改的count的值更新到该字段，否则更新失败。java的基本类型的原子类型对象如AtomicInteger就是这种思想。

• 所有字段：和待更新字段类似，只是使用所有字段做版本控制信息，只有所有字段都没变化才会执行更新。

4. 持久性（Duration）

事务的持久性是指事务一旦提交后，数据库中的数据必须被永久的保存下来。即使服务器系统崩溃或服务器宕机等故障。只要数据库重新启动，那么一定能够将其恢复到事务成功结束后的状态。

数据库持久性通过redo log（重做日志）来实现，RedoLog记录的是新数据的备份。在事务提交前，只要将RedoLog持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是RedoLog已经持久化。系统可以根据RedoLog的内容，将所有数据恢复到最新的状态。