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

已于 2023-10-27 08:54:49 修改
阅读量169 收藏 1
点赞数 3
文章标签： 网络 中间件
于 2023-09-21 13:41:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_50914566/article/details/133132543
版权

二刷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);
}

一键三联鸭~
关注
  • 3
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
xiuxian:修仙之路 - 小游戏 玩法同2048
06-09
xiuxian修仙之路 - 小游戏 玩法同2048浏览器支持:现代浏览器在2048的逻辑基础上增加修仙等级对应的文字映射,以当前游戏程序为基础,开发者可以开发出任意等级,只需要修改 game_manager.js 中的this.tilesTextArr对应...
Python基于Nonebot2的修仙文字游戏插件+使用说明.zip
09-21
配置地址:修仙插件下xiuxian_config.py<br> 在只有一个qq链接的情况下风控配置应该全部为空，即不配置<br> self.put_bot = [] # 接收消息qq,主qq,框架将只处理此qq的消息，不配置将默认设置第一个链接的qq为主qq<br>...
Java修仙之路，十万字吐血整理全网最完整Java学习笔记（基础篇）
vincewm的博客
01-05 4038
从Java环境的搭建到实际代码的编写，从基本用法的讲解到底层原理的剖析，深度解析Java基础知识。本文是《Java学习路线》专栏的起始文章，旨在提供一套完整的Java学习路线，覆盖Java基础知识、数据库、SSM/SpringBoot等框架、Redis/MQ等中间件、设计模式、架构设计、性能调优、源码解读、核心面试题等全面的知识点，并在未来不断更新和完善，帮助Java从业者在更短的时间内成长为高级开发。
Java修真之练气筑基篇(持续更新)
qq_36317312的博客
08-26 1699
因为对于天产土豆的斗破苍穹印象还是比较深的， 所以就拿主角萧炎来说吧，练气筑基阶段是非常重要的，只有基础打得牢，才能够一路披荆斩棘，越阶战斗！ 同理而言，对于刚接触Java 的小伙伴来说，Java基础也就是练气筑基过程，只有打牢基础，才能万层高楼拔地起，任凭风吹雨打不动摇！ 我虽然在本科期间学习过，但是现在只记得一些零零碎碎的内容，所以在研究生学余时间想系统的学习一遍。 下面就让小曾带你一起学java基础，我们来一起练气筑基！ Java基础 1.1注释、标识符、关键字 注释 相信写过代码的都知..
Java修仙之高级功法篇-＞MybatisPlus
weixin_50914566的博客
09-11 323
*** @Description 自定义sql分页查询实现*/@TestMapper层//@Mapper/*** 查询大于指定id的用户信息，并分页查询实现* @return*/XML
Java修真之修炼斗技--入门面向对象
qq_36317312的博客
09-03 948
前言 在修真一途，以斗破苍穹来说，上一篇斗气筑基仅仅只是一个开始，有了少量的斗气后，那么也需要学会斗技，这样才能提升自己的实力。在学习Java 的时候也是如此，上一篇Java基础只是简单的入门，目前学习的“斗技”–面向对象，才是Java 的精髓。 斗技分天,地,玄,黄 四个等级，那么对应学习Java内容，应该也是从初级来开始。 ...
Java修仙，法力无边（光速回顾Java基础~）
小菜鸡的小博客
02-20 913
一起来回顾Java基础吧~向着大牛冲冲冲！！
基于C#实现的文字修仙游戏源码（高分项目）.zip
05-08
基于C#实现的文字修仙游戏源码（高分项目）.zip本资源中的源码都是经过本地编译过可运行的，评审分达到95分以上。资源项目的难度比较适中，内容都是经过助教老师审定过的能够满足学习、使用需求，如果有需要的话可以...
运气修仙1.8文字修仙来了 上班摸鱼利器源码编译小游戏
最新发布
07-18
主题是种菜挂机类修仙，纯文字摸鱼，操作简单 里面拥有种药、炼丹、嗑药、挂机、渡劫、打怪、升级、论道、等内容 你要做的就是聊天摸鱼，点点点个，感兴趣的可以试一试。 前端wpf+prism+MaterialDesign 后端...
2021修仙游戏市场研究报告-AdTiming企划部-202107.pdf
07-18
2021修仙游戏市场研究报告-AdTiming企划部-202107.pdf
最强Java修仙之路【附赠BAT修炼资源】，这些核心技能是你必须要掌握的！！
shayukaifa的博客
04-25 1432
代码尽头谁为峰，一见秃头道成空。 编程修真路破折，一步一劫渡飞升。 众所周知，编程修真有八大境界： Javase-练气筑基 数据库-结丹 web前端-元婴 Javaweb-化神 Javaweb项目-炼虚 流行框架-合体 分布式•微服务-大乘 架构师-飞升 第一部分：JavaSE-练气筑基 Java SE大致可分为以下几块内容: n 对象导论：如何用面向对象的思路来开发 n 深入JVM：Java运行机制以及JVM原理 n 面向对象的特征：封装、继承、抽象、多态 n 数组和容器：容
java修仙录-集群、负载均衡和分布式
爱码农的小java的博客
04-28 392
java修仙录-集群、负载均衡和分布式序集群负载均衡分布式总结 序 天地不仁，以万物为刍狗。我辈修仙 ，逆天伐道。在下java派散人- 玄重子，修仙年许，虽有小成，不过 一毛之长。修仙路漫漫， 吾将上下而求索。小道才开始研究分布式，有些弯弯绕绕总是不能融汇贯通。撇开代码不言，光是这三字要义就让我破费脑力。所幸有许多师兄前辈的修仙心得可以参考，从中也参悟出一些自己的感悟,特记录于此。由于鄙人才疏学浅...
用修仙小说的方式打开java——初识java（一）
WRZSPBM的博客
12-29 806
新手村的Java 在这一片Java大陆中，位于新手村的那必然是我们的 JavaSE 在我们修炼（学习）之前肯定是要去了解这一个世界是怎么样的存在，这个世界由各种不同的程序员组成，每个人的实力（技术水平）有高有低，可是为什么要叫程序员呢？这就不得不说说程序这个东西了 什么是程序呢？程序就是计算机执行某些操作或解决某个问题而编写的一系列有序指令的集合 ...
【java修仙路：炼气期】java的理解 （涉及linux用命令对java进行部署）
qq_44162236的博客
03-02 640
java一、理解java1、问题（1）Hello是我们自己定义的一个类，为什么写java代码的时候要写一个类？2、Hello类中的方法，为什么名字要叫做main？System.out.println("hello world")，这句代码具体是什么意思？在Hello中，我们为什么可以使用System这个类？使用java Hello运行这个类的时候，JVM是通过什么找到Hello.class文件的？Hello这个类的名字和Hello.java的名字有什么必然关系么？2、pacakge3 、jar如何将自己的c
Java程序员修仙之路，不进反退，前同事凭借着3份文档，年薪50W
求关注
05-21 713
前言 前段时间有一些同事离职了，准确的说是跳槽，话说跳槽这个东西确实会传染，跳槽也是我们程序生涯的重要一环，工作差不多 5 年，换了三家公司，也呆过不少小作坊，就差去过大厂，所以想拼一拼看看自己可不可以走进大厂，这是他们的原话。 其中有个同事也是成功进入了阿里巴巴，虽然不是年薪百万的大牛，但也一年拿个50W也是可以的，我特地和他咨询了下，他就甩给我三份文档分别是《Java高级架构面试知识点整理》《1000道互联网ava程师面试题》《Java核心知识点》，说他在过年家里呆的时候就已经准备了，天天在家啃知识
springboot-启动加载类
子龙修仙的博客
04-13 7412
项目在启动的时候做一些初始化工作，需要实现ApplicationRunner接口，并重写run()方法，当项目启动时，run()方法便会自动执行。 package com.wps.education.runner;import com.wps.education.Service.IAuthorityService;import org.springframework.boot.Applic...
Response简单讲解（Java修仙体系结丹境）
烟雨红尘·客栈
03-18 530
Response (J2EE筑基境) 首先我们介绍下它的数据格式 首先有两大类需要了解，数据行和数据头。其他的还有数据空行和数据体，这里就不写了 关于数据行，我们介绍两大类，一个是数据响应行，一个是状态码 数据响应行 HTTP/1.1 200 OK; // 这个就是其数据响应行，我们可以去浏览器F12看看 下面就是状态码了 1xx：在服务器接收客户端消息一段时间后，发送1xx状态码，主要是免得：请求一次断开一次，大大降低了网页的载入速度 2xx：这个一般是200，表示成功 3xx：这个的代表是 302，代表
Java线程简单讲解（Java修仙体系筑基境）
烟雨红尘·客栈
03-29 1397
Java线程简单讲解
Java工程师修炼之路（校招总结）
weixin_30553837的博客
02-20 6179
Java工程师修炼之路（校招总结） 前言 在下本是跨专业渣考研的985渣硕一枚，经历研究生两年的学习积累，有幸于2019秋季招聘中拿到几个公司的研发岗offer，包括百度，阿里，腾讯，今日头条，网易，华为等。 一路走来也遇到很多困难，也踩了很多坑，同时我自己也探索了很多的学习方法，总结了很多心得体会，并且，我对校园招聘也做了一些研究和相应的准备。 在...
STM32CubeMX配置时如何开启SYS->Debug
02-16
在STM32CubeMX中开启SYS->Debug功能，请按照以下步骤操作： 1. 打开STM32CubeMX软件，并创建一个新项目。 2. 在"Pinout & Configuration"选项卡中，选择你的芯片型号。 3. 在"System Core"中选择"SYS"选项卡。 4. ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值