一、方案一的简介和优缺点

1、方案一简介：

在方案一当中，我们采用的是在发送MQ消息的时候去会落库msg并设置初始状态，然后在消费的时候去维护这个msg的状态来实现可靠性

2、方案一的优点：

• 大大提高了可靠性
• 同时补偿方案做的也比较完善

3、方案一的缺点：

• 消息未到达broker的几率是比较低的，但是却用了一整套的流程来控制
• 需要多次操作数据库，在高并发的环境下是不适用的
  • 发送消息写一次数据
  • 接收到confirm或者return更新一次
  • 消费者接受消息前读一次幂等
  • 消费者消费完成后更新一次状态

二、方案二：

2.1、示意图：

2.2、各个步骤的解释：

• step1：获取业务全局ID，其实这个规则还是比较好生成的，例如redis每天唯一递增，然后我们写回redis并写入附带信息：生成时间、重试次数
• step2：我们把我们的订单信息转化成MQ msg
• step3：发送MQ msg
• step4：消费者消费MQ msg，
• step5：删除Redis中的唯一的ID，同时这个地方也可以判断幂等
• step6：定时查看Redis中的全局唯一ID，对比现在的生成时间，如果超5分钟，则调用生产者的补偿接口，如果达到充实次数，则人工介入处理。

2.3、需要注意的点：

Redis全局ID的生成时间对比：

• 取决于你的生成速率和消费速率只差
• 取决于你的业务的敏感程度，如果实时性要求高(这个生成和消费的速率肯定不会慢)，这个差值则设置小一点

这个一定要设置合理，否则的话会有大量的数据去走补偿接口，同时走补偿接口也要控制接口的速率，

2.4 优缺点：

优点：

• 并发性更高
• 通过redis速度回更快
• 减少了IO的次数，我们这这样正常情况只需要走2次即可
• 减小针对于小量失败的情况的处理代价，更加有的放矢
• 不需要处理生产者的confirm和消费者的应答处理
• 流程更加简洁
• 使用更少的资源来处理少量的补偿信息

缺点

• 引入第三方中间件 redis 增加维护的复杂性，这里面我们默认redis是可靠的
• 是否决定走补偿接口的参数调节对业务的影响比较大，其实这个地方第一个方案里面也是有这方面的影响，如果时间设置不合理，则会在MQ生成大量的重复消息