通过MQ的延时消息来解决订单/库存服务直接调用的事务问题

一、如何解决下单系统这个高并发里边的分布式事务呢？

首先，我们肯定不会用 2PC 模式、 TCC-事务补偿性方案，我们也不考虑

最终我们选择可靠消息+最终一致性这种方式

为了保证高并发，订单这一块还是自己回滚，

因为性能不佳，我们弃用seata的方案

1、库存服务自己怎么回滚？

通过MQ消息队列，我们在提交订单那里，当捕捉到异常要回滚的时候，给库存服务发一个消息，让库存服务自己把库存解锁

这样不需要让库存事务回滚，只需要给它发一个消息，不会损失什么性能

库存服务本身也可以使用自动解锁模式。

需要使用消息队列来完成。

如果你想让我这的哪些库存解锁，首先你需要给我发一个消息告诉我。

然后我们专门的库存解锁服务，去来订阅我们/login.html");

最终监听order.release.order.queue这个队列的释放订单服务，发现有消息进来了，就会针对里面的数据对其进行关闭订单

这种关闭订单方式会有一些问题

假设订单创建成功之后，订单服务的机器由于卡顿、消息延迟等原因，导致订单未及时取消

此时库存服务的逻辑是订单创建成功之后，它自己会发一个消息，等 40分钟 以后检查之前下单的订单是否已取消，如果是已取消，则解锁库存

结果，库存服务过来查询时，订单服务由于上述原因没有将订单修改为已取消，所以库存就不会解锁，此时的库存消息就算是消费了

等库存服务都检查完了，此时的订单服务才反应过来，然后把订单状态改为已取消了，但是此时库存服务会再有任何的操作了，因为检查订单的消息已经被消费了，库存永远得不到解锁。

为了解决这个问题，我们在监听取消订单的消息时，再发一个消息，主动解锁库存。

具体是这样的，在释放订单之后，我们主动发一个消息解锁库存，

库存服务有对这个队列进行监听，所有一旦有数据来了，就会对其进行解锁库存服务