RabbitMQ消息可靠性：发送确认、消费者ACK与SpringAMQP实战

大家好，我是晚安code。

刚接触 RabbitMQ 那会儿，我以为消息发出去就万事大吉了。踩的坑多了才明白：消息可靠性的核心不是某一道防线，而是每一层都有兜底。丢消息不一定是 MQ 的锅------可能是你生产者发出去就没确认，也可能是消费者抛了个异常消息就没了。

本文以 SpringAMQP 为例，带你搭建 RabbitMQ 消息可靠性的四道防线。文中涉及的配置和代码（2026 年 7 月实测，适用于 Spring Boot 3.x + RabbitMQ 3.12+）可以直接拿去用。

一、发送者确认：消息出门之前的第一道锁

Publisher Confirm（发送者确认）是消息可靠性的第一道防线，它解决的问题很直接------你发出去的消息，到底到没到 Broker？

很多开发者用 rabbitTemplate.convertAndSend() 发完消息就不管了，默认情况下这个方法不会告诉你消息投递的结果。网络波动了、Exchange 写错了、队列绑错了------你都不知道。

Publisher Confirm（发送者确认）：RabbitMQ 提供的消息投递回执机制。生产者发送消息后，Broker 在消息成功路由并持久化后，向生产者返回 ACK 回执；如果消息无法路由或持久化失败，则返回 NACK。你可以理解为快递寄出后的「已签收」短信通知。

SpringAMQP 提供了三种 Confirm 模式：

模式	行为	适用场景
`NONE`	关闭 Confirm，发完不管	允许丢消息的非关键场景
`SIMPLE`	同步阻塞等待 Broker 回执	吞吐量要求不高的场景
`CORRELATED`	异步回调方式接收回执	生产环境推荐，不阻塞业务线程

再配上一个容易被忽略的 Publisher Return------当消息投递到了 Exchange 但路由到队列失败时（比如 RoutingKey 写错了），Broker 会回调 ReturnCallback 告诉你路由异常的具体原因。

看配置：

yaml 复制代码

spring:
  rabbitmq:
    publisher-confirm-type: correlated   # 开启异步 Confirm
    publisher-returns: true              # 开启 Return 回调

光配 YAML 不够，ReturnCallback 需要在启动时注册：

java 复制代码

@Configuration
public class MqConfig {
    @PostConstruct
    public void init(RabbitTemplate rabbitTemplate) {
        rabbitTemplate.setReturnsCallback(returned -> {
            log.error("消息路由失败: exchange={}, routingKey={}, replyCode={}",
                returned.getExchange(), returned.getRoutingKey(), returned.getReplyCode());
        });
    }
}

发送消息时通过 CorrelationData 拿到每条消息的回执：

java 复制代码

CorrelationData cd = new CorrelationData();
cd.getFuture().addCallback(new ListenableFutureCallback<>() {
    @Override
    public void onSuccess(CorrelationData.Confirm result) {
        if (result.isAck()) {
            log.info("消息发送成功，收到 ACK");
        } else {
            log.error("消息发送失败，收到 NACK: {}", result.getReason());
        }
    }
    @Override
    public void onFailure(Throwable ex) {
        log.error("回执异常", ex);
    }
});
rabbitTemplate.convertAndSend("order.direct", "order.create", orderMsg, cd);

可能有人会问：Publisher Confirm 返回了 ACK，消息就一定被消费者处理了吗？

不是。Publisher Confirm 只保证消息到了 Broker 并被持久化到磁盘，不保证消费者成功消费。消费者可能收到消息后处理失败、或者消费者服务本身就挂了。这条链路还有三道防线在后面等着。

还有一个关于连接重试的坑要注意：SpringAMQP 提供了连接失败后的阻塞式重试机制，等待期间当前线程被阻塞。

yaml 复制代码

spring:
  rabbitmq:
    template:
      retry:
        enabled: true
        initial-interval: 1000ms
        multiplier: 1.5
        max-attempts: 3

这个机制在网络不稳定的时候确实能提高成功率。但它是阻塞式的------重试期间线程什么事都做不了，对高并发业务是性能杀手。如果你追求吞吐量，建议关掉它，改用异步线程发消息。

说到底，发送者确认这一层管的是"消息出得去"，下一层我们得管"消息落得下"。

完整链路示意如下：

二、MQ 持久化：消息在 Broker 手里的安全

默认情况下 RabbitMQ 把消息存在内存里，MQ 一宕机，内存里的消息全部消失。持久化就是把消息搬到磁盘上，宕机重启后还能恢复。

这需要三层全部持久化：交换机、队列、消息本身。

交换机持久化 和队列持久化 ：在控制台声明时把 Durable 设为 true，或者在代码里用 QueueBuilder.durable()。

消息持久化 ：消息体本身默认是非持久化的，需要显式设置 DeliveryMode：

java 复制代码

Message message = MessageBuilder
    .withBody("hello".getBytes(StandardCharsets.UTF_8))
    .setDeliveryMode(MessageDeliveryMode.PERSISTENT)
    .build();
rabbitTemplate.convertAndSend("simple.queue", message);

只有这三层全部持久化，消息才不会因为 Broker 重启而丢失。

再往上走一步是 Lazy Queue（惰性队列）：消息在进入队列后直接写入磁盘，不在内存里停留；只有当消费者来拉消息时，才从磁盘读出来加载到内存。

Lazy Queue（惰性队列）：RabbitMQ 3.6.0 引入的队列模式。消息接收后直接落盘，不驻留内存；消费者需要时再从磁盘读取（可提前缓存最多 2048 条到内存以降低延迟）。你可以理解为一栋楼的快递柜------快递到了一律锁进柜子，你来取的时候再拿出来。在 3.12 版本后，所有队列默认就是 Lazy 模式，不需要额外配置。

java 复制代码

@Bean
public Queue lazyQueue() {
    return QueueBuilder.durable("lazy.queue").lazy().build();
}

用 Lazy Queue 的好处是即使消息积压再多，也不会撑爆内存。代价是消费延迟会高一丢丢------但这通常比消息丢了强一百倍。

三、消费者确认：消息真的被处理了吗？

Consumer Acknowledgement（消费者确认）：消费者在成功处理消息后，向 Broker 发送 ACK 回执，Broker 收到后从队列中删除该消息；如果消费者处理失败，发送 NACK 让 Broker 重新投递，或发送 REJECT 直接拒绝并删除消息。就像外卖骑手点了「已送达」才算订单完成------没点之前，消息一直挂在队列里。

SpringAMQP 帮我们封装了这个机制，提供三种确认模式：

模式	行为	安全程度	推荐场景
`NONE`	消息投递给消费者后立刻 ACK，MQ 立即删除	⚠️ 极低	不推荐
`MANUAL`	业务代码中手动调用 API 发 ACK / NACK / REJECT	✅ 高（需自控）	需要精细控制的复杂场景
`AUTO`	Spring AOP 环绕增强，正常返回自动 ACK，业务异常自动 NACK，校验异常自动 REJECT	✅ 高	生产环境首选

NONE 模式是我见过最危险的配置------消费者刚拿到消息还没开始处理，消息就从队列里删了。处理过程中消费者挂了？消息没了。

AUTO 模式是生产环境的甜蜜点：Spring 会根据你的方法是否抛出异常，自动判断该发 ACK 还是 NACK。如果抛的是业务异常（比如 BusinessException），自动 NACK 触发重试；如果是消息格式错误（比如 MessageConversionException），自动 REJECT 直接丢弃------因为重试一万次格式也不会对。

配置很简单：

yaml 复制代码

spring:
  rabbitmq:
    listener:
      simple:
        prefetch: 1             # 每次只推送一条，公平分发
        acknowledge-mode: auto  # 自动确认

这里的 prefetch: 1 也是个关键参数------设为 1 表示消费者每次只取一条消息，处理完再拿下一条。如果不设或设太大，一个慢消费者会积压一堆未 ACK 的消息，影响整体吞吐。

四、失败重试与幂等：最后的兜底

4.1 本地重试 vs 无限 requeue

消费者抛异常 → NACK → 消息重新入队 → 再推给消费者 → 再抛异常......这就是经典的「死循环 requeue」。SpringAMQP 的本地重试机制在消费者内部完成重试，不会让消息反复进出队列------这才是正确的做法。

yaml 复制代码

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true
          initial-interval: 1000ms
          multiplier: 2
          max-attempts: 3
          stateless: true     # 无事务用 true

本地重试 3 次还是失败后，就要看 MessageRecoverer 的策略了：

策略	行为	风险
`RejectAndDontRequeueRecoverer`	直接 Reject，消息丢弃	默认策略，消息会丢
`ImmediateRequeueMessageRecoverer`	返回 NACK，消息重新入队	⚠️ 可能无限循环
`RepublishMessageRecoverer`	投递到死信交换机	✅ 生产环境推荐

默认的 RejectAndDontRequeueRecoverer 是个坑------重试 3 次失败消息就没了。我第一次遇到的时候以为配置没生效，查了半天才发现消息被静默丢弃了。

推荐用 RepublishMessageRecoverer 把失败消息转发到死信队列，后续人工处理或定时任务补偿：

java 复制代码

@Bean
public MessageRecoverer messageRecoverer(RabbitTemplate rabbitTemplate) {
    return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
}

重试和死信兜底的完整流程：

4.2 幂等性：同一件事做一次和做十次，结果必须一样

重试能解决"消息丢了"的问题，但它的副作用是------同一消息可能被消费多次。网络超时了，消费者处理成功了但 ACK 没发出去，Broker 以为失败又投了一次。

业务幂等性：同一个操作执行一次或多次，对业务状态的最终影响完全一致。扣款业务中，同一个订单只能扣一次库存------这是幂等的；查询业务天然幂等------查十次结果一样。

解决重复消费有两个思路：

1）唯一消息 ID 判重。每条消息带一个全局唯一 ID，消费者处理前先查数据库有没有这个 ID 的记录。处理过就跳过。

java 复制代码

@Bean
public MessageConverter messageConverter() {
    Jackson2JsonMessageConverter converter = new Jackson2JsonMessageConverter();
    converter.setCreateMessageIds(true);  // 自动生成全局唯一 MessageId
    return converter;
}

消费者逻辑：

java 复制代码

@RabbitListener(queues = "order.queue")
public void handleOrder(OrderMsg msg, Message message) {
    String msgId = message.getMessageProperties().getMessageId();
    if (msgLogService.exists(msgId)) {
        return;  // 已处理过，跳过
    }
    // 执行业务...
    msgLogService.save(msgId);  // 记录已处理
}

2）业务状态判断。不依赖消息 ID，而是根据业务状态机来判断。比如支付回调更新订单状态时，先查订单是不是"未支付"，是才改成"已支付"。

幂等性是分布式系统的必修课，不是可选项。特别是涉及钱、库存、状态的业务，一定要在消费端加幂等判断。

可能有人会问：本地重试和 NACK 让消息重新入队，到底选哪个？

优先选本地重试。NACK 让消息重新入队意味着消息要重新排队，如果前面有积压，这条消息可能要等很久才能再次处理。而且频繁的 requeue 会加重 Broker 的 IO 压力。本地重试在消费者进程内部完成，速度快、不增加 Broker 负担。只有在本地重试也搞不定、并且不能丢消息的场景下，才用 RepublishMessageRecoverer 转发到死信队列走人工兜底。

五、延迟消息：一致性兜底

即使前面的四道防线都搭好了，还是可能出现极端情况------消费者服务挂了半小时，重试也耗尽了。这时候就需要延迟消息做兜底。

死信交换机（Dead Letter Exchange, DLX）：队列中的消息在三种情况下会变成「死信」------被消费者 Reject 且不重新入队、消息在队列中过期、或队列满了被挤出。这些死信会被自动转发到指定的交换机，等待人工兜底处理。你可以理解为消息的「废品回收站」------不合格的消息不会凭空消失，而是被转到专门的地方等人工处理。

定义一个带死信转向的普通队列：

java 复制代码

@Bean
public Queue normalQueue() {
    return QueueBuilder.durable("normal.queue")
        .deadLetterExchange("dlx.direct")
        .deadLetterRoutingKey("dlx")
        .ttl(30 * 60 * 1000)  // 30 分钟过期
        .build();
}

消息在 normal.queue 里待了 30 分钟还没被消费，自动变成死信投递到 dlx.direct，由专门的死信消费者处理。这个模式特别适合做延迟消息------比如下单后 30 分钟未支付自动取消，就是靠消息 TTL + 死信队列实现的。

当然，RabbitMQ 社区也提供了一个延迟消息插件（rabbitmq-delayed-message-exchange），可以把普通交换机改造成支持延迟投递的交换机，消息头上带 x-delay 指定延迟时间。不过目前基于死信队列的方案更通用，不依赖插件安装，在任何 RabbitMQ 版本上都能跑。

参考链接

RabbitMQ 官方 Confirms 文档（搜：RabbitMQ Publisher Confirms）
RabbitMQ Lazy Queue 说明
Spring AMQP 官方文档

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你在做 RabbitMQ消息可靠性的时候，最常丢消息的环节是哪一道？发送确认、持久化、消费者 ACK 还是幂等？