什么是生成端的可靠性投递：
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一遍。重新发一遍消息。重新走一遍流程。