简单的来说,一条SQL执行或则几条SQL一起执行时,我们希望这个SQL要么执行成功后提交,要么执行失败后回滚,这是我们最直观的理解。在上面这句话中,就包含了事务的几个必要属性:"执行成功后提交",意味着持久性;"执行失败后回滚",意味着一致性;"要么成功,要么失败",意味着原子性。他们的具体理解如下:
- 原子性(A):事务要么执行成功,要么执行失败,没有第三种状态。
- 一致性(C):事务执行的前后数据要一致,也就是说执行成功后数据的更改和预期一致,执行失败需要回滚到更改前数据。
- 隔离性( I ):多个事务并发执行时,相互隔离,互不影响。
- 持久性(D):事务提交后,对数据的更改是永久性的。也就说,哪怕数据库崩溃了,那些数据也是可以被恢复过来的。
事务的实现分为两个部分,一个是数据库底层的事务实现,另外一个是基于Spring去实现事务管理。这里主要是讲数据库(mysql-innodb)层面的实现。下面会围绕上面所说的ACID属性来讲mysql的底层实现。
redo日志与原子性、持久性的关系
redo日志是mysql-innodb底层的一个日志文件,主要记录当前数据页的物理修改日志,也就是可以记录事务执行过程中对数据页的更改情况。
如果事务执行了一半数据库宕机了,那么根据redo日志来恢复,可以恢复到事务开始前的数据版本,也就是哪怕宕机了也不存在中间状态,这就是redo日志来保证事务执行的原子性。
持久性的关键点其实在于数据恢复,也就是事务提交后数据的更改永久存在,哪怕宕机了也可以恢复到宕机前的数据。redo日志因为记录的数据页的物理修改情况,所以就可以根据它来恢复数据,保证持久性。
redo日志如此重要,但是它也会有丢失数据的风险,所以mysql的数据安全不能完全指望redo日志去保证,还需要做一些备份处理。具体redo日志的介绍,参考《MySQL技术内幕InnoDB存储引擎》。
undo日志与一致性的关系
undo日志也是mysql-innodb底层的一个日志文件,主要记录事务执行过程中,对具体数据行的修改。可以把它理解成一个数据快照,保存着事务开始前以及执行过程中的各个数据更改前的数据快照。
一致性的理解分为事务执行成功与执行失败两种情况。执行成功要求数据的更改与预期一致,这个其实是上面说的持久性,也就是更改成功后永久存在,我下次再来查数据是存在的;另外就是执行失败需要回滚,这里就是需要用到redo日志了,redo日志相当于一个快照,在事务执行失败后,innodb引擎回去找到对应的快照去做回滚,从而保证了事务的一致性。
redo日志还被用来实现MVCC,也就是常说的"多版本并发控制"。主要也是用的快照属性,在多个事务并发执行时,查询对应的数据时(非锁定读),会直接去查对应的快照,从而实现了一定的隔离性。
另外,redo日志还分为两种类型,更新删除类型和插入类型,这个类型的区别主要是在于记录的内容和删除的方式不同,不过与本篇的主题"事务"没有太大关系,请自行参考《MySQL技术内幕InnoDB存储引擎》。
next_key lock与隔离性的关系
在了解隔离性之前,我们先了解一下,事务并发执行可能带来的一些数据安全性问题:
- 脏读:A事务读到了B事务未提交的数据。举个栗子:DB中某商品的库存为2,B事务去扣减库存执行库存-2的操作,但是未提交;此时A去查库存,查到了B未提交的数据,也就是库存为0了,就给客户返回购买失败;但是事务B又执行失败了,那么这两笔交易都未能完成。也就是说A事务读到了不准确的数据,也就是脏数据,就叫做脏读。
- 不可重复读:A事先查了一个数据;B事务将那个数据改了,并提交;A事务再去查,发现第二次查询的数据和第一次的数据不一致了。
- 幻读:A事先查了一个范围内数据有10条;B事务在这个范围内又插入了10条,并提交;A事务再去查,发现第二次查询的数据比第一次查询的数据多了。幻读跟不可重复的区别在于,幻读是新插入了数据,而不可重复读是更新了数据。
- 修改丢失:A事务对某一个数据执行修改,B事务也对该数据执行修改,最后导致只有其中一个事务的修改是成功的,另外一个事务的修改操作丢失了。
以上的一些问题,都需要隔离级别来解决对应的问题。事务的隔离性主要分为四种:
- Read uncommitted:读未提交,也就是A事务可以读到B事务未提交的数据,数据很不安全。除了修改丢失问题外都会发生,丢失修改只需要加锁操作就OK了。
- Read committed :读已提交,也就是也就是A事务可以读到B事务已提交的数据,数据相对安全。这个就是oracle的默认隔离级别。这个隔离级别下可以防止脏读,但是不可重复读和幻读都可能发生。
- Repeatable read :可重复读,也就是A事务开启后,前后查询数据是一致的,除非是自己事务内修改了数据。这个隔离级别是mysql的默认隔离级别,原本是无法防止幻读的,但是mysql-innodb引入了next_key lock从而在Repeatable read实现了Serializable级别的所有要求。
- Serializable:串行化。也就是所有事务全都一个个来执行,也就没有了所有的并发问题,但是吞吐量也会因此降得极低。 综上可知,mysql-innodb默认隔离级别是Repeatable read。解决不可重复读的问题是基于undo实现的MVCC,每次读取都会去读取对应的事务开始前的快照数据;而解决幻读是基于next_key lock,幻读的发生是因为有其他事务往对应的数据范围内插入了数据,因此mysql-innodb对该范围都加上了一个锁,不然其他事务插入,从而解决掉了幻读问题,实现了完备的隔离性要求。
Spring的事务管理方式有两种,一种是编程式事务,自己手动去执行事务的一些提交、回滚等操作;还有一种是声明式事务,通过配置或者注解配置好事务管理器,然后由Spring自动管理事务(常用)。
Spring的事务管理主要是有三个接口:
- PlatformTransactionManager:平台事务管理器。定义了进行事务管理的接口,由各个持久层框架自己实现这个接口,进行真正的事务管理操作。
- TransactionDefinition:事务定义信息。定义了一组组常量,例如:隔离级别,传播行为等等。
- TransactionStatus:事务状态。可以获取到事务的各个状态,例如是否有保存点等等。 这三者之间的关系:在Spring进行事务管理时,会先根据TransactionDefinition去进行初始化;然后PlatformTransactionManager的对应持久层框架实现类,通过绑定的datasource去实现数据库操作;而管理过程中会产生一些状态,就保存在了TransactionStatus中。
Spring的传播行为主要作用是解决在Spring中各个Service层相互调用时,事务范围划分的问题。例如A方法调用B方法时,事务如何传播。Spring的事务传播行为分为三大类:
- A调用B:让A与B的操作在同一事务中,否则如何如何。
- A调用B:让A与B的操作不在同一事务中,否则如何如何。
- 嵌套事务:根据设置去执行,例如当前事务有保存点,是直接回滚还是回滚到保存点。
具体官方说明:
举个栗子: Spring默认的隔离级别是REQUIRED,因此如果使用默认值,A方法调用B方法时,B方法中执行的操作会加入到A方法中的事务去执行。
如果A设置为REQUIRED级别,B设置为SUPPORTS,也会加入到A事务中。如果A也是SUPPORTS那么就都以非事务方式执行。
就如上文所说,编程式和声明式事务的最大区别就在于事务管理操作的主动与被动。以下Demo是基于上的课程进行的总结,大家可以在文末找到课程的链接,课程是免费的。
编程式事务的实现Demo:
配置:PlatformTransactionManager(以下简称manager),datasource与manager绑定后,配置TranscationTemplet。
使用:代码中注入TranscationTemplet 手动执行 transcationTemplet.execute()函数。
声明式事务的实现Demo1:基于TransactionProxyFactoryBean。 配置:配置manager,并与datasource绑定,然后给每个需要事务的业务层配置代理,有N个类就需要配置N个代理。 使用:在代码中使用的时候,只需要注入对应配置的代理类,然后执行函数就可以自动进行事务管理了。
声明式事务的实现Demo2:基于AspectJ。 配置:配置manager,并与datasource绑定。然后配置advice与manager绑定,接着配置pointcut,最后将advice与pointcut组成一个aop切面。 使用:代码中不需要做任何的侵入操作,只需要编写符合规则的函数名称,Spring就可以自动生成代理类去进行事务管理。
声明式事务的实现Demo3:基于@Transactional注解。 配置:配置manager,并与datasource绑定。最后开启注解事务即可。 使用:代码中使用@Transactional注解修饰需要进行事务管理的类或者函数,Spring就可以自动管理对应的事务操作。
最后对上面四种方式进行总结:
这个问题一般默认都是问的声明式事务的实现原理,我们通常的回答就是基于AOP实现的,也就是动态代理。这里在面试的时候,可以和面试官再聊聊代理模式,然后引出动态代理的两种实现方式——JDK动态代理以及CGLIB动态代理。接着说一下这两种实现方式的区别在于是否需要继承接口,最后说清楚为什么JDK动态代理需要实现接口,而CGLIB不需要?——因为动态代理的实现方式和静态代理的方式相同,一个是通过组合方式拿到对应调用,一个是通过继承方式拿到父类调用。关于代理模式,以后也会进行对应的模块总计。
参考书籍及链接:
《MySQL技术内幕InnoDB存储引擎》
《Spring事务管理》