分布式事务_如何解决微服务分布式事务问题

MQ消息事务-RocketMQ

先说说MQ的分布式事务，RocketMq在4.3版本已经正式宣布支持分布式事务，在选择Rokcetmq做分布式事务请务必选择4.3以上的版本。

事务消息作为一种异步确保型事务， 将两个事务分支通过 MQ 进行异步解耦，RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：

这个时候我们基本可以认为，只有MQ发送方自己的本地事务执行完毕，那么MQ的订阅方必定百分百能够接收到消息，我们再对下单减库存的步骤进行改造：

这里涉及到一个异步化的改造，我们理一下如果是同步流程中的各个步骤

查看商品详情（或购物车）

计算商品价格和目前商品存在库存（生成订单详情）

商品扣库存（调用商品库存服务）

订单确认（生成有效订单）

订单创建完成后，发布一个事件“orderCreate” 到消息队列中，然后由MQ转发给订阅该消息的服务，因为是基于消息事务，我们可以认为订阅该消息的商品模块是百分百能收到这个消息的。

商品服务接受到orderCreate消息后就执行扣减库存的操作，注意，这里可能会有一些不可抗的因素导致扣减库存失败，无论成功或失败，商品服务都将发送一个扣减库存结果的消息“stroeReduce”到消息队列中，订单服务会订阅扣减库存的结果。

订单服务收到消息后有两种可能：

如果扣减库存成功，将订单状态改为 “确认订单” ，下单成功

如果扣减库存失败，将订单状态改为 “失效订单” ，下单失败

这种模式将确认订单的流程变成异步化，非常适合在高并发的使用，但是，切记了，这个需要前端用户体验的一些改变，要配合产品来涉及流程。

完美，使用MQ分布式事务就可以解决调一致性问题

MQ消息事务方案的风险了解一下

上面使用MQ的方式确实是可以完成A和B操作，但是A和B并不是严格一致性，而是最终一致性，我们牺牲掉严格一致性，换来性能的提升，这种很适合在大促高并发场景总使用，但是如果B一直执行不成功，那么一致性也会被破坏，后续应该考虑到更多的兜底方案，方案越细系统就将越复杂。