1.为什么需要事务?
事务定义
将⼀组操作封装成⼀个执⾏单元(封装到⼀起),要么全部成功,要么全部失败。
为什么要⽤事务?
⽐如转账分为两个操作:
- 第⼀步操作:A 账户 -100 元。
- 第⼆步操作:B 账户 +100 元。
如果没有事务,第⼀步执⾏成功了,第⼆步执⾏失败了,那么 A 账户平⽩⽆故的 100 元就“⼈间蒸
发”了。⽽如果使⽤事务就可以解决这个问题,让这⼀组操作要么⼀起成功,要么⼀起失败。
2.Spring 中事务的实现
Spring 中的事务操作分为两类:
- ⼿动操作事务。
- 声明式⾃动提交事务
在开始讲解它们之前,咱们先来回顾事务在 MySQL 中是如何使⽤的?
3.MySQL 中的事务使⽤
事务在 MySQL 有 3 个重要的操作:开启事务、提交事务、回滚事务,它们对应的操作命令如下:
# 开启事务
start transaction;
# 业务执行
# 提交事务
commit;
# 回滚事务
rollback;
4.Spring ⼿动操作事务
Spring ⼿动操作事务和上⾯ MySQL 操作事务类似,它也是有 3 个重要操作步骤:
- 开启事务(获取事务)。
- 提交事务。
- 回滚事务
SpringBoot 内置了两个对象,DataSourceTransactionManager ⽤来获取事务(开启事务)、提交或回滚事务的,⽽ TransactionDefinition 是事务的属性,在获取事务的时候需要将TransactionDefinition 传递进去从⽽获得⼀个事务 TransactionStatus,实现代码如下:
5.Spring 声明式事务(⾃动事务)
声明式事务的实现很简单,只需要在需要的⽅法上添加 @Transactional 注解就可以实现了,⽆需⼿动开启事务和提交事务,进⼊⽅法时⾃动开启事务,⽅法执⾏完会⾃动提交事务,如果中途发⽣了没有处理的异常会⾃动回滚事务,具体实现代码如下:
运行结果:
没有添加用户成功。 事务回滚生效。
那没有加@Transactional会怎么样?
结果添加成功了。
6.@Transactional 作⽤范围
@Transactional 可以⽤来修饰⽅法或类:
- 修饰⽅法时:需要注意只能应⽤到 public ⽅法上,否则不⽣效。推荐此种⽤法。
- 修饰类时:表明该注解对该类中所有的 public ⽅法都⽣效
7.@Transactional 参数说明
运行结果:
@Transactional 在异常被捕获的情况下,不会进⾏事务⾃动回滚,验证以下代码是否会发⽣事务回滚:
运行结果:
事务回滚没有生效:
事务不会⾃动回滚解决⽅案
解决⽅案1:对于捕获的异常,事务是会⾃动回滚的,因此解决⽅案1就是可以将异常重新抛出,具体实现如下:
运行结果:
事务发生了回滚:
解决⽅案2:⼿动回滚事务,在⽅法中使⽤ TransactionAspectSupport.currentTransactionStatus() 可以得到当前的事务,然后设置回滚⽅法 setRollbackOnly 就可以实现回滚了,具体实现代码如下:
运行结果:
事务发生回滚:
8.@Transactional ⼯作原理
@Transactional 是基于 AOP 实现的,AOP ⼜是使⽤动态代理实现的。如果⽬标对象实现了接⼝,默认情况下会采⽤ JDK 的动态代理,如果⽬标对象没有实现了接⼝,会使⽤ CGLIB 动态代理。
@Transactional 在开始执⾏业务之前,通过代理先开启事务,在执⾏成功之后再提交事务。如果中途遇到的异常,则回滚事务。
@Transactional 实现思路预览:
@Transactional 具体执⾏细节如下图所示:
9.事务隔离级别
事务有4 ⼤特性(ACID),原⼦性、持久性、⼀致性和隔离性,具体概念如下:
- 原⼦性:⼀个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执⾏过程中发⽣错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执⾏过⼀样。
- ⼀致性:在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写⼊的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以⾃发性地完成预定的⼯作。
- 持久性:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
- 隔离性:数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒,隔离性可以防⽌多个事务并发执⾏时由于交叉执⾏⽽导致数据的不⼀致。事务隔离分为不同级别,包括读未提交(Readuncommitted)、读提交(read committed)、可重复读(repeatable read)和串⾏化(Serializable)。
上⾯ 4 个属性,可以简称为ACID。
⽽这 4 种特性中,只有隔离性(隔离级别)是可以设置的.
为什么要设置事务的隔离级别?
设置事务的隔离级别是⽤来保障多个并发事务执⾏更可控,更符合操作者预期的。
什么是可控呢?
⽐如近⼏年⽐较严重的新冠病毒,我们会把直接接触到确证病例的⼈员隔离到酒店,⽽把间接接触者(和直接接触着但未确诊的⼈)隔离在⾃⼰的家中,也就是针对不同的⼈群,采取不同的隔离级别,这种隔离⽅式就和事务的隔离级别类似,都是采取某种⾏动让某个事件变的“更可控”。⽽事务的隔离级别就是为了防⽌,其他的事务影响当前事务执⾏的⼀种策略.
脏读怎么回事?
事务A读取到了事务B修改的数据之后,事务B⼜进⾏了回滚操作,从⽽导致事务A读取的数据是错误的.
不可重复读怎么回事?
⼀个事务两次查询得到的结果不同,因为在两次查询中间,有另⼀个事务把数据修改了.
幻读怎么回事?
⼀个事务两次查询中得到的结果集不同,因为在两次查询中另⼀个事务有新增/删除了⼀部分数
据。
- 幻读和不可重复读有些类似,但是幻读强调的是集合的增减,而不是单条数据的更新。
幻读
说的是存不存在的问题:原来不存在的,现在存在了,则是幻读不可重复读
说的是变没变化的问题:原来是A,现在却变为了B,则为不可重复读- 读取到另一个事务未提交的数据的现象就是脏读
MySQL 事务隔离级别有 4 种
1. READ UNCOMMITTED:读未提交,也叫未提交读,该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据,⽽未提交的数据可能会发⽣回滚,因此我们把该级别读取到的数据称之为脏数据,把这个问题称之为脏读。
2. READ COMMITTED:读已提交,也叫提交读,该隔离级别的事务能读取到已经提交事务的数据,因此它不会有脏读问题。但由于在事务的执⾏中可以读取到其他事务提交的结果,所以在不同时间的相同 SQL 查询中,可能会得到不同的结果,这种现象叫做不可重复读。
3.REPEATABLE READ:可重复读,是 MySQL 的默认事务隔离级别,它能确保同⼀事务多次查询的结果⼀致。但也会有新的问题,⽐如此级别的事务正在执⾏时,另⼀个事务成功的插⼊了某条数据,但因为它每次查询的结果都是⼀样的,所以会导致查询不到这条数据,⾃⼰重复插⼊时⼜失败(因为唯⼀约束的原因)。明明在事务中查询不到这条信息,但⾃⼰就是插⼊不进去,这就叫幻读(Phantom Read)。
4. SERIALIZABLE:序列化,事务最⾼隔离级别,它会强制事务排序,使之不会发⽣冲突,从⽽解决了脏读、不可重复读和幻读问题,但因为执⾏效率低,所以真正使⽤的场景并不多.
在数据库中通过以下 SQL 查询全局事务隔离级别和当前连接的事务隔离级别:
select @@global.tx_isolation,@@tx_isolation;
10.Spring 中设置事务隔离级别
Spring 中事务隔离级别可以通过 @Transactional 中的 isolation 属性进⾏设置,具体操作如下图所示:
Spring 事务隔离级别有 5 种:
- Isolation.DEFAULT:以连接的数据库的事务隔离级别为主。
- Isolation.READ_UNCOMMITTED:读未提交,可以读取到未提交的事务,存在脏读。
- Isolation.READ_COMMITTED:读已提交,只能读取到已经提交的事务,解决了脏读,存在不可重复读。
- Isolation.REPEATABLE_READ:可重复读,解决了不可重复读,但存在幻读(MySQL默认级别)。
- Isolation.SERIALIZABLE:串⾏化,可以解决所有并发问题,但性能太低.
从上述介绍可以看出,相⽐于 MySQL 的事务隔离级别,Spring 的事务隔离级别只是多了⼀个
Isolation.DEFAULT(以数据库的全局事务隔离级别为主)
Spring 中事务隔离级别只需要设置 @Transactional ⾥的 isolation 属性即可,具体实现代码如下:
11.Spring 事务传播机制
Spring 事务传播机制定义了多个包含了事务的⽅法,相互调⽤时,事务是如何在这些⽅法间进⾏传递的。
为什么需要事务传播机制?
事务隔离级别是保证多个并发事务执⾏的可控性的(稳定性的),⽽事务传播机制是保证⼀个事务在多个调⽤⽅法间的可控性的(稳定性的)。
事务隔离级别解决的是多个事务同时调⽤⼀个数据库的问题,如下图所示:
⽽事务传播机制解决的是⼀个事务在多个节点(⽅法)中传递的问题,如下图所示:
事务传播机制有哪些?
Spring 事务传播机制包含以下 7 种:
- Propagation.REQUIRED:默认的事务传播级别,它表示如果当前存在事务,则加⼊该事务;如果当前没有事务,则创建⼀个新的事务。
- Propagation.SUPPORTS:如果当前存在事务,则加⼊该事务;如果当前没有事务,则以⾮事务的⽅式继续运⾏。
- Propagation.MANDATORY:(mandatory:强制性)如果当前存在事务,则加⼊该事务;如果当前没有事务,则抛出异常。
- Propagation.REQUIRES_NEW:表示创建⼀个新的事务,如果当前存在事务,则把当前事务挂起。也就是说不管外部⽅法是否开启事务,Propagation.REQUIRES_NEW 修饰的内部⽅法会新开启⾃⼰的事务,且开启的事务相互独⽴,互不⼲扰。
- Propagation.NOT_SUPPORTED:以⾮事务⽅式运⾏,如果当前存在事务,则把当前事务挂起.
- Propagation.NEVER:以⾮事务⽅式运⾏,如果当前存在事务,则抛出异常.
- Propagation.NESTED:如果当前存在事务,则创建⼀个事务作为当前事务的嵌套事务来运⾏;如果当前没有事务,则该取值等价于 PROPAGATION_REQUIRED
以上 7 种传播⾏为,可以根据是否⽀持当前事务分为以下 3 类:
12.Spring 事务传播机制使⽤和各种场景演示
⽀持当前事务(REQUIRED)
SysLogService设置运行时异常
运行结果:事务回滚!
执⾏结果:程序报错,数据库没有插⼊任何数据。
执⾏流程描述:
- UserService 中的保存⽅法正常执⾏完成。
- LogService 保存⽇志程序报错,因为使⽤的是 Controller 中的事务,所以整个事务回滚。
- 数据库中没有插⼊任何数据,也就是步骤 1 中的⽤户插⼊⽅法也回滚了。
不⽀持当前事务(REQUIRES_NEW)
UserController 类中的代码不变,将添加⽤户和添加⽇志的⽅法修改为 REQUIRES_NEW 不⽀持当前事务,重新创建事务,观察执⾏结果:
运行结果:
程序执⾏结果:User 表中成功插⼊了数据,Log 表执⾏失败,但没影响 UserController 中的事务。
不⽀持当前事务,NEVER 抛异常
运行结果:
程序执⾏报错,⽤户表未添加任何数据.
NESTED 嵌套事务
运行结果:
最终执⾏结果,⽤户表和⽇志表都没有添加任何数据.
执⾏流程描述:
- UserController 中调⽤了 UserService 的添加⽅法,UserService 使⽤ NESTED 修饰循环嵌套了UserController 的事务,并成功执⾏了添加⽅法。
- UserService 中调⽤了 LogService 的添加⽅法,LogService 使⽤ NESTED 修饰循环嵌套了上⼀个调⽤类的事务,执⾏了添加⽅法,但在执⾏的过程中出现了异常,回滚当前事务,⽇志添加失败。
- 因为是嵌套事务,所以⽇志添加回顾之后,往上找调⽤它的⽅法和事务回滚了⽤户添加,所以⽤户添加也失败了,所以最终的结果是⽤户表和⽇志表都没有添加任何数据。
嵌套事务和加⼊事务有什么区别?
先来看嵌套事务 NESTED 示例,示例中使⽤ UserController 调⽤ UserService,UserService 中调⽤LogService,⽽UserService 和 LogService 中的事务传播特性都是 NESTED,具体实现代码如下。
运行结果:
在 LogService 进⾏当前事务的回滚操作,最终执⾏效果是:
User 表中成功添加数据,⽽ Log 表中没有添加数据。
说明:Log 中的事务已经回滚,但是嵌套事务不会回滚嵌套之前的事务,也就是说嵌套事务可以实现部分事务回滚。
而REQUIRED 如果回滚就是回滚所有事务,不能实现部分事务的回滚。
嵌套事务只所以能够实现部分事务的回滚,是因为事务中有⼀个保存点(savepoint)的概念,嵌套事务进⼊之后相当于新建了⼀个保存点,⽽滚回时只回滚到当前保存点,因此之前的事务是不受影响的.
⽽ REQUIRED 是加⼊到当前事务中,并没有创建事务的保存点,因此出现了回滚就是整个事务回滚,这就是嵌套事务和加⼊事务的区别.
嵌套事务(NESTED)和加⼊事务(REQUIRED )的区别:
- 整个事务如果全部执⾏成功,⼆者的结果是⼀样的。
- 如果事务执⾏到⼀半失败了,那么加⼊事务整个事务会全部回滚;⽽嵌套事务会局部回滚,不会影响上⼀个⽅法中执⾏的结果。