数据库事务的特性、隔离级别、传播策略

概要：ACID、不隔离的问题、隔离级别、隔离级别实现所用的锁

事务的四个特性（ACID）：原子性、一致性、隔离性、持久性

事务不隔离带来的问题：更新丢失、脏读、不可重复读、虚读（幻读）。其中更新丢失就是并发写导致的，这是一定不允许的，因此一定要解决更新丢失问题。

事务隔离的级别：读未提交（1000）、读已提交（1100）、可重复读（1110）、串行化（1111），区别在于解决上述问题的程度不同。

	更新丢失	脏读	不可重复读	幻读
RU（读未提交）	避免
RC（读提交）	避免	避免
RR（可重复读）	避免	避免	避免
S（串行化）	避免	避免	避免	避免

从读、写是否互斥的角度去看事务不隔离的问题及事务隔离级别的内涵会很容易理解！！！

 

1、事务四个特性（ACID）

ACID

如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性（称为ACID特性）：

（1）原子性（Atomicity）

　　原子性是指事务包含的所有操作要么全部成功，要么全部失败并回滚，因此事务的操作如果成功就必须完全应用到数据库，如果操作失败则不能对数据库有任何影响。

（2）一致性（Consistency）

　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。

　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。

（3）隔离性（Isolation）

　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

　　关于事务的隔离性数据库提供了多种隔离级别，稍后介绍。

（4）持久性（Durability）

　　持久性是指一个事务一旦被提交了，那么对数据库中数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

　　例如我们在使用JDBC操作数据库时，在提交事务后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务已正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但数据库因为故障而没有执行事务的重大错误。

  

ACID的MySQL内部实现

 

 MySQL InnoDB存储引擎通过如下方式实现ACID：

※ 事务的隔离性通过数据库锁机制实现（见后文）。
※ 事务的一致性通过 undo log 实现：undo log（回滚日志），是逻辑日志，记录了事务的insert、update、deltete操作，回滚的时候做相反的delete、update、insert操作来恢复数据。
※ 事务的原子性和持久性通过 redo log 实现：redo log（重做日志），是物理日志，事务提交的时候，必须先将事务的所有日志写入redo log持久化，到事务的提交操作才算完成。

redo log作用：为提高IO效率，数据更新时不立即写磁盘而是攒到page大小后再写，故此期间若服务故障则内存数据会丢失，为解决该问题引入了WAL机制——写内存再写持久化日志，redo log就是该用途。

 

2、事务隔离性

事务的隔离性用来解决多个事务并发访问共享资源的问题。

2.1、没有事务隔离带来的问题

总结——如果不考虑事务的隔离性，会发生的几种问题：

更新丢失（此写彼写）：两事务同时写，然后：都回滚则没问题；一回滚一提交 或 都提交 则会出现更新丢失问题。即有更新丢失和更新覆盖两种情形。

脏读（此写彼读）：事务T2读取到事务T1修改且还未提交的数据，之后事务T1又回滚其更新操作，导致事务T2读到的是脏数据。

不可重复读（此读彼写，写是update）：事务T1读取某个数据后，事务T2对该数据做了修改，当事务T1再次读该数据时得到与前一次不同的值。

虚读（幻读）（此读彼写，写是insert/delete）：事务T1读取了某范围数据后，事务T2增或删该范围内的数据，当事务T1再次数据该范围数据时发现不一样了，出现了一些“幻影行”。

脏读和不可重复读的区别：脏读是写时允许别人读导致、读的是另一事务未提交的数据，不可重复读是读时允许别人写导致、读的是前一事务已提交的数据。

不可重复读和幻读的异同：同的是读时允许别人写导致且读的是前一事务已提交的数据；异的是不可重复读读的是同一个数据项、写是update操作，而幻读读的是一个范围内的数据、写是insert/delete操作。

 

啰嗦解释：

（1）更新丢失

1、更新丢失（Lostupdate）

两个事务都做更新操作，一个事务回滚会覆盖另一个事务更新的数据，导致更新丢失

2、两次更新问题（Secondlost updates problem）

两个事务都做更新操作，后提交事务者会覆盖先提交者的更新。

（2）脏读

　　脏读是指在一个事务处中读取了另一个未提交的事务中的数据。

　　当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。例如：用户A向用户B转账100元，对应SQL命令如下：

    update account set money=money+100 where name=’B’;  (此时A通知B)

    update account set money=money - 100 where name=’A’;

　　当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。

（3）不可重复读

　　不可重复读是指对于数据库中的某个数据，一个事务内多次查询却返回了不同的值，这是由于在查询间隔，被另一个事务修改并提交了。

　　例如事务T1在读取某一数据后，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。

　　在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。是否能容忍不可重复读视具体需求而定，MySQL默认是做到可重复读的即不存在该问题。

（4）虚读(幻读)

　　例如事务T1对一个表中一个范围内的所有行的某列做了从“1”修改为“2”的操作，这时事务T2又对该范围内插入了一行数据并且提交给数据库且该数据的那列值还是为“1”。而事务T1若再查看该范围的数据会发现还有一行没有修改，这好像产生幻觉一样，即发生了幻读。删除操作同理，会导致事务1两次读该范围的数据得到的条数不一样。

 

2.2、事务隔离的级别及内部实现

为此我们需要通过提供不同类型的“锁”机制针对数据库事务进行不同程度的并发访问控制，由此产生了不同的事务隔离级别。SQL、SQL2标准定义了四种隔离级别，级别由低到高分别是：

●读未提交（Read Uncommitted）

含义解释：只限制同一数据写事务禁止其他写事务。解决”更新丢失”。（一事务写时禁止其他事务写）

名称解释：可读取未提交事务的数据

所需的锁：排他写锁（事务写时不允许其他事务写但允许读），不加读锁

●读提交（Read Committed）

含义解释：只限制同一数据写事务禁止其它读写事务。解决”脏读”、”更新丢失”。（一事务写时禁止其他事务读写）

名称解释：已提交事务的数据才能被读取

所需的锁：排他写锁（事务写时不允许其他事务读写）、瞬间共享读锁

●可重复读（Repeatable Read）

含义解释：限制同一数据写事务禁止其他读写事务，读事务禁止其它写事务(允许读)。解决”不可重复读”、”更新丢失”、”脏读”。（一事务写时禁止其他事务读写、一事务读时禁止其他事务写）

注意没有解决幻读，解决幻读的方法是增加范围锁或者表锁。

名称解释：重复读取同一数据得到的结果不变

所需的锁：排他写锁（事务写时不允许其他事务读写）、共享读锁（事务读时不允许其他事务写但允许读）

●串行化（Serializable）

含义解释：限制所有读写事务都必须串行化实行。它要求事务序列化执行，即事务只能一个接一个地而能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。（一事务写时禁止其他事务读写、一事务读时禁止其他事务读写）

所须的锁：范围锁（MySQL InnoDB中是gap lock和next-key lock）或表锁

 

下表是各隔离级别对各种异常的控制能力。

	更新丢失	脏读	不可重复读	幻读
RU（读未提交）	避免
RC（读提交）	避免	避免
RR（可重复读）	避免	避免	避免
S（串行化）	避免	避免	避免	避免

　　以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，数据完整性越好，但并发性能就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应视实际情况而定。

 

2.3、常见数据库的默认事务隔离级别

数据库	默认级别
MySQL	可重复读（Repeatable Read）
Oracle	读提交（Read Committed）
SQLServer	读提交（Read Committed）
DB2	读提交（Read Committed）
PostgreSQL	读提交（Read Committed）

　　在MySQL数据库中，支持上面四种隔离级别，默认的为Repeatable read (可重复读)，InnoDB存储引擎默认的就是Repeatable read；此外，MySQL的Repeatable Read隔离级别也解决了幻读问题（通过Gap Locke 和 Next-key lock即范围锁解决不可重复读和幻读问题，如select * from t where a>10 for update会对key为(10,infinite）范围的行加锁，这样其他事务就不能对此范围内key对应的行更改）达到了SQL、SQL2标准中的Serializable级别。

注：MySQL中有两种读，快照读、当前读，两者的幻读问题分别通过加范围锁、MVCC实现，故MySQL的幻读问题是 范围锁+MVCC共同解决的。

在Oracle数据库中，只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别，其中默认的为Read committed级别。

　　在MySQL数据库中查看当前事务的隔离级别：

select @@tx_isolation; #结果：'REPEATABLE-READ'

　　在MySQL数据库中设置事务的隔离 级别：

    set  [glogal | session]  transaction isolation level 隔离级别名称; //设置全部、当前连接的事务隔离级别
    set tx_isolation=’隔离级别名称; //设置当前连接的事务隔离级别

例1：查看当前事务的隔离级别：

　　

例2：将事务的隔离级别设置为Read uncommitted级别：

　　

或：

　　

记住：设置数据库的隔离级别一定要是在开启事务之前！

　　如果使用JDBC对数据库的事务设置隔离级别，也应该是在调用Connection对象的setAutoCommit(false)方法之前。调用Connection对象的setTransactionIsolation(level)即可设置当前链接的隔离级别，至于参数level，可以使用Connection对象的字段：

　　

在JDBC中设置隔离级别的部分代码：

　　

　　后记：隔离级别的设置只对当前连接有效。对于使用MySQL命令窗口而言，一个窗口就相当于一个连接故当前窗口设置的隔离级别只对当前窗口中的事务有效；对于JDBC操作数据库而言，一个Connection对象相当于一个连接故设置的隔离级别只对该Connection对象有效。

 

 3、Spring事务传播

事务的传播行为是指，同一个线程内如果在开始当前事务之前一个事务上下文已经存在，那么此时要怎么执行事务。

需要注意的是，传播是指一个线程内的传播，不同线程间是没有传播一说的，即不同线程间无法在一个事务内（不然还要事务隔离干嘛），因为他们通常是不同的数据库连接。因此子异步线程事务回滚与否不会影响父线程的事务回滚与否。

以Java中的Spring Transaction为例，Spring中有声明式事务和编程式事务，前者以注解的形式使用的，内部借助AOP实现。声明式事务存在事务传播、事务失效问题。

关于事务传播，在TransactionDefinition接口定义中包括了如下几个表示传播行为的常量（3+3+1）：

• TransactionDefinition.PROPAGATION_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是默认值。
• TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
• TransactionDefinition.PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
• TransactionDefinition.PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。
• TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
• TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。
• TransactionDefinition.PROPAGATION_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则新建事务。

示例可参阅：https://blog.csdn.net/f641385712/article/details/98642777

在Java SpringMVC项目中Controller方法调Service方法时常会有两方法都加 @Transactional 的情形，此时就涉及到事务传播。

关于事务失效，至少有如下情形会导致声明式事务失效：

@Transactional 的事务传播类型 propagation 设置不当，例如用PROPAGATION_NOT_SUPPORTED。

@Transactional 的 rollbackFor 设置错误导致有些异常抛出时不会触发回滚。

@Transactional 所修饰方法非public。

同一类内的方法间调用，假设方法A调方法B：

B被@Transactional修饰而A没有，则事务不会生效。须从类外部调用@Transactional 所修饰方法事务才会生效，这是因为这时才用的事代理类。

A被@Transactional修饰而B没有，但A调B时完全try catch了异常且catch中不再抛出异常，此时事务也不生效。

 

参考资料：

1、http://www.cnblogs.com/fjdingsd/p/5273008.html

2、http://www.2cto.com/database/201603/495078.html