一、消息丢失的可能场景消息从生产者到消费者经过以下流程每一步都可能出问题阶段可能丢失的原因发送阶段连接 MQ 失败、Exchange 不存在、路由找不到 Queue、MQ 内部异常MQ 存储阶段消息已入队但未持久化Broker 突然宕机消费阶段消费者收到消息后宕机、处理过程中抛出异常因此可靠性保障需要三管齐下✅ 确保生产者一定把消息发送到 MQ✅ 确保 MQ 不会丢失消息✅ 确保消费者一定成功处理消息二、生产者可靠性保障2.1 生产者重试机制应对网络抖动当RabbitTemplate与 MQ 连接超时时SpringAMQP 提供阻塞式重试机制。配置application.ymlyamlspring: rabbitmq: connection-timeout: 1s # 连接超时时间 template: retry: enabled: true # 开启重试 initial-interval: 1000ms # 初始等待时间 multiplier: 1 # 等待时长倍数 max-attempts: 3 # 最大重试次数⚠️注意重试是阻塞的会占用当前线程。对性能敏感的业务建议禁用重试或用异步线程发送。2.2 生产者确认机制应对路由失败 / MQ 内部异常RabbitMQ 提供两种确认机制机制触发时机Publisher Confirm消息到达 Exchange 后返回ACK/NACKPublisher Return消息从 Exchange 路由到 Queue失败时返回异常信息开启确认机制spring: rabbitmq: publisher-confirm-type: correlated # 异步回调 publisher-returns: true # 开启 Return 机制2.2.1 配置 ReturnCallback统一处理路由失败每个RabbitTemplate只能配置一个ReturnCallback建议在配置类中统一设置Slf4j Configuration AllArgsConstructor public class MqConfig { private final RabbitTemplate rabbitTemplate; PostConstruct public void init() { rabbitTemplate.setReturnsCallback(returned - { log.error(触发 return callback); log.debug(exchange: {}, returned.getExchange()); log.debug(routingKey: {}, returned.getRoutingKey()); log.debug(message: {}, returned.getMessage()); log.debug(replyCode: {}, returned.getReplyCode()); log.debug(replyText: {}, returned.getReplyText()); }); } }当路由失败时日志会输出类似replyCode: 312 replyText: NO_ROUTE2.2.2 配置 ConfirmCallback按消息处理回执由于每条消息的处理逻辑可能不同ConfirmCallback在每次发送时动态定义。发送消息并添加回调Test void testPublisherConfirm() { // 1. 创建 CorrelationData包含唯一 id CorrelationData cd new CorrelationData(); // 2. 添加 ConfirmCallback cd.getFuture().addCallback(new ListenableFutureCallbackCorrelationData.Confirm() { Override public void onFailure(Throwable ex) { log.error(发送消息异常, ex); } Override public void onSuccess(CorrelationData.Confirm result) { if (result.isAck()) { log.debug(收到 ACK消息发送成功); } else { log.error(收到 NACK发送失败原因{}, result.getReason()); } } }); // 3. 发送消息携带 CorrelationData rabbitTemplate.convertAndSend(hmall.direct, q, hello, cd); }2.2.3 回执结果分析场景Confirm 回执Return 回调路由成功✅ ACK不触发路由失败Exchange 存在但 Queue 不存在✅ ACK✅ 触发replyCode312Exchange 不存在❌ NACK不触发建议大多数业务无需开启生产者确认因为路由失败和 Exchange 错误通常是编程问题可以在开发阶段规避。仅在极高可靠性要求的业务中开启且只处理NACK即可。六、总结最佳实践清单层级措施适用场景生产者开启重试机制网络不稳定生产者开启 Confirm Return对可靠性要求极高的业务
)
