RabbitMQ生产端保证消息100投递成功

什么是生产端的可靠性投递

1. 保证消息成功发出
2. 保证 MQ 节点的成功接收
3. 发送端收到 MQ 节点 (borker) 的确认应答
4. 完善的消息补偿机制

互联网大厂生产端可靠性投递方案

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

1. 生产者将业务数据和消息入库，并设置信息状态为 0，即初始待投递
2. 生产者将消息发送至 broker
3. broker 向生产者发送确认
4. 生产者收到 broker 确认后修改消息状态为 1，即消息投递成功
5. 系统定时任务扫描未投递成功的消息
6. 生产者将为成功投递的消息重发给 broker，并记录重发次数
7. 当重发次数大于 3 时，此时修改消息状态为 2，即投递失败。对于投递失败的消息启用补偿机制或人工去处理失败消息

存在问题

在高并发场景下，每次要对业务数据和消息数据入库，数据库会遇到瓶颈。故采用下面的消息的延迟投递，做二次检查，回调确认的方案。

消息的延迟投递，做二次检查，回调确认

1. 先将业务数据入库
2. 生产者第一次向 broker 发送消息
3. 生产者第二次向 broker 发送 check 延迟消息，一般按自己业务设为 2min-5min.
4. Consumer 从 messageQueue 获取消息
5. Consumer 成功消费消息后，向 broker 发送确认消息(设其队列名为ConsumerQueueConfirm)
6. CallbackService 监听ConsumerQueueConfirm，并将成功消费的消息入库MSG DB
7. 同时 CallbackService 监听 checkdetailQueue, 并去MSG DB 查询该消息是否被成功消费
8. 若查询不到 check message，则 CallbackService 向 ProducerService 发送 RPC 请求，让其重发消息，设置重发次数，达到重发次数后，设置其为消费失败
9. 人工处理因网络闪断或者业务问题产生的未成功消费消息，系统消息投递几乎达到 100%

注意

1. 互联网大厂一般不会考虑分布式事务，都用补偿机制。
2. 在高并发下，少做一次数据库持久操作，提高系统处理能力，故将业务和消息的持久化拆开。