分布式事物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有了异常采用的是重试加上定时器。
感谢观看!