最终一致性(二)

基于MQ的分布式事务补偿机制

序列图

异常场景处理

1. 预创建订单失败:如果实际预创建订单成功,订单定时补偿机制,定时删除这部分订单,不影响数据一致性,下单失败

2. 预扣减库存失败:如果预扣减库存真实失败,则下单失败(订单由定时补偿机制定时删除,其它应用参照场景4的处理方式,下单失败;如果实际预扣减库存成功,参照场景4的处理方式,下单失败

3. 实际创建订单失败:如果创建订单真实失败(不需要发送下单失败消息,防止实际创建订单成功场景)
   ,订单的预处理数据通过订单的定时补偿机制尝试删除(需要考虑事务处理时间,将超过某个时间范围该事务还处于预处理状态的订单删除),下单失败;如果实际创建订单成功,其它应用参照场景4的处理方式,下单成功(提示用户下单失败)

4. 发送订单创建成功消息失败/库存服务由于各种原因没有接到下单成功消息:库存服务定时轮询处理数据(需要考虑事务处理时间,将超过某个时间范围该事务还处于预处理状态的订单筛选出来),询问订单服务改订单Id对应的订单是否创建成功,根据订单创建成功与否选取相应的事务补偿机制

和TCC的比较

1. TCC是把所有的订单创建步骤平等看待,只要有一个失败,整个下单流程全部失败(比较TCC里面的confirm失败和基于MQ实际创建订单失败的补偿难易程度)

2. TCC是通过发消息给TCC服务器,然后由TCC服务调用应用服务;基于MQ的分布式事务补偿机制,是通过将消息发送到MQ,然后由应用自己去监听MQ的事件

关键字：java, 分布式, 分布式事务, 事务

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！