RabbitMQ消息的可靠性投递

可靠性

1. 保障消息成功发送出去
2. 保障mq节点成功接收消息
3. 消息发送端需要收到mq服务的确认应答
4. 完善的消息补偿机制（百分百成功成功，需要该步骤）

方案

消息落库方案

订单服务调用物流服务举例子

1. 在创建订单的操作的时候，把数据插入到订单相关的表中，把消息插入到消息表中，初始状态为0（发送中）
2. 把物流消息投递到消息队列中
3. 消息队列访问一个确认消息,并且由订单服务来监控mq server的确认消息
4. 根据收到的确认消息来更新数据库中的消息记录的状态为1已确认
5. 使用定时任务抓取超过5分钟未确认的消息进行重新发送

特点

在第一步的过程中，既插入了业务数据表，也同时插入了消息记录表，进行了二次db操作，在高并发的环境下，这个环境就会造成性能瓶颈

延时投递，回调检测

1. 先将业务数据进行入库，然后生产端将消息发送出去，在发送消息之后，紧接着生产端再次发送一条消息(Second Send Delay Check)，即延迟消息投递检查，这里需要设置一个延迟时间，比如5分钟之后进行投递
2. 消费端去监听指定队列，将收到的消息进行处理，处理完成之后，发送一个confirm消息，也就是回送响应，但是这里响应不是正常的ACK，而是重新生成一条消息，投递到MQ中，上面的Callback service是一个单独的服务，其实它扮演了方案一的存储消息的DB角色，它通过MQ去监听下游服务发送的confirm消息，如果Callback service收到confirm消息，那么就对消息做持久化存储，即将消息持久化到DB中
3. 5分钟之后延迟消息发送到MQ了，然后Callback service还是去监听延迟消息所对应的队列，收到Check消息后去检查DB中是否存在消息，如果存在，则不需要做任何处理，如果不存在或者消费失败了，那么Callback service就需要主动发起通信给上游服务，告诉它延迟投递的这条消息没有找到，需要重新发送，生产端收到信息后就会重新查询业务消息然后重复步骤1发送消息和延迟检测消息。

特点

主要目的是为了减少数据库操作，提高并发量，在高并发场景下，最关心的不是消息100%投递成功，而是一定要保证性能，保证能抗得住这么大的并发量，所以能减少数据库的操作就尽量减少，可以异步的进行补偿