消息生产端的可靠性投递方案

生产端的可靠性投递：

• 保证生产端消息成功发出
• 保证mq节点成功接收
• 发送端收到MQ的确认应答
• 完善的消息补偿机制

方案一：

消息落库，对消息状态进行打标

以订单模型为例 （消息状态 0：发送中；1：发送成功；2：消息发送失败）

1. 订单消息先落库，并且 要发送的消息也落库,例如落到消息日志表
2. 生产者发送消息
3. MQ Broker如果收到这个消息，会给生产者发送一个确认，确认收到这个消息（应答）
4. 生产者需要写一个监听，监听上面的应答。再根据这个应答去操作日志记录表，将消息状态改为1（成功）
5. 定时任务定时去拉去消息日志表，状态为0,发送中（一般为超时）消息
6. 将定时任务拉出来的状态为0的消息，重投消息，直到状态为1
7. 记录当前这条消息重投次数，设置最大努力次数，如果超过设置的最大努力次数（比如上面的3次），就将消息状态改为2（失败），这种状态，人工去解决
   （如果步骤3出现断连，会出现重复投递问题，需要消费端自己去做幂等）

方案二：

消息的延迟投递，做二次确认，回调检查
（高并发场景下避免方案一的第一步两次insert操作，将写msgDB异步化）

1. 生产端讲消息入库，然后发送消息到MQ
2. 生产端发送一条延迟消息，用于检查该消息投递是否成功（发送到callback服务）
3. 消费段监听获取到消息进行消费
4. 消费完成后，消费端发送一条消息到MQ，表示此条消息消费完成（发给callback服务的）
5. callback服务监听消费端发送过来的confirm消息，然后将消息入库
6. callbakc服务监听到身缠段发送过来的check消息，去msg DB查询该消息是否消费完成
7. 如果callback服务在check消息时候，在msg db没有查到该条消息，说明投递失败，会通过RPC调用高速生产端重新投递消息。