分布式事物confirm的底层原理
在order的try阶段：
首先会冻结库存和建余额账户。并且注册一个事务组，他们是通过id一致绑定在一起的。
try阶段走完过后，就会执行confirm的方法。
总结：try阶段注册事物组，然后try和confirm阶段都是由事务管理器来管理的，try阶段执行完过后就会进入confirm阶段。
如何解决分布式事务的try异常
我们在order的try阶段设置一个异常：
在confirm中设置断点：
测试日志中就会出现执行cancel：
我们就可以得出如果try阶段出现了异常，这几个服务都会执行cancel操作。
这是怎么做到的呢？
因为他们在try阶段就都注册了事务组，而且他们的id都是一样的，如果order的try出现了异常，就会通知库存和账户执行cancel阶段。如果一个执行cancel，所有的都会执行cancel。
从这段代码，我们就可以知道，如果try出现异常，就会执行cancel。
如何解决分布式事务的confirm异常?
首先，我们在confirm阶段中制造一个异常：
出现的结果：
它会睡眠120毫秒然后重新尝试。
如果解决？
第一先把bug修复，然后重启服务。
2分钟过后就会重新尝试，然后重新执行。
所以confirm有了异常采用的是重试加上定时器。
感谢观看！
