什么是生成端的可靠性投递：

1. 保障消息的成功发出

2. 保障MQ节点的成功接收

3. 发送端收到MQ节点（Broker）确认应答

4. 完善的消息进行补偿机制

业界主流解决方案：

1. 消息落库，对消息状态进行打标志，比如状态改为1表示成功收到，轮询抓取状态为0的消息重新发送，到最大努力次数达到成功，比如说3次5次。

2. 消息的延迟投递，做二次确认，回调检查。

一：

1. 先入库开始状态0

2. 发消息MQ Broker

3. confirm 应答给我们的生产端， Confirm Listener 异步监听响应的 confirm，监听超时如果5分钟后还是0的状态就重试步骤2,3

4. 将指定这条记录抓取出来，然后更新，比如消息的状态从0更新为1，表示确认这条消息100%投递成功

5. status0 重试有限制，比如重试超过3次，状态改成2.

二：

高并发场景：

消息的延迟投递，做二次确认，回调检查。

先入库，在发消息

1. 把消息发出去。

2. 设置延迟投递消息检查，比如2分钟，3分钟后MQ Broker才收到

3. Broker收到进行处理

4. 处理完发送confirm确认的消息到MQ

5. 由Callback监听confirm消息，确认服务成功的处理了，然后做MSG DB持久化

6.如3分钟 Check Detail监听延迟投递的消息收到消息了，然后去检查MSG DB数据库，确认Upstream的确添加成功。

如果没找到，发送RPC ReSend Command 给Upsteam service 说明延迟检查的消息没有找到，你要重新ReSend一遍。重新发一遍消息。重新走一遍流程。