实现步骤
步骤1 - 可靠的消息生产记录消息发送
隐患
- 可能消息发送失败：
-
基于RabbitMQ消息队列的分布式事务解决方案(下)4 总结 - 为确保数据一定成功发送到MQ。在同一事务中，增加一个记录表的操作, 记录
每一条发往MQ的数据以及它的发送状态
- 于是在订单系统中增加一个本地信息表
不再通过HTTP请求直接调用运单系统接口，而是使用MQ：
生成订单时，也保存本地信息表
步骤2-可靠消息生产(修改消息发送状态)
- 利用RabbitMQ的事务发布确认机制(confirm)：开启后，MQ准确受理消息会返回回执
-
基于RabbitMQ消息队列的分布式事务解决方案(下)4 总结
然后就能知道如何更新本地信息表
确保在SpringBoot项目中开启Confirm机制
代码实现
-
若出现回执没收到、消息状态修改失败等特殊情况
兜底方案：定时检查消息表，超时没发送成功，再次重发。
步骤3 - 可靠消息处理(正常处理)
- 运单系统收到消息数据后，突然宕机或访问运单DB时，DB突然宕机，消息数据不就丢了？
-
基于RabbitMQ消息队列的分布式事务解决方案(下)4 总结 - 于是还需要如下处理：
➢ 幂等性
防止重复消息数据的处理，一次用户操作，只对应一次数据处理
➢ 开启
手动ACK模式
由消费者控制消息的重发/清除/丢弃
步骤4 - 可靠消息处理(消息重发)
消费者处理失败，需要MQ重发给消费者。出现异常一般会重试几次，由消费者自身记录重试次数，并进行次数控制。
步骤五 - 可靠消息处理(消息丢弃)
消费者处理失败，直接丢弃或者转移到死信队列(DLQ)。
重试次数过多、消息内容格式错误等情况，通过线上预警机制通知运维
4 总结
MQ实现分布式事务分析
优点
- 通用性强
- 拓展性强
- 方案成熟
缺点
- 基于消息中间件，只适合异步场景
- 消息处理会有延迟，需要业务上能够容忍
尽量避免分布式事务，尽量将非核心事务做成异步。
参考
https://tech.meituan.com/2018/07/26/peisong-sys-arch-evolution.html