目录
1、改变事务2的传播方式REQUIRES_NEW
2、异步调用
业务场景：
业务提交审核（生成审核账单等数据，事务方法1），审核通过（业务看到账单如果没有问题就去手动审核通过，事务方法2），
后期增加了一个自动审核的功能，如果账单中等等一些信息匹配时就直接审核通过，此时，最理想的改动就是中间加个方法，提交审核完成后去主动判断是否能走自动审核通过，也就是事务方法1调用事务方法2，出现了事务回滚不是理想结果的情况，当2出现异常时，提交审核也会被回滚。
事务不生效问题可见：事务不生效
现要实现当事务方法2出现异常时，事务方法1正常提交，事务方法2回滚
1、改变事务2的传播方式REQUIRES_NEW
嵌套事务：就是事务方法A调用事务方法B，外层调用方法和内层被调用方法都是事务方法的情况。
一般我们不关心外层调用方法的事务传播行为（用默认的（不指定就行））。而只关心内层被调用方法的传播行为。
我们一般情况下，会有以下三种需求：
- 外层调用方法和内层被调用方法，有异常一起回滚，没问题一起提交。（共用一个事务）
- 内层被调用方法回滚与否，不会影响外层调用方法。而外层调用方法出异常回滚，也不会回滚内层被调用方法（两个独立的事务）
- 内层被调用方法回滚与否，不会影响外层调用方法。而外层调用方法出异常回滚，也会回滚内层被调用方法（嵌套事务）
这三种情况正好对应三种最常用的传播行为
1----->@Transactional(propagation=Propagation.REQUIRED) ：
内外层方法共用外层方法的事务
2----->@Transactional(propagation=Propagation.REQUIRES_NEW) ：
当执行内层被调用方法时，外层方法的事务会挂起。两个事务相互独立，不会相互影响。
3----->@Transactional(propagation=Propagation.NESTED) :
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，
而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。
结果：改变事务传播方式为ROPAGATION_REQUIRES_NEW，报错，因为事务方法2要用到事务方法1的数据，若不在一个事务，就找不到数据会报错
所以，怎样能让事务方法1与事务方法2无关联，事务方法1调用完事务方法2后就提交，或者说此处就不应该出现事务嵌套
2、异步调用
目前使用的是异步调用解决了当前的问题：一个可以无需等待被调用函数的返回值就让操作继续进行的方法
