事务（Transaction）是并发控制的单位，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位
事务的隔离级别
脏读：事务1更新数据，未提交时，事务2读取，事务2读取的是事务1修改后的值，此时事务1出错回滚，导致事务2脏读；
不可重复读：事务1多次查询，查询1与查询2期间，事务2修改了数据并提交，事务1中查询1与查询2获取的数据不一致
幻读：事务1多次查询，查询1与查询2期间，事务2新增了数据，事务1中查询1与查询2获取的数据不一致
- READ UNCOMMITTED（读未提交）: 事务执行时可以看到其他事务“没有提交的新增+修改”记录。可以读到一个事务的中间过程，违背了事务的隔离性，基本不会使用。
结果：导致脏读，导致不可重复读，导致幻读- READ COMMITTED （读已提交） : 事务执行时可以看到其他事务“已经提交的新增+修改”记录。
结果：避免脏读，导致不可重复读，可能导致幻读- REPEATABLE READ（可重复读）: 事务执行时可以看到其他事务“已经提交的新增”记录。
结果：避免脏读，避免不可重复读，可能导致幻读(mvcc机制优化)（了解间隙锁，也可解决幻读）- SERIALIZABLE （串行化）: 事务执行时看不到其他事务对数据库所做的更新。两个事务实际上是串行化方式运行。
结果：避免脏读，避免不可重复读，避免幻读
Spring隔离界别体现
@Transactional(isolation = Isolation.DEFAULT)
Isolation.DEFAULT 即默认与数据库一致
查看mysql数据库隔离级别
SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;
Mysql默认的事务隔离级别是REPEATABLE-READ。
SERIALIAZABLE如何保证隔离级别
SERIALIAZABLE事务隔离级别采用使用 2PL（Two-Phase Locking，两阶段锁）机制来控制本地事务的并发，保证隔离性。2PL 是将锁操作分为加锁和解锁两个阶段，并且保证两个阶段完全不相交。加锁阶段，只加锁，不放锁。解锁阶段，只放锁，不加锁。在一个本地事务中，每执行一条更新操作之前，都会先获取对应的锁资源，只有获取锁资源成功才会执行该操作，并且一旦获取了锁资源就会持有该锁资源直到本事务执行结束。MySQL 通过这种 2PL 机制，可以保证在本地事务执行过程中，其他并发事务不能操作相同资源，从而实现了事务隔离。由于读写都需要上锁，性能差。
MVCC（Multi Version Concurrency Control，多版本并发控制）
mvcc查用快照版本，增删改用最新版本，超卖等场景解决方案之一
MySql通过内部机制避免幻读，在rr隔离级别下几乎达到了串行化隔离级别的效果。
InnoDB是在undolog中实现的MVCC，通过undolog可以找回数据的历史版本。
MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和MVCC不兼容, 因为 READ UNCOMMITTED 总是读取最新的数据行, 而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。
InnoDB存储引擎在数据库每行数据的后面添加了三个字段
事务ID(DB_TRX_ID)字段: 用来标识最近一次对本行记录做修改(insert|update)的事务的标识符, 即最后一次修改(insert|update)本行记录的事务id。
回滚指针(DB_ROLL_PTR)字段: 指写入回滚段(rollback segment)的 undo log record (撤销日志记录)。
DB_ROW_ID字段: 表中没有主键或合适的唯一索引, 也就是无法生成聚簇索引的时候, InnoDB会帮我们自动生成聚集索引, 聚簇索引会使用DB_ROW_ID的值来作为主键; 如果我们有自己的主键或者合适的唯一索引, 那么聚簇索引中也就不会包含 DB_ROW_ID 了。
对于删除操作，mysql底层会记录好被删除的数据行的回滚事务id，对于更新操作，mysql底层会新增一条相同数据并记录好对应的事务id。
在RR级别下，快照读（简单的select操作）是通过MVVC和undo log来实现的
当前读(select ... lock in share mode，select ... for update，insert，update，delete)是通过加record lock(记录锁)和gap lock(间隙锁)来实现的。
事务的传播行为
1：PROPAGATION_REQUIRED
如果当前没有事务，就新建一个事务，如果已经存在一个事务中，则加入该事务。
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚。
2：PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行
3：PROPAGATION_MANDATORY
必须在一个事务中运行，否则就要抛出异常。
4：PROPAGATION_REQUIRES_NEW
新建事务，如果当前事务存在，则把当前事务挂起
比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。
5： PROPAGATION_NOT_SUPPORTED
以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。
6：PROPAGATION_NEVER
以非事务方式执行操作，如果当前存在事务，则抛出异常。
假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，那么ServiceB.methodB就要抛出异常了。
7：PROPAGATION_NESTED
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。而Nested事务的好处是他有一个savepoint。
解决Transactional注解不回滚
1、检查你方法是不是public的，不能作用在方法的内部的任何方法上
2、你的异常类型是不是unchecked异常,即运行时异常 （java里面将派生于Error或者RuntimeException（比如空指针,数组越界,1/0）的异常称为unchecked异常，其他继承自java.lang.Exception得异常统称为Checked Exception，如IOException、TimeoutException等）。如果想check异常也想回滚怎么办，注解上面写明异常类型即可@Transactional(rollbackFor=Exception.class)。类似的还有norollbackFor，自定义不回滚的异常
3、数据库引擎要支持事务，如果是MySQL，注意表要使用支持事务的引擎，比如innodb，如果是myisam，事务是不起作用的
4、是否开启了对注解的解析（Springboot不需关注，Springboot会自动配置，5同）
<tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"/>
5、spring是否扫描到你这个包，如下是扫描到org.test下面的包
<context:component-scan base-package="org.test" ></context:component-scan>
6、检查是不是同一个类中的方法调用（如a方法调用同一个类中的b方法）
7、异常是不是被你catch住了
解决不能作用在方法的任何内部方法上
1.注入本身service，在当前处理service注入自己，然后内部调用 推荐
2.(1).在未定义事务的方法调用带有事务的方法使用AopContext.currentProxy()((AfterSaleManager)AopContext.currentProxy()).innerRefund(goodsReturnsApply); 可用
(2).spring配置文件配置
<aop:aspectj-autoproxy expose-proxy="true"/>
3、重新定义对象 applicationContext.getBean() 未测试
4、使用@Aspect注解 未测试
希望在编译期间进行织入(weaving)，还是编译后(post-compile)或是运行时(run-time)。Spring只支持运行时织入，你可以选择使用AspectJ编译后(post-compile)或载入时(load-time)织入。Spring基于代理模式（使用CGLIB），它有一个使用限制，即无法在使用final修饰的bean上应用横切关注点。
借鉴：https://juejin.im/post/5b90cbf4e51d450e84776d27
