JAVA修仙高级功法-＞千里传音MQ（高阶篇）

二刷MQ

MQ存在的问题

消息可靠性（消息丢失问题）

可靠性保证-生产者确认机制

原理：给每个消息指定一个唯一ID，消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。

返回结果：

publisher-confirm，发送者确认

消息成功投递到交换机，返回ack
消息未投递到交换机，返回nack

publisher-return，发送者回执

消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。

生产者确认机制实现

1：添加配置


spring:
  rabbitmq:
    // publisher-confirm-type: correlated  //异步回调，定义ConfirmCallback，MQ返回结果时会回调这个ConfirmCallback
    publisher-returns: true //开启publish-return功能
    template:
      mandatory: true //定义消息路由失败时的策略。true，则调用ReturnCallback；false：则直接丢弃消息

2：定义ReturnConfirm 回调


@Configuration
@Slf4j
public class CommonConfig implements ApplicationContextAware {
 
    /**
     * 当前方法  会在项目启动时调用
     * @param applicationContext  IOC容器对象
     * @throws BeansException
     */
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        // 在容器中找到RabbitTemplate对象  设置     确认回调     return回调
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
 
        // 设置生产者确认回调函数
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            /**
             * @param correlationData  发消息时自定义的数据
             * @param ack  是否发送成功  true: 消息已经发送到交换机    false: 消息发送失败
             * @param cause  失败原因
             */
            @Override
            public void confirm(CorrelationData correlationData, boolean ack, String cause) {
                String id = correlationData.getId();
                if(ack){
                    log.info(" 消息确认回调触发   消息已经成功发送到 mq的exchange中    消息id:{}",id);
                }else {
                    log.error(" 消息确认回调触发   消息发送失败    消息id:{}, 失败原因:{}",id,cause);
 
                    // 将消息  重新发送
                }
            }
        });
 
        rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
            /**
             * @param message  返还的消息内容
             * @param replyCode    回复状态码
             * @param replyText    回复内容
             * @param exchange     交换机
             * @param routingKey   路由
             */
            @Override
            public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
                // 投递失败，记录日志
                log.info("消息发送失败，应答码{}，原因{}，交换机{}，路由键{},消息{}",
                        replyCode, replyText, exchange, routingKey, message.toString());
 
                // 重试发送消息
            }
        });
 
    }
 
    // direct  fanout   topic
    // simple.direct    simple     simple.queue
 
    @Bean
    DirectExchange simpleDirect(){
        return new DirectExchange("simple.direct");
    }
 
    @Bean
    Binding bindingSimpleQueue(){
        return BindingBuilder.bind(simpleQueue()).to(simpleDirect()).with("simple");
    }
 
    @Bean
    public Queue simpleQueue(){
                                // 声明队列
        return QueueBuilder.durable("simple.queue") // 指定队列名称，并持久化
                .deadLetterExchange("dl.direct") // 指定死信交换机
                .deadLetterRoutingKey("simple")
                .build();
    }
    // 声明死信交换机 dl.direct
    @Bean
    public DirectExchange dlExchange(){
        return new DirectExchange("dl.direct", true, false);
    }
    // 声明存储死信的队列 dl.queue
    @Bean
    public Queue dlQueue(){
        return new Queue("dl.queue", true);
    }
    // 将死信队列 与 死信交换机绑定
    @Bean
    public Binding dlBinding(){
        return BindingBuilder.bind(dlQueue()).to(dlExchange()).with("simple");
    }
 
    @Bean
    public Queue lazyQueue(){
        // 声明惰性队列
        return QueueBuilder.durable("lazy.queue").lazy().build();
    }
 
    @Bean
    public Queue normalQueue(){
        // 声明惰性队列
        return QueueBuilder.durable("normal.queue").build();
    }
}

可靠性保证-消息，交换机，队列持久化

消息持久化(默认就是持久化的）

默认情况下，SpringAMQP发出的任何消息都是持久化的，不用特意指定。


步骤
	1：定义消息
	2：消息持久化


	@Test
    public void testSendMessage2SimpleQueue() throws InterruptedException {
        String routingKey = "simple";
        String message = "hello, spring amqp!";
        // 自定义数据
        CorrelationData data = new CorrelationData(UUID.randomUUID().toString());
        // 发送消息
        rabbitTemplate.convertAndSend("simple.direct", routingKey, message, new MessagePostProcessor() {
            // 后置处理消息
            @Override
            public Message postProcessMessage(Message message) throws AmqpException {
                // 设置消息的持久化方式
                message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT);
                return message;
            }
        },data);
    }

队列持久化（默认就是持久化的)


@Bean
    public Queue simpleQueue(){
        return new Queue("simple.queue",true);
    }

交换机持久化（默认非持久化，需手动设置）


@Bean
public DirectExchange simpleExchange(){
    // 三个参数：交换机名称、是否持久化、当没有queue与其绑定时是否自动删除
    return new DirectExchange("simple.direct", true, false);
}

持久化的标志

可靠性保证-消费者消息确认

RabbitMQ通过消费者回执来确认消费者是否成功处理消息的：

消费者获取消息后，应该向RabbitMQ发送ACK回执，表明自己已经处理消息。

消费者确认模式：（推荐auto）

manual：手动ack，需要在业务代码结束后，调用api发送ack。

auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack

none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

auto模式：抛出异常后，Spring会自动返回nack，消息恢复至Ready状态，不会被RabbitMQ删除

三种模式分析：

manual：自己根据业务情况，判断什么时候该ack

auto模式类似事务机制，出现异常时返回nack，消息回滚到mq；没有异常，返回ack

none模式下，消息投递是不可靠的，可能丢失

消费者确认实现


spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: none # 关闭ack

可靠性保证-消费失败重试机制

默认：当消费者出现异常，消息会不断requeue（重入队）到队列，再重新发送给消费者，再异常...无限循环

即：利用Spring的retry机制，在本地重试，设置重试次数，每次失败等待时长

本地重试：（利用Spring的retry机制）

即：不再重入队，而是再本地重试


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

达到最大重试次数后：SpringAMQP会抛出异常AmqpRejectAndDontRequeueException

消息处理：查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是ack，mq删除消息了（可设置失败策略）

结论：

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

最大重试后的失败策略

在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecovery接口来处理，它包含三种不同的实现：

RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式（丢弃）

ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队（重入队）

RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机（投递到指定交换机）

推荐：采用方案三，重试耗尽后，投递到指定的交换机，由人工处理。

方案三实现方式

1：创建交换机，队列，并绑定


@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");
}

2：定义一个RepublishMessageRecoverer，关联队列和交换机


@Bean // 这里是定义失败消息策略，可通过return new的值修改策略
public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
    return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
}


@Configuration
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");
    }
}

可靠性总结


如何确保RabbitMQ消息的可靠性？
- 开启生产者确认机制，确保生产者的消息能到达队列
- 开启持久化功能，确保消息未消费前在队列中不会丢失
- 开启消费者确认机制为auto，由spring确认消息处理成功后完成ack
- 开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理

死信交换机

定义：

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

1：消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false（消费失败不重入队）

2：消息过期，无人消费

3：队列已满，无法投递

可以利用死信交换机，处理达到最大重试次数的消息


   	// 修改 失败消息策略
	@Bean
    public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
//        return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
        return new RejectAndDontRequeueRecoverer();
    }


1:创建队列，接收消息。并设置dead属性，指定死信交换机。（好的发走，坏的走死信交换机）
2：创建交换机队列，并绑定
3：死信就走队列绑定的死信交换机，接着到队列
@Configuration
	@Bean
    public Queue simpleQueue(){
        return QueueBuilder.durable("simple.queue") // 指定队列名称，并持久化
                .deadLetterExchange("dl.direct") // 指定死信交换机
                .build();
    }
    // 声明死信交换机 dl.direct
    @Bean
    public DirectExchange dlExchange(){
        return new DirectExchange("dl.direct", true, false);
    }
    // 声明存储死信的队列 dl.queue
    @Bean
    public Queue dlQueue(){
        return new Queue("dl.queue", true);
    }
    // 将死信队列 与 死信交换机绑定
    @Bean
    public Binding dlBinding(){
        return BindingBuilder.bind(dlQueue()).to(dlExchange()).with("simple");
    }

死信交换机总结


什么样的消息会成为死信？
 
- 消息被消费者reject或者返回nack
- 消息超时未消费
- 队列满了
 
死信交换机的使用场景是什么？
 
- 如果队列绑定了死信交换机，死信会投递到死信交换机；
- 可以利用死信交换机收集所有消费者处理失败的消息（死信），交由人工处理，进一步提高消息队列的可靠性。

TTL（超时）

写法：死信交换机基础上，在队列多写个TTL

一个队列中的消息如果超时未消费，则会变为死信，超时分为两种情况：

1:消息所在的队列设置了超时时间

2:消息本身设置了超时时间

TTL本质：（队列设置超时时间），队列内，超时未消费的信息被丢进死信交换机


@Bean
public Queue ttlQueue(){
    return QueueBuilder.durable("ttl.queue") // 指定队列名称，并持久化
        .ttl(10000) // 设置队列的超时时间，10秒
        .deadLetterExchange("dl.ttl.direct") // 指定死信交换机
        .build();
}

利用死信交换机与TTL实现延迟接收消息


@Test
public void testTTLMsg() {
    // 创建消息
    Message message = MessageBuilder
        .withBody("hello, ttl message".getBytes(StandardCharsets.UTF_8))
        .setExpiration("5000")
        .build();
    // 消息ID，需要封装到CorrelationData中
    CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
    // 发送消息
    rabbitTemplate.convertAndSend("ttl.direct", "ttl", message, correlationData);
    log.debug("发送消息成功");
}


 
    @RabbitListener(bindings = @QueueBinding(
            value = @Queue(name = "dl.ttl.queue", durable = "true"),
            exchange = @Exchange(name = "dl.ttl.direct"),
            key = "ttl"
    ))
    public void listenDlQueue(String msg){
        log.info("接收到 dl.ttl.queue的延迟消息：{}", msg);
    }

小结


消息超时的两种方式是？
 
- 给队列设置ttl属性，进入队列后超过ttl时间的消息变为死信
- 给消息设置ttl属性，队列接收到消息超过ttl时间后变为死信
 
如何实现发送一个消息20秒后消费者才收到消息？
 
- 给消息的目标队列指定死信交换机
- 将消费者监听的队列绑定到死信交换机
- 发送消息时给消息设置超时时间为20秒

如何实现发送一个消息20秒后消费者才收到消息？

原理：这边没有消费者监听队列，所以消息无法被消费。所以会在队列等待20S，然后被死信交换机获取


- 给消息的目标队列指定死信交换机
- 将消费者监听的队列绑定到死信交换机
- 发送消息时给消息设置超时时间为20秒

延迟交换机

前置：安装插件

发送方：

发送消息时，一定要携带x-delay属性，指定延迟的时间：


@Test
public void testDelayedMsg() {
    // 创建消息
    Message message = MessageBuilder
            .withBody("hello, delay message".getBytes(StandardCharsets.UTF_8))
            .setHeader("x-delay",10000)//看这里
            .build();
    // 消息ID，需要封装到CorrelationData中
    CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
    // 发送消息
    rabbitTemplate.convertAndSend("delay.direct", "delay", message, correlationData);
    log.debug("发送消息成功");
}

接收方：


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

基于@Bean的方式：给交换机配置delayed属性

消费堆积问题

解决一：多线程

解决二：提升消费者数量，提高消费速度

解决三：惰性队列（扩大队列容积）

接收到消息后直接存入磁盘而非内存

消费者要消费消息时才会从磁盘中读取并加载到内存

支持数百万条的消息存储

惰性队列设置：在声明队列时，指定x-queue-mode属性为lazy即可

基于@Bean声明lazy-queue


// 惰性队列
@Bean
public Queue lazyQueue(){
    return QueueBuilder.durable("lazy.queue")
            .lazy()
            .build();
}

基于@RabbitListener声明LazyQueue

可以通过命令行将一个运行中的队列修改为惰性队列：


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：策略的作用对象，是所有的队列


消息堆积问题的解决方案？
 
- 队列上绑定多个消费者，提高消费速度
- 使用惰性队列，可以再mq中保存更多消息
 
惰性队列的优点有哪些？
 
- 基于磁盘存储，消息上限高
- 没有间歇性的page-out（linux内存页默认4kb,页出就是分页写入磁盘的过程），性能比较稳定
 
惰性队列的缺点有哪些？
 
- 基于磁盘存储，消息时效性会降低
- 性能受限于磁盘的IO

MQ集群

普通集群

特点：元数据共享，消息不共享

例如我们有2个MQ：mq1，和mq2，如果你的消息在mq1，而你连接到了mq2，那么mq2会去mq1拉取消息，然后返回给你。如果mq1宕机，消息就会丢失。如果mq1宕机，消息就会丢失。

镜像模式（就是redis的主从集群）

队列消息会在各个mq的镜像节点之间同步

连接到任何一个镜像节点，均可获取到消息

一个节点宕机，并不会导致数据丢失。不过，这种方式增加了数据同步的带宽消耗。

镜像模式下，创建队列的节点被称为该队列的主节点，队列还会拷贝到集群中的其它节点，也叫做该队列的镜像节点。

主节点：处理请求

从节点：备份数据

用户发送给队列的一切请求，例如发送消息、消息回执默认都会在主节点完成，如果是从节点接收到请求，也会路由到主节点去完成。镜像节点仅仅起到备份数据作用。


总结如下：
 
- 镜像队列结构是一主多从（从就是镜像）
- 所有操作都是主节点完成，然后同步给镜像节点
- 主宕机后，镜像节点会替代成新的主（如果在主从同步完成前，主就已经宕机，可能出现数据丢失）
- 不具备负载均衡功能，因为所有操作都会有主节点完成（但是不同队列，其主节点可以不同，可以利用这个提高吞吐量）

镜像模式的配置：

1：准确模式：集群中队列副本（主服务器和镜像服务器之和）的数量。count如果为1意味着单个副本：即队列主节点。count值为2表示2个副本：1个队列主和1个队列镜像。

2：all：队列在群集中的所有节点之间进行镜像。

3：nodes：指定队列创建到哪些节点，如果指定的节点全部不存在，则会出现异常。如果指定的节点在集群中存在，但是暂时不可用，会创建节点到当前客户端连接到的节点。（指定队列在哪个节点创建）

一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一

消息可靠性：

常见的丢失原因：

发送时丢失：

- 生产者发送的消息未送达exchange
- 消息到达exchange后未到达queue

MQ宕机，queue将消息丢失
consumer接收到消息后未消费就宕机

解决：

生产者确认机制
mq持久化
消费者确认机制
失败重试机制

生产者消息确认

RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。

返回结果有两种方式：

publisher-confirm，发送者确认：

1：投递到交换机：返回ack

2：未投递到交换机：返回nack

备注：

publisher-return，发送者回执：

投递到交换机，未到队列，返回ack+路由失败原因

开启方式


spring:
  rabbitmq:
    publisher-confirm-type: correlated//开启pub...
    publisher-returns: true //开启 publisher-re...
    template:
      mandatory: true //开启消息路由失败策略
 
publish-confirm-type：开启publisher-confirm，这里支持两种类型：
- simple：同步等待confirm结果，直到超时
- correlated：异步回调，定义ConfirmCallback，MQ返回结果时会回调这个ConfirmCallback
 
mandatory: true    true，则调用ReturnCallback；false：则直接丢弃消息

情况一：消息未发送到交换机。ack为false

情况二：消息投递到交换机，未发送到队列

情况三：成功发送

消息持久化

交换机持久化

参数1： true 表示永久存在,即使mq重启，交换机也存在

参数2： false表示不自动删除，当交换机不被使用时，不被删除

队列持久化

即：重启不丢失

消息持久化

利用SpringAMQP发送消息时，可以设置消息的属性（MessageProperties），指定delivery-mode：

1：非持久化
2：持久化


 String routingKey = "simple";
        String message = "hello, spring amqp!";
        // 自定义数据
        CorrelationData data = new CorrelationData(UUID.randomUUID().toString());
        // 发送消息
        rabbitTemplate.convertAndSend("simple.direct", routingKey, message, new MessagePostProcessor() {
            // 后置处理消息
            @Override
            public Message postProcessMessage(Message message) throws AmqpException {
                // 设置消息的持久化方式
                message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT);
                return message;
            }
        },data);

消费者消息确认

RabbitMQ是阅后即焚机制，

消费者获取消息后，向RabbitMQ发送ACK回执（重点，什么时间回）

RabbitMQ收到回执，确认消息已被消费者消费，立即删除消息

问题：

消费者获取消息后，返回ACK给RabbitMQ

RabbitMQ删除消息

消费者宕机，消息尚未处理

SpringAMQP允许配置三种确认模式：

manual：手动ack，需要在业务代码结束后，调用api发送ack。

auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack

none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

使用：auto


spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: auto # 关闭ac

消费失败重试机制（达到最大重试次数走失败策略）

当消费者出现异常后，消息会不断requeue（重入队列），再重新发送给消费者，

无限循环，带来不必要的压力

1：本地重试

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


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

失败策略


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

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


  @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 // RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机
    public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
        return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
    }

失败策略

这是默认的第一种（上面那个是第二种）


@Bean
    public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate) {
        return new RejectAndDontRequeueRecoverer();
    }

死信交换机

死信：

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

1：消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false（消费失败，并且无法重入队的消息）

2：过期的消息

3：队列已满，无法投递的消息

死信交换机：

前置：A队列设置了dead-letter-exchange属性

本质：1：A队列投递消息到消费者失败后

2：消息进入与A绑定的交换机（此交换机称为死信交换机）

3：交换机绑定了一个存储失败信息的B队列，B队列称为死信队列

TTL（队列内，指定时间，未被消费的信息，丢进死信）

设置简述:设置队列时，写一个TTL属性，指定消费时间

1：要给队列设置超时时间，需要在声明队列时配置x-message-ttl属性


@Bean
public Queue ttlQueue(){
    return QueueBuilder.durable("ttl.queue") // 指定队列名称，并持久化
        .ttl(10000) // 设置队列的超时时间，10秒
        .deadLetterExchange("dl.ttl.direct") // 指定死信交换机
        .build();
}

2：声明交换机，将ttl与交换机绑定（这个是正常绑定的，不超时的就走这）


@Bean
public DirectExchange ttlExchange(){
    return new DirectExchange("ttl.direct");
}
@Bean
public Binding ttlBinding(){
    return BindingBuilder.bind(ttlQueue()).to(ttlExchange()).with("ttl");
}

3：在consumer服务的SpringRabbitListener中，定义一个新的消费者，并且声明死信交换机、死信队列：


@RabbitListener(bindings = @QueueBinding(
    value = @Queue(name = "dl.ttl.queue", durable = "true"),
    exchange = @Exchange(name = "dl.ttl.direct"),
    key = "ttl"
))
public void listenDlQueue(String msg){
    log.info("接收到 dl.ttl.queue的延迟消息：{}", msg);
}

相关阅读:
CocosCreator3.8研究笔记（三）CocosCreator 项目结构说明及编辑器的简单使用
 基于3D扫描和3D打印的产品逆向工程实战【数字仪表】
redux、mobx
JAVA学习笔记DAY6——SSM_Spring
用户留存为何重要？
网络安全（黑客）自学
 中项系统集成项目管理2023上半年真题及解析
 前端面试0906
Splunk 输出取 / 分割符之间的部分
 openssl 用法整理 —— 筑梦之路
原文地址：https://blog.csdn.net/weixin_50914566/article/details/133132543