消息落库
1.搞一个消息记录表，发送消息前，做一个消息状态标识
2.消息传递到Broker中后，Confirm回调通知生产者进行消息状态更新
3.可靠性投递-并不包含消息成功消费<br>
4.搞一个定时Job，按照业务设置时间进行定时处理状态未改变的消息，进行尝试，多次失败后，不再进行重发
延时投递
说明
考虑到如上方案会进行至少两次Db的操作，因此阻塞性能，不再依赖生产者进行消息状态更新<br>
优化
引入第三方服务，进行接收二次投递检查消息和消费端成功消费通知的消息(更新消息状态)
1.生产者在原有业务消息的基础上再传递二次确认消息进行处理(第三方服务处理该消息)-也是Mq消息吗<br>
2.消费端服务处理完逻辑后，发送确认消费消息到第三方服务中-通过MQ吗<br>
3.第三方服务接收消费端确认消息后，更新消息的状态
4.第三方服务接收到二次核查消息后，进行判断消息的状态，出现问题后，回调发送端服务(如何进行回调呢)，进行重试发送<br>
问题
生产者的二次核查消息优先于消费端发送的消息，到达第三方服务的时候，此时让生产者再次发送重试也是没问题的
