RabbitMQ

基于erlang语言开发，具备语言级别的高并发能力。支持持久化、高可用

核心五个概念：

• Queue：真正存储数据的地方
• Exchange:接受请求，转存数据
• Bind:收到请求后存储到哪里
• 消息生产者：发送数据的应用

• 消息消费者：取出数据处理的应用

  
  1.png

分布式事务解决方案

• 基于数据库XA/JTA协议的方式：需要数据库厂商支持；JAVA组件有atomikos等
• 异步校对数据的方式：支付宝、微信支付主动查询致支付状态、对账单的形式
• 基于可靠消息(MQ)的解决方案：异步场景；通用性较强，扩展性较高
• TCC编程式解决方案：严选、阿里自己封装的DTX

1. 多系统之间的分布式事务问题

   
   2.png

2. 错误示例

   
   3.png

实现分布式事务的五个场景

1. 整体设计思路

   
   4.png

2. 可靠消息生产-记录消息发送

   
   5.png

3. 可靠性消息生产- 修改消息发送状态

   
   6.png

注意兜底方案：是开启定时任务类似于进行扫表

4. 可靠性消息处理-正常处理

   
   7.png

之所以有幂等问题，是因为在订单中心有可能出现重发(消息回执不及时等导致的)，此时在运单中心可以通过id等信息去数据库判断是否有，有的话就直接告知mq删除该条消息，没有的话则正常操作，而且操作成功后才告知mq删除消息。

5. 可靠消息处理-消息重发

   
   8.png

一般记录重试次数用redis等；至于如果是网络问题mq等送到消费者失败的话相当于通道断开则mq在连接成功后会自动重新推送。

6. 可靠消息处理-消息丢弃
   如上图，如果重试次数过多，不应该重复尝试，则进入消息丢弃

   
   9.png

7. 缺点

• 基于消息中间件，只适合异步场景
• 消息处理会有延迟，需要业务上能容忍
• 基本没有事务回滚了，业务上必须成功不能失败(例如：外卖订单，付钱了必须成功)