还是我经常说的那句话，没有分布式，Java其实挺简单，一有分布式，所有的问题都需要考虑一遍，变引发了各种系统性的架构演变，一切都是分布式惹的祸！
现在考虑一个问题：
订单提交：
@Transactional
public void submitOrder(){
1 、 生成订单
2、 锁定库存
3、 扣用户积分
}
这个方法中有三个逻辑，每个逻辑都是一个很复杂的方法，如果方法出现异常，变回滚，貌似是没有问题的，但仔细想想会出现以下问题：
image.png
1、远程服务假失败
远程服务成功了，但是由于网络原因没有返回数据导致订单回滚，库存却扣减。
2、远程服务区执行成功，后面的方法出现问题，导致已执行的远程请求不能回滚。
所以必须使用分布式事务才能解决！
回顾本地事务，以防面试问到：
image.png
事务还有传播机制等，说的是一个方法调用了其他方法，其他方法是否使用该方法的事务。
本地事务中springboot有一个非常好的注解@Transactional ,但有一个漏洞需要说明一下，看示例代码：
public void a(){
b();
c();
}
image.png
a方法设置了事务的传播机制以及过期时间等诸多设置，b,c 方法也有自己的事务的设置选项，如果b方法和c方法和a同在一个service类中，那么b和c方法设置的事务是无效的，如果b和c是其他类中的方法，设置是有效的。
如何解决这个问题呢？
就是使用代理机制。
image.png
通过aop中的aspectJ创建代理对象，然后通过代理对象调用本地的方法，便可以成功解决。
这里需要复习spring 动态代理和jdk动态代理的区别。
