MQ 保证消息安全投递并消费

可能出现消息丢失的情况

1. Producer在把Message发送Broker的过程中，因为网络问题等发生丢失，或者Message到了Broker，但是出了问题，没有保存下来

针对这个问题，Producer可以开启MQ的事务，如果这个过程出现异常，进行回滚，但是有个很大的问题，你提交一个事务就会阻塞在那，非常影响性能，生产环境肯定不会开启事务，一般都是使用confirm机制

3. Broker接收到Message暂存到内存，Consumer还没来得及消费，Broker挂掉了

可以通过持久化设置去解决：(1) 创建Queue的时候设置持久化，保证Broker持久化Queue的元数据，但是不会持久化Queue里面的消息; (2) 将Message的deliveryMode设置为2，可以将消息持久化到磁盘，这样只有Message支持化到磁盘之后才会发送通知Producer ack。
这两步过后，即使Broker挂了，Producer肯定收不到ack的，就可以进行重发。

5. Consumer有消费到Message，但是内部出现问题，Message还没处理，Broker以为Consumer处理完了，只会把后续的消息发送

这时候，就要关闭autoack，消息处理过后，进行手动ack

生产端如何保证可靠性投递？

• 保证消息的成功发出

• 保证MQ节点的成功接收

• 发送端收到MQ节点（Broker）的确认应答

• 完善的消息补偿机制

解决方案

1. 消息落库，对消息状态进行变更，对于高并发环境下数据库压力很大，因为需要写多次数据库
   整体流程：

• 业务数据和消息都进行落库
• 生产端发送message给Broker
• Broker给Confirm响应返回生产端
• 接收到confirm，对message状态更改
• 分布式定时任务获取消息的状态
• 如果消息不能成功投递，重新进行发送，记录重发次数
• 当重发3次之后，将状态修改，只能人工进行干预