如何实现mq生产者消息的可靠性投递

---

一、生产者消息丢失原因

  由于消息中间件有着削峰、解耦等好处，已经在业界得到了广泛的应用。
　　常见的应用场景为：

　　这里的订单系统为生产者，结算系统为消费者。
　　但是一般而言，MQ中间件为了提高系统的吞吐量，会把消息保存在内存中。如果不作其他处理，MQ服务器一旦意外宕机，生产者投递的消息将全部丢失。
　　因此，我们需要达到两个目标：
　　（1）消息持久化
　　（2）消息投递成功的确认机制

---

二、解决办法

1、MQ持久化 + 确认回调机制

  许多MQ都支持将内存中的消息持久化到磁盘中。比如RabbitMQ，其在发消息的时候有个durable参数可以设置。设置为true，就会持久化。
　　而是否持久化成功，是由MQ来进行回调通知的。比如RabbitMQ就有一个confirm机制：

（1）消息生产者把消息发送给MQ，如果接收成功，MQ会返回一个ack消息给生产者
（2）如果消息接收不成功，MQ会返回一个nack消息给生产者

  通过开启mq的持久化，以及使用其确认回调机制，在一定程度上已经解决了消息丢失的问题。

1.1、缺陷

  然而，为了吞吐量，MQ不可能每条消息都直接持久化到磁盘中，而是要先积累到一定量之后才会持久化。在这过程中如果MQ服务器宕机，这部分数据依旧会丢失。
　　因此，也就有了下面的这个方案。

2、消息提前持久化 + 定时任务补偿机制 + 接口幂等

流程图如下：

流程说明如下：

（1）订单服务生产者在投递消息之前，先把消息持久化到Redis或DB中，建议Redis，高性能。消息的状态为发送中。
（2）confirm机制监听消息是否发送成功？如ack成功消息，删除Redis中此消息。
（3）如果nack不成功的消息，这个可以根据自身的业务选择是否重发此消息。也可以删除此消息，由自己的业务决定。
（4）这边加了个定时任务，来拉取隔一定时间内，消息状态还是为发送中的，这个状态就表明，生产者没有收到ack成功消息。
（5）定时任务会作补偿性的投递消息。这个时候如果MQ回调ack成功接收了，再把Redis中此消息删除。
（6）定时任务那边我们还可以加上一个补偿的次数，如果大于3次，还是没有收到ack消息 ，那就直接把消息的状态设置为【失败】，由人工去排查到底是为什么

2.1、注意点

（1）这里的补偿机制，生产者可能会发送多次同样的消息。因此，消息者必须保证消费时的幂等性。
　　 消费方的幂等性在后续的其他文章中，再进行详细描述。
（2）本方案也需要保障MQ的高可用，比如跨机房集群等

---

参考文章