微服务-MQ高级

星梦清河2026-05-09 8:49

一、发送者的可靠性（生产者确认：Confirm+Return）

尽可能确保MQ消息的可靠性（即消息应该至少被消费者处理1次），存在问题：

  1. 该如何确保MQ消息的可靠性？
  2. 如果真的发送失败，有没有其他的兜底（处理）方案？

消息从发送者发送消息，到消费者处理消息，需要经过的流程如下：

消息从生产者到消费者的每一步都可能导致消息丢失：

  • 发送消息时丢失：
    • 生产者发送消息时连接MQ失败；
    • 生产者发送消息到达MQ后未找到Exchange；
    • 生产者发送消息到达MQ的Exchange后，未找到合适的Queue；
    • 消息到达MQ后，处理消息的进程发生异常；
  • MQ导致消息丢失：
    • 消息到达MQ，保存到队列后，尚未消费就突然宕机；
  • 消费者处理消息时：
    • 消息接收后尚未处理突然宕机；
    • 消息接收后处理过程中抛出异常；

解决消息丢失问题，保证MQ的可靠性（确保消息成功发送到MQ），需要从3个方面入手：

  1. 确保生产者一定把消息发送到MQ；
  2. 确保MQ不会将消息弄丢；
  3. 确保消费者一定要处理消息；

1.1 生产者重试机制（发送阶段）

突发情况： 生产者发送消息时，出现了网络故障，导致与MQ的连接中断；
解决方案： SpringAMQP提供的消息发送时的重试机制（即：当RabbitTemplate与MQ连接超时后，多次重试）；

修改publisher模块的application.yaml文件，添加下面的内容：

yaml 复制代码 
spring:
  rabbitmq:
    connection-timeout: 1s # 设置MQ的连接超时时间
    template:
      retry:
        enabled: true # 开启超时重试机制
        initial-interval: 1000ms # 失败后的初始等待时间
        multiplier: 1 # 失败后下次的等待时长倍数，下次等待时长 = initial-interval * multiplier
        max-attempts: 3 # 最大重试次数

利用命令停掉RabbitMQ服务：

shell 复制代码 
docker stop mq

测试： 发送一条消息，会发现每隔1秒重试1次，总共试了3次，消息发送的超时重试机制配置成功了！
注意： 当网络不稳定时，利用重试机制可以有效提高消息发送的成功率，不过SpringAMQP提供的重试机制是阻塞式的重试（也就是说多次重试等待的过程中，当前线程是被阻塞的）。

若对于业务性能有要求，建议禁用重试机制，如果一定要使用，可合理配置等待时长和重试次数，也可使用异步线程来执行发送消息的代码。

1.2 生产者确认机制（路由阶段）

一般情况下，只要生产者与MQ之间的网络连接顺畅，基本不会出现发送消息丢失的情况，因此大多数情况下无需考虑这种问题。

少数情况下，出现消息发送到MQ之后丢失问题：

  • MQ内部处理消息的进程发生了异常；
  • 生产者发送消息到达MQ后未找到Exchange;
  • 生产者发送消息到达MQ的Exchange后，未找到合适的Queue，因此无法路由；

RabbitMQ提供了生产者消息确认机制 ，包括Publisher Confirm和Publisher Return两种，在开启确认机制的情况下，当生产者发送消息给MQ后，MQ会根据消息处理的情况返回不同的回执；

总结：

  • 当消息投递到MQ，但路由失败时，通过Publisher Return返回异常信息，同时返回ack的确认信息，代表投递成功；
  • 临时消息投递到了MQ，并且入队成功，返回ACK，告知投递成功
  • 持久消息投递到了MQ，并且入队完成持久化，返回ACK ，告知投递成功
  • 其它情况都会返回NACK，告知投递失败

其中ack和nack属于Publisher Confirm机制，ack是投递成功；nack是投递失败。而return则属于Publisher Return机制。
默认两种机制都是关闭状态，需要通过配置文件来开启。

1.3 实现生产者确认

1.3.1 开启生产者确认

在publisher模块的application.yaml中添加配置：

yaml 复制代码 
spring:
  rabbitmq:
    publisher-confirm-type: correlated # 开启publisher confirm机制，并设置confirm类型
    publisher-returns: true # 开启publisher return机制

publisher-confirm-type有三种模式可选：

  • none：关闭confirm机制
  • simple：同步阻塞等待MQ的回执
  • correlated：MQ异步回调返回回执（推荐使用）

1.3.2 定义ReturnCallback

每个RabbitTemplate只能配置一个ReturnCallback，因此我们可以在配置类中统一设置。我们在publisher模块定义一个配置类：

代码如下：

java 复制代码 
package com.itheima.publisher.config;

import lombok.AllArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.ReturnedMessage;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.context.annotation.Configuration;

import javax.annotation.PostConstruct;

@Slf4j
@AllArgsConstructor
@Configuration
public class MqConfig {
    private final RabbitTemplate rabbitTemplate;

    @PostConstruct
    public void init(){
        rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
            @Override
            public void returnedMessage(ReturnedMessage 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());
            }
        });
    }
}

1.3.3 定义ConfirmCallback

由于每个消息发送时的处理逻辑不一定相同，因此ConfirmCallback需要在每次发消息时定义。具体来说，是在调用RabbitTemplate中的convertAndSend方法时，多传递一个参数：


CorrelationData中包含两个核心：

  • id： 消息的唯一标示，MQ对不同的消息的回执以此做判断，避免混淆；
  • SettableListenableFuture： 回执结果的Future对象；

将来MQ的回执会通过Future来返回，可以提前给CorrelationData中的Future添加回调函数来处理消息回执：

新建一个测试，向系统自带的交换机发送消息，并且添加ConfirmCallback：

java 复制代码 
@Test
void testPublisherConfirm() {
    // 1.创建CorrelationData
    CorrelationData cd = new CorrelationData();
    // 2.给Future添加ConfirmCallback
    cd.getFuture().addCallback(new ListenableFutureCallback<CorrelationData.Confirm>() {
        @Override
        public void onFailure(Throwable ex) {
            // 2.1.Future发生异常时的处理逻辑，基本不会触发
            log.error("send message fail", ex);
        }
        @Override
        public void onSuccess(CorrelationData.Confirm result) {
            // 2.2.Future接收到回执的处理逻辑，参数中的result就是回执内容
            if(result.isAck()){ // result.isAck()，boolean类型，true代表ack回执，false 代表 nack回执
                log.debug("发送消息成功，收到 ack!");
            }else{ // result.getReason()，String类型，返回nack时的异常描述
                log.error("发送消息失败，收到 nack, reason : {}", result.getReason());
            }
        }
    });
    // 3.发送消息
    rabbitTemplate.convertAndSend("hmall.direct", "q", "hello", cd);
}

执行结果如下：

可以看到，

  • 由于传递的RoutingKey是错误的，路由失败后，触发了return callback，同时也收到了ack。
  • 当我们修改为正确的RoutingKey以后，就不会触发return callback了，只收到ack。
  • 如果连交换机都是错误的，则只会收到nack。

注意：
开启生产者确认比较消耗MQ性能，一般不建议开启。而且大家思考一下触发确认的几种情况：

  • 路由失败：一般是因为RoutingKey错误导致，往往是编程导致
  • 交换机名称错误：同样是编程错误导致
  • MQ内部故障：这种需要处理，但概率往往较低。因此只有对消息可靠性要求非常高的业务才需要开启，而且仅仅需要开启ConfirmCallback处理nack就可以了。

二、MQ的可靠性（LazyQueue：惰性队列）

消息到达MQ以后，如果MQ不能及时保存，也会导致消息丢失，所以MQ的可靠性也很重要，需要确保消息在MQ中不丢失。

2.1 数据持久化

为了提高性能，默认情况下MQ的数据都是在内存存储的临时数据，重启后就会消失。

为了保证数据的可靠性，必须配置数据持久化，包括：

  • 交换机持久化
  • 队列持久化
  • 消息持久化

2.1.1 交换机持久化

在控制台的Exchange页面，添加交换机时，可配置交换机的Durability参数：

设置为Durable就是持久化模式，Transient就是临时模式。

2.1.2 队列持久化

在控制台的Queues页面，添加队列时，同样可以配置队列的Durability参数：

2.1.3 消息持久化

在控制台发送消息时，可添加很多参数，而消息的持久化是要配置一个properties：

说明： 在开启持久化机制之后，如果同时还开启了生产者确认，那么MQ会在消息持久化以后才发送ACK回执，进一步确保消息的可靠性；

不过出于性能考虑，为了减少IO次数，发送到MQ的消息并不是逐条持久化到数据库的，而是每隔一段时间批量持久化，一般间隔在100毫秒左右，就会导致ACK有一定的延迟，因此建议生产者确认全部采用异步方式。

2.2 LazyQueue

在默认情况 下，RabbitMQ会将接收到的信息保存在内存中以降低消息收发的延迟，但在特殊情况下，会导致消息积压：

  • 消费者宕机或出现网络故障；
  • 消息发送量激增，超过了消费者处理速度；
  • 消费者处理u业务发生阻塞；

一旦出现消息堆积问题，RabbitMQ的内存占用就会越来越高，直到触发内存预警上限，此时RabbitMQ会将内存消息刷到磁盘上，这个行为成为Pageout，Pageout会耗费一段时间，并会阻塞队列进程，因此该过程中RaabbitMQ不会再处理新的消息，生产者的所有请求都会被阻塞；

为了解决这个问题，从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的模式，也就是惰性队列。

惰性队列的特征如下：

  • 接收到消息后直接存入磁盘而非内存
  • 消费者要消费消息时才会从磁盘中读取并加载到内存（也就是懒加载）
  • 支持数百万条的消息存储

而在3.12版本之后，LazyQueue已经成为所有队列的默认格式。因此官方推荐升级MQ为3.12版本或者所有队列都设置为LazyQueue模式。

2.2.1 控制台配置Lazy模式

在添加队列时，添加x-queue-mod-lazy参数即可设置队列为Lazy模式：

2.2.2 代码配置Lazy模式

在利用SpringAMQP声明队列时，添加x-queue-mod-lazy参数也可设置队列为Lazy模式：

java 复制代码 
@Bean
public Queue lazyQueue(){
    return QueueBuilder
            .durable("lazy.queue")
            .lazy() // 开启Lazy模式
            .build();
}

通过QueueBuilder的lazy()函数配置Lazy模式，底层源码如下：

也可以基于注解来声明队列并设置为Lazy模式：

java 复制代码 
@RabbitListener(queuesToDeclare = @Queue(
        name = "lazy.queue",
        durable = "true",
        arguments = @Argument(name = "x-queue-mode", value = "lazy")
))
public void listenLazyQueue(String msg){
    log.info("接收到 lazy.queue的消息：{}", msg);
}

2.2.3 更新已有队列为Lazy模式

对于已存在的队列，也可以配置为lazy模式，但要通过设置policy实现。

可以基于命令行设置policy：

shell 复制代码 
rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy"}' --apply-to queues

命令解读：

  • rabbitmqctl ：RabbitMQ的命令行工具
  • set_policy ：添加一个策略
  • Lazy ：策略名称，可以自定义
  • "^lazy-queue$" ：用正则表达式匹配队列的名字
  • '{"queue-mode":"lazy"}' ：设置队列模式为lazy模式
  • --apply-to queues：策略的作用对象，是所有的队列

可以在控制台配置policy，进入在控制台的Admin页面，点击Policies，即可添加配置：

三、消费者的可靠性

当RabbitMQ向消费者投递消息以后，需要知道消费者的处理状态如何，因为消息投递给消费者并不代表就一定被正确消费了，可能出现的故障有很多：

  • 消息投递过程中出现网络故障；
  • 消费者接收到消息后突然宕机；
  • 消费者接收到消息后，因处理不当导致异常；

若出现上面的故障情况，消息也会丢失，RabbitMQ必须知道消费者的处理状态，一旦消息处理失败才能重新投递消息。
核心问题： RabbitMQ如何得知消费者的处理状态呢？

3.1 消费者确认机制

为了确认消费者是否成功处理消息，RabbitMQ提供了消费者确认机制（Consumer Acknowledgement），即：当消费者处理消息结束后，应该向RabbitMQ发送一个回执，告知RabbitMQ自己消息处理状态，回执有三种可选值：

  • ack：成功处理消息，RabbitMQ从队列中删除该消息；
  • nack：消息处理失败，RabbitMQ需要再次投递消息；
  • reject：消息处理失败并拒绝该消息，RabbitMQ从队列中删除该消息；

一般reject方式用的较少，除非是消息格式有问题，那就是开发问题，大多数情况下需要将消息处理的代码通过try-catch机制捕获，消息处理成功时返回ack，处理失败时返回nack。

由于消息回执的处理代码比较统一，因此SpringAMQP可以实现消息确认，并允许通过配置文件设置ACK处理方式，有三种模式：

  • none：不处理。即消息投递给消费者后立刻ack，消息会立刻从MQ删除，非常不安全，不建议使用；
  • manual：手动模式。需要自己在业务代码中调用api，发送ack或reject，存在业务入侵，但更灵活；
  • auto：自动模式。SpringAMQP利用AOP对消息处理逻辑做了环绕增强，当业务正常执行时则自动返回ack，当业务出现异常时，根据异常判断返回不同结果：
    • 如果是业务异常 ，会自动返回nack；
    • 如果是消息处理或校验异常 ，自动返回reject；

返回Reject的常见异常有：

text 复制代码 
Starting with version 1.3.2, the default ErrorHandler is now a ConditionalRejectingErrorHandler that rejects (and does not requeue) messages that fail with an irrecoverable error. Specifically, it rejects messages that fail with the following errors:
- o.s.amqp...MessageConversionException: Can be thrown when converting the incoming message payload using a MessageConverter.
- o.s.messaging...MessageConversionException: Can be thrown by the conversion service if additional conversion is required when mapping to a @RabbitListener method.
- o.s.messaging...MethodArgumentNotValidException: Can be thrown if validation (for example, @Valid) is used in the listener and the validation fails.
- o.s.messaging...MethodArgumentTypeMismatchException: Can be thrown if the inbound message was converted to a type that is not correct for the target method. For example, the parameter is declared as Message<Foo> but Message<Bar> is received.
- java.lang.NoSuchMethodException: Added in version 1.6.3.
- java.lang.ClassCastException: Added in version 1.6.3.

通过配置可以修改SpringAMQP的ACK处理方式：

yaml 复制代码 
spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: none # 不做处理

修改consumer服务的SpringRabbitListener类中的方法，模拟一个消息处理的异常：

java 复制代码 
@RabbitListener(queues = "simple.queue")
public void listenSimpleQueueMessage(String msg) throws InterruptedException {
    log.info("spring 消费者接收到消息：【" + msg + "】");
    if (true) {
        throw new MessageConversionException("故意的");
    }
    log.info("消息处理完成");
}

测试可以发现：当消息处理发生异常时，消息依然被RabbitMQ删除了。

再次把确认机制修改为auto：

yaml 复制代码 
spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: auto # 自动ack

在异常位置打断点，再次发送消息，程序卡在断点时，可以发现此时消息状态为unacked（未确定状态）：

放行以后，由于抛出的时消息转换异常 ，因此Spring会自动返回reject，所以消息依然会被删除：

将异常改为RuntimeException类型：

java 复制代码 
@RabbitListener(queues = "simple.queue")
public void listenSimpleQueueMessage(String msg) throws InterruptedException {
    log.info("spring 消费者接收到消息：【" + msg + "】");
    if (true) {
        throw new RuntimeException("故意的");
    }
    log.info("消息处理完成");
}

在异常位置打断点，然后再次发送消息测试，程序卡在断点时，可以发现此时消息状态为unacked（未确定状态）：

放行以后，由于抛出的是业务异常，所以Spring返回ack，最终消息恢复至Ready状态，并且没有被RabbitMQ删除：

当把配置改为auto时，消息处理失败后，会回到RabbitMQ，并重新投递到消费者。

3.2 失败重试机制

当消费者出现异常后，消息会不断requeue(重入队)到队列，再重新发送给消费者，如果消费者再次执行依然出错，消息会再次requeue到队列，再次投递，直到消息处理成功为止。
极端情况 ：消费者一直无法执行成功，那么消息requeue就会无限循环，导致mq的消息处理飙升，带来不必要的压力：

以上极端情况的发生概率很小，为了应对上述情况Spring又提供了消费者失败重试机制：在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列中。

修改consumer服务的application.yaml文件，添加内容：

yaml 复制代码 
spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true # 开启消费者失败重试
          initial-interval: 1000ms # 初识的失败等待时长为1秒
          multiplier: 1 # 失败的等待时长倍数，下次等待时长 = multiplier * last-interval
          max-attempts: 3 # 最大重试次数
          stateless: true # true无状态；false有状态。如果业务中包含事务，这里改为false

重启consumer服务，重复之前的测试，发现：

  • 消费者在失败后消息没有重新回到MQ无限重新投递，而是本地重试了3次；
  • 本地重试3次后，抛出了AmqpRejectAndDontRequeueException异常，查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是reject；

结论：

  • 开启本地重试时，消息处理过程中抛出异常，不会requeue到队列，而是在消费者本地重试；
  • 重试达到最大次数后，Spring会返回reject，消息会被丢弃；

3.3 失败处理策略

在之前的测试中，本地测试达到最大重试次数后，消息会被丢弃，对于消息可靠性要求较高的业务场景下，不可行。

因此Spring允许自定义重试次数耗尽后的消息处理策略，这个策略是由MessageRecovery接口来定义的，有3个不同实现：

  • RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式
  • ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队
  • RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机

比较优雅的一种处理方案是RepublishMessageRecoverer，失败后将消息投递到一个指定的，专门存放异常消息的队列，后续由人工集中处理。

  1. 在consumer服务中定义处理失败消息的交换机和队列
java 复制代码 
@Bean
public DirectExchange errorMessageExchange(){
    return new DirectExchange("error.direct");
}
@Bean
public Queue errorQueue(){
    return new Queue("error.queue", true);
}
@Bean
public Binding errorBinding(Queue errorQueue, DirectExchange errorMessageExchange){
    return BindingBuilder.bind(errorQueue).to(errorMessageExchange).with("error");
}
  1. 定义一个RepublishMessageRecoverer，关联队列和交换机
java 复制代码 
@Bean
public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
    return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
}

完整代码：

java 复制代码 
package com.itheima.consumer.config;

import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.DirectExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.rabbit.retry.MessageRecoverer;
import org.springframework.amqp.rabbit.retry.RepublishMessageRecoverer;
import org.springframework.context.annotation.Bean;

@Configuration
@ConditionalOnProperty(name = "spring.rabbitmq.listener.simple.retry.enabled", havingValue = "true")
public class ErrorMessageConfig {
    @Bean
    public DirectExchange errorMessageExchange(){
        return new DirectExchange("error.direct");
    }
    @Bean
    public Queue errorQueue(){
        return new Queue("error.queue", true);
    }
    @Bean
    public Binding errorBinding(Queue errorQueue, DirectExchange errorMessageExchange){
        return BindingBuilder.bind(errorQueue).to(errorMessageExchange).with("error");
    }

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

3.4 业务幂等性

幂等 是一个数学概念，用函数表达式描述：f(x)=f(f(x))，例如求绝对值函数。
程序开发中，幂等则是指同一个业务，执行一次或多次对业务状态的影响是一致的。

保证消息处理的幂等性，可采用的方案：

  • 唯一消息ID
  • 业务状态判断

3.4.1 唯一消息ID

核心思路：

  1. 每条消息都生成一个唯一id，与消息一起投递给消费者；
  2. 消费者接收到消息后处理自己的业务，业务处理成功后将消息id保存到数据库；
  3. 如果下次又收到相同消息，去数据库查询判断是否存在，存在则为重复消息放弃处理；

如何给消息添加唯一ID？

SpringAMQP的MessageConverter自带了MessageID的功能，只需要开启该功能即可。

以Jackson的消息转换器为例：

java 复制代码 
@Bean
public MessageConverter messageConverter(){
    // 1.定义消息转换器
    Jackson2JsonMessageConverter jjmc = new Jackson2JsonMessageConverter();
    // 2.配置自动创建消息id，用于识别不同消息，也可以在业务中基于ID判断是否是重复消息
    jjmc.setCreateMessageIds(true);
    return jjmc;
}

3.4.2 业务判断

业务判断 就是基于业务本身的逻辑或状态来判断是否是重复的请求或消息，不同的业务场景判断的思路也不一样。
案例 ：处理消息的业务逻辑是把订单状态从未支付修改为已支付，此时可在执行业务时判断订单状态是否为未支付，如果不是，则证明订单已经被处理锅，无需重复处理。

以支付修改订单的业务为例，我们需要修改OrderServiceImpl中的markOrderPaySuccess方法：

java 复制代码 
    @Override
    public void markOrderPaySuccess(Long orderId) {
        // 1.查询订单
        Order old = getById(orderId);
        // 2.判断订单状态
        if (old == null || old.getStatus() != 1) {
            // 订单不存在或者订单状态不是1，放弃处理
            return;
        }
        // 3.尝试更新订单
        Order order = new Order();
        order.setId(orderId);
        order.setStatus(2);
        order.setPayTime(LocalDateTime.now());
        updateById(order);
    }

上述代码逻辑上符合了幂等判断的需求，但是由于判断和更新是两步动作，因此在极小概率下可能存在线程安全问题,可以合并上述操作为这样：

java 复制代码 
@Override
public void markOrderPaySuccess(Long orderId) {
    // UPDATE `order` SET status = ? , pay_time = ? WHERE id = ? AND status = 1
    lambdaUpdate()
            .set(Order::getStatus, 2)
            .set(Order::getPayTime, LocalDateTime.now())
            .eq(Order::getId, orderId)
            .eq(Order::getStatus, 1)
            .update();
}

注意:上述代码等同于这样的SQL语句：

sql 复制代码 
UPDATE `order` SET status = ? , pay_time = ? WHERE id = ? AND status = 1

在where条件中除了判断id以外，还加上status必须为1的条件，如果条件不符合（说明订单已支付），则sql匹配不到数据，根本不会执行。

3.5 兜底方案

核心思想： 既然MQ通知不一定发送到交易服务，那么交易服务就必须自己主动去查询支付状态，这样即便支付服务的MQ通知失败，依然能通过主动查询来保证订单状态的一致。

流程如下：

图中黄色线圈起来的部分就是MQ通知失败后的兜底处理方案，又交易服务自己主动去查询支付状态；
问题： 交易服务并不知道用户会什么时候支付，如果查询时机不正确，查询到的支付状态也不正确。
解决方案： 通常利用定时任务定期查询，例如每隔一段时间就查询一次，并判断支付状态，如果订单已经支付，则立刻更新订单状态为已支付即可。
总结：（支付服务与交易服务之间的订单状态一致性保证问题？）

  • 首先，支付服务会正在用户支付成功以后利用MQ消息通知交易服务，完成订单状态同步；
  • 其次，为了保证MQ消息的可靠性，采用了生产者确认机制、消费者确认、消费者失败重试等策略，确保消息投递的可靠性；
  • 最后，我们在交易服务设置了定时任务，定期查询订单支付状态，即便MQ通知失败，还可利用定时任务最为兜底方案，确保订单支付状态的最终一致性。

四、延迟消息

4.1 死信交换机和延迟消息

4.1.1 死信交换机

什么是死信？

当一个队列中的消息满足下列情况之一，可以成为死信（dead letter）：

  • 消费者使用basic.reject或basic.nack声明消费失败，并且消息的requeue参数设置为false;
  • 消息是一个过期消息，超时无人消费；
  • 要投递的队列消息满了，无法投递；

如果队列中的消息已经成为死信，并且这个队列通过dead-letter-exchange属性指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机就称为死信交换机（Dead Letter Exchange）。而此时加入有队列与死信交换机绑定，则最终死信就会被投递到这个队列中。

死信交换机的作用：

  1. 收集那些因处理失败而被拒绝的消息；
  2. 收集那些因队列满了而被拒绝的消息；
  3. 收集因TTL（有效期）到期的消息；

4.1.2 延迟消息

死信交换机前两种作用场景可看做是把死信交换机当作一种消息处理的最终兜底方案，与消费者重试时讲的RepublishMessageRecoverer作用类似。

最后一种如示例可见：

有一组绑定的交换机（ttl.fanout）和队列（ttl.queue）。但是ttl.queue没有消费者监听，而是设定了死信交换机hmall.direct，而队列direct.queue1则与死信交换机绑定，RoutingKey是blue：

假如我们现在发送一条消息到ttl.fanout，RoutingKey为blue，并设置消息的有效期为5000毫秒：

注意： 尽管这里的ttl.fanout不需要RoutingKey，但是当消息变为死信并投递到死信交换机时，会沿用之前的RoutingKey，这样hmall.direct才能正确路由消息。

消息肯定会被投递到ttl.queue之后，由于没有消费者，因此消息无人消费。5秒之后，消息的有效期到期，成为死信：

死信被再次投递到死信交换机hmall.direct，并沿用之前的RoutingKey，也就是blue：

由于direct.queue1与hmall.direct绑定的key是blue，因此最终消息被成功路由到direct.queue1，如果此时有消费者与direct.queue1绑定， 也就能成功消费消息了。但此时已经是5秒钟以后了：

也就是说，publisher发送了一条消息，但最终consumer在5秒后才收到消息。我们成功实现了延迟消息。

4.1.3 总结

RabbitMQ的消息过期是基于追溯方式来实现的，也就是说当一个消息的TTL到期以后不一定会被移除或投递到死信交换机，而是在消息恰好处于队首时才会被处理。

当队列中消息堆积很多时，过期消息可能不会被按时处理，因此设置的TTL时间不一定准确。

4.2 DelayExchange插件

基于死信队列虽然可以实现延迟消息，但太麻烦，bbitMQ社区提供了一个延迟消息插件来实现相同的效果。

官方文档：https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq

4.2.1 下载

插件下载地址：https://github.com/rabbitmq/rabbitmq-delayed-message-exchange

由于安装的MQ是3.8版本，这里下载3.8.17版本：

也可直接使用准备好的资料

4.2.2 安装

我直接使用准备好的资料，基于Docker安装：

  1. 需要线查看RabbitMQ从插件目录对应的数据卷：
shell 复制代码 
docker volume inspect mq-plugins

返回结果：

json 复制代码 
[
    {
        "CreatedAt": "2026-05-06T14:55:31+08:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/mq-plugins/_data",
        "Name": "mq-plugins",
        "Options": null,
        "Scope": "local"
    }
]

插件目录被挂载到了/var/lib/docker/volumes/mq-plugins/_data这个目录，我们上传插件到该目录下。

  1. 先把插件文件放到 volume 中（需要 sudo 权限）
shell 复制代码 
# 先确认你当前目录有插件文件
ls -la ~/ | grep rabbitmq_delayed

# 如果没有，先下载
cd ~
wget https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases/download/v3.8.0/rabbitmq_delayed_message_exchange-3.8.0.ez

# 复制到 volume（需要 sudo）
sudo cp rabbitmq_delayed_message_exchange-3.8.0.ez /var/lib/docker/volumes/mq-plugins/_data/

# 验证文件已复制
sudo ls -la /var/lib/docker/volumes/mq-plugins/_data/
  1. 从容器内启用插件
shell 复制代码 
# 进入容器
docker exec -it mq bash

# 查看 /plugins 目录下是否有插件
ls -la /plugins/

# 复制插件到 RabbitMQ 的插件目录
cp /plugins/rabbitmq_delayed_message_exchange-3.8.0.ez /opt/rabbitmq/plugins/

# 启用插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

# 退出容器
exit
  1. 重启 RabbitMQ
shell 复制代码 
docker restart mq
  1. 验证
shell 复制代码 
# 检查插件是否启用
docker exec mq rabbitmq-plugins list | grep delayed

# 应该看到类似输出：
# [E*] rabbitmq_delayed_message_exchange 3.8.0

4.2.3 声明延迟交换机

基于注解方式：

java 复制代码 
@RabbitListener(bindings = @QueueBinding(
        value = @Queue(name = "delay.queue", durable = "true"),
        exchange = @Exchange(name = "delay.direct", delayed = "true"),
        key = "delay"
))
public void listenDelayMessage(String msg){
    log.info("接收到delay.queue的延迟消息：{}", msg);
}

基于@Bean的方式：

java 复制代码 
package com.itheima.consumer.config;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Slf4j
@Configuration
public class DelayExchangeConfig {

    @Bean
    public DirectExchange delayExchange(){
        return ExchangeBuilder
                .directExchange("delay.direct") // 指定交换机类型和名称
                .delayed() // 设置delay的属性为true
                .durable(true) // 持久化
                .build();
    }

    @Bean
    public Queue delayedQueue(){
        return new Queue("delay.queue");
    }
    
    @Bean
    public Binding delayQueueBinding(){
        return BindingBuilder.bind(delayedQueue()).to(delayExchange()).with("delay");
    }
}

4.2.4 发送延迟消息

发送消息时，必须通过x-delay属性设定延迟时间

java 复制代码 
@Test
void testPublisherDelayMessage() {
    // 1.创建消息
    String message = "hello, delayed message";
    // 2.发送消息，利用消息后置处理器添加消息头
    rabbitTemplate.convertAndSend("delay.direct", "delay", message, new MessagePostProcessor() {
        @Override
        public Message postProcessMessage(Message message) throws AmqpException {
            // 添加延迟消息属性
            message.getMessageProperties().setDelay(5000);
            return message;
        }
    });
}

注意：

延迟消息插件内部会维护一个本地数据库表，同时使用Elang Timers功能实现计时。如果消息的延迟时间设置较长，可能会导致堆积的延迟消息非常多，会带来较大的CPU开销，同时延迟消息的时间会存在误差。

因此，不建议设置延迟时间过长的延迟消息。

五、相关高频面试题

序号 分类 面试问题 参考答案
1 发送者可靠性 如何确保生产者一定把消息发送到MQ？ 从三个方面确保： 1. 生产者重试机制： • 当与MQ连接超时时，SpringAMQP提供阻塞式重试 • 配置：spring.rabbitmq.template.retry.enabled=true • 可设置初始等待时间、倍数、最大重试次数 2. 生产者确认机制（Publisher Confirm）： • 开启后MQ会返回ACK/NACK回执 • 配置：spring.rabbitmq.publisher-confirm-type=correlated • ACK：投递成功；NACK：投递失败 3. 生产者返回机制（Publisher Return）： • 路由失败时触发Return回调 • 配置：spring.rabbitmq.publisher-returns=true • 常见原因：Exchange不存在、RoutingKey错误
2 发送者可靠性 生产者确认机制有哪几种模式？如何选择？ 三种模式： • none：关闭确认机制（默认） • simple：同步阻塞等待MQ回执，影响性能 • correlated：异步回调返回回执，推荐使用 建议： • 对可靠性要求不高的业务可不开启 • 开启确认机制消耗MQ性能，建议只开启ConfirmCallback处理NACK即可
3 发送者可靠性 发送消息失败后的兜底方案有哪些？ 1. 重试机制： • 网络故障时自动重试，最多3次 2. 记录失败日志： • 在ConfirmCallback的NACK或ReturnCallback中记录失败消息 • 后续通过定时任务或人工介入处理 3. 本地消息表： • 发送前先保存消息到本地数据库，状态为"发送中" • 收到ACK后更新状态为"已发送" • 定时任务扫描超时未确认的消息进行重发 4. 死信队列兜底： • 将失败消息投递到专门队列，由人工或补偿任务处理
4 MQ可靠性 如何确保MQ不会把消息弄丢？ 1. 数据持久化： • 交换机持久化：Durable=true • 队列持久化：Durable=true • 消息持久化：设置delivery-mode=2 2. 使用LazyQueue（惰性队列）： • 消息直接存入磁盘而非内存 • 消费时才从磁盘加载到内存 • 支持数百万条消息存储 • 3.12版本后成为默认格式 3. 生产者确认与持久化配合： • 开启持久化后，MQ会在消息持久化完成后才发送ACK • 确保消息真正保存后才确认
5 MQ可靠性 什么是LazyQueue？有什么优势？ LazyQueue（惰性队列）特征： • 接收到消息后直接存入磁盘 而非内存 • 消费者消费时才从磁盘读取并加载到内存 • 支持数百万条消息存储 优势： • 避免内存溢出风险 • 避免Pageout阻塞队列进程 • 适合消息积压场景 配置方式： • 控制台：添加队列时设置x-queue-mode=lazy • 代码：QueueBuilder.durable().lazy().build() • 注解：@Argument(name="x-queue-mode", value="lazy")
6 消费者可靠性 消费者确认机制有哪些模式？ 三种模式： 1. none（不处理）： • 消息投递给消费者后立刻ACK • 消息立即从MQ删除，不安全，不推荐 2. manual（手动）： • 需要在业务代码中手动调用API发送ACK/NACK/REJECT • 灵活但有业务入侵 3. auto（自动-推荐）： • SpringAOP环绕增强自动返回 • 业务正常→返回ACK • 业务异常→返回NACK • 消息转换/校验异常→返回REJECT
7 消费者可靠性 什么是消费者失败重试机制？如何配置？ 背景： 消费者异常时消息会不断requeue，可能导致无限循环 解决方案： 开启本地重试，异常时在消费者本地重试，而不是无限requeue到MQ 配置示例： yaml<br>spring:<br> rabbitmq:<br> listener:<br> simple:<br> retry:<br> enabled: true<br> initial-interval: 1000ms<br> multiplier: 1<br> max-attempts: 3<br> 效果： • 重试期间消息不会返回MQ • 重试耗尽后默认返回REJECT，消息被丢弃
8 消费者可靠性 重试耗尽后的消息处理策略有哪些？ MessageRecovery接口的三种实现： • RejectAndDontRequeueRecoverer： 直接REJECT，丢弃消息（默认） • ImmediateRequeueMessageRecoverer： 返回NACK，消息重新入队 • RepublishMessageRecoverer（推荐）： 将失败消息投递到指定交换机，由人工集中处理 RepublishMessageRecoverer配置步骤： 1. 定义专门存放异常消息的Exchange和Queue 2. 创建RepublishMessageRecoverer并关联RabbitTemplate 3. 失败消息自动投递到异常队列，后续人工处理
9 消费者可靠性 如何保证消息处理的幂等性？ 1. 唯一消息ID方案： • 每条消息生成唯一ID与消息一起投递 • 消费者处理成功后保存消息ID到数据库 • 重复消息通过ID判断后放弃处理 • 开启方式：Jackson2JsonMessageConverter设置setCreateMessageIds(true) 2. 业务状态判断方案（推荐）： • 基于业务逻辑自身状态判断 • 例如：修改订单状态时，SQL加上状态条件 • UPDATE order SET status=2 WHERE id=? AND status=1 • 只有符合条件才更新，天然幂等
10 兜底方案 如果MQ通知彻底失败，有什么兜底方案？ 核心思想： 接收方主动查询，不依赖MQ通知 实现方式： • 交易服务设置定时任务 ，定期查询订单支付状态 • 若发现订单已支付但状态未更新，主动完成状态同步 完整可靠性保障链路： 1. 支付服务发送MQ消息通知交易服务 2. 生产者确认机制确保消息投递可靠 3. 消费者确认+重试机制确保消费可靠 4. 定时任务作为最终兜底，保证最终一致性 适用场景： 支付服务与交易服务之间的订单状态同步
11 延迟消息 如何实现延迟消息？有哪些方式？ 方式一：死信队列 + TTL（过期时间） • 给消息设置TTL，投递到没有消费者的队列 • 消息过期后成为死信，投递到死信交换机 • 死信交换机路由到目标队列，消费者延迟收到 • 缺点： 必须消息处于队首才处理，时间不准确 方式二：DelayExchange插件（推荐） • 安装rabbitmq-delayed-message-exchange插件 • 声明交换机时设置delayed=true • 发送消息时设置x-delay属性指定延迟毫秒数 • 精确延迟，实现简单 注意： • 延迟时间过长会导致堆积，增加CPU开销 • 不建议设置过长的延迟消息
12 延迟消息 DelayExchange插件如何使用？ 1. 安装插件： 下载插件： <br>wget https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases/download/v3.8.0/rabbitmq_delayed_message_exchange-3.8.0.ez<br> 复制到插件目录： shell<br>sudo cp rabbitmq_delayed_message_exchange-3.8.0.ez /var/lib/docker/volumes/mq-plugins/_data/<br> 进入容器并启用插件： shell<br>docker exec -it mq bash<br> shell<br>cp /plugins/rabbitmq_delayed_message_exchange-3.8.0.ez /opt/rabbitmq/plugins/<br> shell<br>rabbitmq-plugins enable rabbitmq_delayed_message_exchange<br> shell<br>exit<br> 重启MQ： shell<br>docker restart mq<br> 验证安装： ```shell docker exec mq rabbitmq-plugins list
相关推荐
你不是我我10 小时前
【Java 开发日记】HTTP3 性能更好，为什么内网微服务依然多用 HTTP2？HTTP2 内网优势是什么？
java·开发语言·微服务
Filwaod11 小时前
互联网大厂Java面试实战：Spring Boot微服务架构与AI技术栈深度解析
spring boot·微服务·大厂面试·java面试·技术干货·ai技术栈·程序员求职
旷世奇才李先生11 小时前
Vue3\+TypeScript 2026实战——企业级前端项目架构搭建与性能优化全指南
前端·架构·typescript
扑兔AI13 小时前
B2B销售线索挖掘效率提升的技术实践：基于工商公开数据的客源筛选与竞品分析架构
大数据·人工智能·架构
用户74883127888516 小时前
从LangChain 到LangGraph 全解析
架构
heimeiyingwang18 小时前
【架构实战】设计一个日志分析平台（ELK架构）
elk·架构·linq
企业架构师老王18 小时前
货物入库分类混乱与库位规划难题：基于实在Agent的非侵入式仓储架构演进指南
人工智能·ai·架构
生成论实验室19 小时前
《源·觉·知·行·事·物：生成论视域下的统一认知语法》第十七章 科学与人心的重聚
人工智能·算法·架构·知识图谱·创业创新
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法04零基础教你claude code 接入 deepseek V405Dirtyfrag漏洞：我花了一下午搞清楚这个Linux内核提权漏洞到底在搞什么06【AI】2026 年具身智能模型和世界模型总结07CC-Switch & Claude 基于 Linux 服务器安装使用指南08Linux 核弹级高危漏洞 CVE-2026-31431 完整修复指南09裂开！ChatGPT 居然开始要手机号验证，附详细解决方法102026 年 AI 辅助编程工具全景对比：Copilot、Cursor、Claude Code 与 Codex 深度解析