介绍
结合场景分析实现步骤
第一步：由订单（上游）微服务将消息投递到消息中间件
- 在订单微服务处理生成订单前，首先向消息中间件发送一条消息
- 消息中间件收到消息后将消息持久化，但并不投递，持久化成功后，返回给订单系统一个成功响应
- 订单微服务收到消息持久化成功的应答后，开始执行生成订单的事务操作。
- 生成订单事务完成后，再次向消息中间件发送提交或者回滚的请求，当请求发送完成后，订单微服务的事务处理过程就完成了。
- 消息中间件收到提交的消息，则向商品微服务投递消息；若收到回滚的消息，则将第一条消息丢弃；若超时迟迟没有收到提交/回滚的指令，那么执行“超时询问机制”。
- 超时询问机制需要订单微服务提交一个事务询问的接口，供消息中间件在超时未收到指令的情况下主动调用确认事务状态，此接口可返回三种状态：提交状态、回滚状态、处理中状态。对于提交和回滚状态继续执行上诉步骤5，对于处理中状态则继续等待，继续轮询此接口。
第二步：消息由中间件投递到商品（下游）微服务
- 处理成功：消息中间件收到处理成功的应答便认为事务处理完成
- 处理失败：如果收到处理失败的响应，建议进行人工介入处理，而不是让上游系统回滚，因为回滚的代价巨大（具体可参考 RocketMq事务消息原理及分布式事务场景分析 文中最后的Q&A章节）。
- 超时未收到响应：超时后会再次向下游服务投递消息，直到得到成功/失败的响应为止，这里需要注意处理消息幂等性的问题，避免重复消息。消息中间件可设置超时时间、重试次数和间隔。
总结
- 基于消息中间件实现分布式事务，上游系统使用异步，注重性能，下游系统使用同步，注重开发成功。
- 依旧不能从根本上解决分布式事务的问题
————————————————
版权声明：本文为CSDN博主「小李_同志」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lishuzhen5678/article/details/122878995
