RabbitMQ-延迟队列的使用

目录

一、使用场景

二、第一种方式:创建具有超时功能且绑定死信交换机的消息队列

三、第二种方式:创建通用延时消息

四、第三种方式:使用rabbitmq的延时队列插件,实现同一个队列中有多个不同超时时间的消息,并按时间超时顺序出队

[4.1 下载延迟插件](#4.1 下载延迟插件)

[4.2 安装插件并启用](#4.2 安装插件并启用)

五、延迟队列图示

六、源代码参考


一、使用场景

  • **1.**定时发布文章
  • **2.**秒杀之后,给30分钟时间进行支付,如果30分钟后,没有支付,订单取消。
  • **3.**预约餐厅,提前半个小时发短信通知用户。

A -> 13:00 17:00 16:30 延迟时间: 7*30 * 60 * 1000

B -> 11:00 18:00 17:30 延迟时间: 13*30 * 60 * 1000

C -> 8:00 14:00 13:30 延迟时间: 11*30 * 60 * 1000

二、第一种方式:创建具有超时功能且绑定死信交换机的消息队列

java 复制代码
   @Bean
    public Queue directQueueLong(){
        return   QueueBuilder.durable("业务队列名称")
                .deadLetterExchange("死信交换机名称")
                .deadLetterRoutingKey("死信队列 RoutingKey")
                .ttl(20000) // 消息停留时间
                //.maxLength(500)
                .build();
    }

监听死信队列,即可处理超时的消息队列

缺点:

上述实现方式中,ttl延时队列中所有的消息超时时间都是一样的,如果不同消息想设置不一样的超时时间,就需要建立多个不同超时时间的消息队列,比较麻烦,且不利于维护。

三、第二种方式:创建通用延时消息

java 复制代码
rabbitTemplate.convertAndSend("交换机名称", "RoutingKey","对象",
	message => {

 
			        message.getMessageProperties().setExpiration(String.valueOf(5000))
			        return message;
	            }
           );

缺点:

该种方式可以创建一个承载不同超时时间消息的消息队列,但是这种方式有一个问题,如果消息队列中排在前面的消息没有到超时时间,即使后面的消息到了超时时间,先到超时时间的消息也不会进入死信队列,而是先检查排在最前面的消息队列是否到了超时时间,如果到了超时时间才会继续检查后面的消息。

四、第三种方式:使用rabbitmq的延时队列插件,实现同一个队列中有多个不同超时时间的消息,并按时间超时顺序出队

4.1 下载延迟插件

在 RabbitMQ 的 3.5.7 版本之后,提供了一个插件(rabbitmq-delayed-message-exchange)来实现延迟队列 ,同时需保证 Erlang/OPT 版本为 18.0 之后。

我这里 MQ 的版本是 3.10.0 现在去 GitHub 上根据版本号下载插件

https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases

4.2 安装插件并启用

我用的是 Docker 客户端,下载完成后直接把插件放在 /root 目录,然后拷贝到容器内plugins目录下(rabbitmq是容器的name,也可以使用容器id)

java 复制代码
docker cp /opt/rabbitmq_delayed_message_exchange-3.10.0.ez rabbitmq:/plugins

进入 Docker 容器

java 复制代码
docker exec -it rabbitmq /bin/bash

在plugins内启用插件

java 复制代码
#先执行,解除防火墙限制,增加文件权限
umask 0022
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

退出容器

java 复制代码
exit

重启 RabbitMQ

java 复制代码
docker restart rabbitmq

通过UI查看

五、延迟队列图示

当C端用户发出消息的时候,延迟队列会实时检测谁的时间最短,自动将最短的排在前面,一定程度上避免了阻塞

六、源代码参考

https://codeup.aliyun.com/62858d45487c500c27f5aab5/springboot-rabbitmq.git

相关推荐
PingCAP15 小时前
善战者无赫赫之功:消费金融核心系统的数据库选型与升级路径
数据库·分布式·架构
库库的数据库笔记16 小时前
金融核心交易系统的数据库国产信创改造该如何做?
大数据·数据库·分布式·mysql·oracle·金融·数据库架构
爱吃火鸡面呀1 天前
深入理解 Spark RDD:五大特性与实战解析
大数据·分布式·spark
Linux实战笔记1 天前
记一次消息队列选型对比线上排查:Kafka/RabbitMQ/Pulsar 技术选型
kafka·rabbitmq·高并发·pulsar·消息队列选型
Norris Huang1 天前
Kafka Connect 与 Flink CDC 写入 Iceberg:Upsert 的代价,以及 S3 Tables 的真正价值
分布式·flink·kafka
张彦峰ZYF1 天前
一条消息的丢与重:Kafka 与 RabbitMQ 可靠投递的确认、位点、死信与幂等全链路
后端·kafka·消息队列·rabbitmq·isr·解耦与削峰·丢失与重复
我就是不信1 天前
集群高并发环境下如何保证分布式唯一全局ID生成?
分布式
黄俊懿2 天前
【架构师从入门到进阶】第六章:服务集群优化——第八节:线程数公式
java·服务器·数据库·分布式·性能优化·架构·系统架构
大菠萝爱上小西瓜2 天前
基于 Spark + Iceberg 湖仓一体的 Netflix 流媒体用户行为全链路数仓与 ALS 智能推荐决策系统(含穿透下钻大屏)
大数据·分布式·spark
吴建旭 智宅焕2 天前
智能家居售后服务体系的架构设计:分布式售后风险的集中式兜底方案
分布式·智能家居