什么是事务？
简单的来说，一条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自动管理事务（常用）。
Spring是如何管理事务的呢？
Spring的事务管理主要是有三个接口：
- PlatformTransactionManager：平台事务管理器。定义了进行事务管理的接口，由各个持久层框架自己实现这个接口，进行真正的事务管理操作。
- TransactionDefinition：事务定义信息。定义了一组组常量，例如：隔离级别，传播行为等等。
- TransactionStatus：事务状态。可以获取到事务的各个状态，例如是否有保存点等等。 这三者之间的关系：在Spring进行事务管理时，会先根据TransactionDefinition去进行初始化；然后PlatformTransactionManager的对应持久层框架实现类，通过绑定的datasource去实现数据库操作；而管理过程中会产生一些状态，就保存在了TransactionStatus中。
Spring的事传播行为了解吗？
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就可以自动管理对应的事务操作。
最后对上面四种方式进行总结：
Spring事务管理的实现原理是什么？
这个问题一般默认都是问的声明式事务的实现原理，我们通常的回答就是基于AOP实现的，也就是动态代理。这里在面试的时候，可以和面试官再聊聊代理模式，然后引出动态代理的两种实现方式——JDK动态代理以及CGLIB动态代理。接着说一下这两种实现方式的区别在于是否需要继承接口，最后说清楚为什么JDK动态代理需要实现接口，而CGLIB不需要？——因为动态代理的实现方式和静态代理的方式相同，一个是通过组合方式拿到对应调用，一个是通过继承方式拿到父类调用。关于代理模式，以后也会进行对应的模块总计。
参考书籍及链接：
《MySQL技术内幕InnoDB存储引擎》
《Spring事务管理》
