一、起因

测试提了一个 bug 说福袋下架后拼团失败的订单并没有自动退款，当时就纳闷了，延迟队列用的是RabbitMQ 死信队列 + TTL 过期时间做的，本地测试的时候一切都正常，然后开始查看测试库的日志，发现福袋的下架时间是在 21 号，本应该马上触发的过期事件却在 22 号才触发，差了一天多的时间！见了鬼了，能有这么大的误差？

二、复现

同时发布两个福袋，第一个福袋设置 10 分钟后过期，第二个福袋设置 3 分钟后过期，结果本地测试时第二个福袋不会在 3 分钟后触发，而是等到 10 分钟后第一个福袋触发过期事件后第二个福袋才触发过期事件，复现成功

三、查找原因

先在 ChatGPT 上问，问答我说 RabbitMQ 是惰性检查，只有新消息进队列或者原队列有消息被访问（消费），才会触发 TTL 清理机制并将过期消息送入死信队列。给我的解决方案是：
1、定期向原队列发送无关消息触发清理
2、使用 RabbitMQ 插件 rabbitmq_delayed_message_exchange
这里有疑问：我之前测试的时候发布一个一天有效期的福袋后就没有任何操作了，结果第二天可以准时收到这个福袋的过期事件，并不符合 ChatGPT 前面说的TTL 清理机制。
带着这个疑问继续百度，最后在一篇文章中找到我想要的答案(所以ChatGPT的话也不能全信)，原文链接：https://baijiahao.baidu.com/s?id=1758898853840326486&wfr=spider&for=pc

最终原因

尽管 TTL 过期时间是设给每条消息的。但是本质上，所有延时消息都还在一个队列里，对它过期时间的检测也是从头部开始的，RabbitMQ 出于性能原因不会检测每一条消息的过期时间，而是顺序检测。如果第一条消息的过期时间很长，会导致它阻塞后进的消息。

订单未支付超时也是用死信队列做的，但是它的过期时间是固定的，比如所有未支付的订单都是 30 分钟后过期，这样的话第一个进入队列里的永远是最先触发过期时间的，后面消息的过期时间不可能早于第一条消息，所以这种情况就不会出现上面那种 bug，这也是为什么死信队列用了那么久了之前没发现问题。

四、解决问题

使用 RabbitMQ 的 rabbitmq_delayed_message_exchange 插件
地址：https://github.com/rabbitmq/rabbitmq-delayed-message-exchange
此插件写明了旨在将消息发布延迟几秒、几分钟或几小时。最多一两天。
这不是一个长期的调度解决方案。如果您需要将发布延迟几天、几周、几个月或几年，请考虑使用适合长期存储的数据存储，以及某种外部调度工具。
我的项目有延迟几天的情况，但是数据量不大，可以用这个插件。如果数据量大又要延迟几天，建议使用数据库的方式来做。

安装rabbitmq_delayed_message_exchange，版本号应对应 RabbitMQ 的版本号
mac:
我是用 Homebrew 安装的 RabbitMQ，需要先找到RabbitMQ 插件目录
查看路径：brew list rabbitmq
一般是这个路径：/opt/homebrew/Cellar/rabbitmq/4.1.0/plugins
进入插件目录：cd /opt/homebrew/Cellar/rabbitmq/4.1.0/plugins
下载对应版本插件（版本需与你的 RabbitMQ 匹配）
wget https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases/download/v4.1.0/rabbitmq_delayed_message_exchange-4.1.0.ez
linux:
去下载页找自己对应的版本的.ez 文件
https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases
然后找到自己 rabbitmq 的插件目录，一般是：/usr/lib/rabbitmq/lib/rabbitmq_server-3.12.13/plugins，把下载好的 .ez 文件放进这个目录
启用插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange
重启 RabbitMQ 服务
brew services restart rabbitmq
验证插件是否启用成功
rabbitmq-plugins list | grep delayed
你应该看到：[E*] rabbitmq_delayed_message_exchange 4.1.0
修改代码
// 声明延迟交换机（使用 rabbitmq_delayed_message_exchange 插件）
@Bean(“luckybagDelayExchange”)
public CustomExchange luckybagDelayExchange() {
Map<String, Object> args = new HashMap<>();
args.put(“x-delayed-type”, “direct”); // 内部实际类型是 direct
return new CustomExchange(RabbitConstant.LUCKYBAG_DELAY_EXCHANGE, “x-delayed-message”, true, false, args);
}

// 延迟队列（无需死信相关配置）
@Bean(“luckybagDelayQueue”)
public Queue luckybagDelayQueue() {
return QueueBuilder.durable(RabbitConstant.LUCKYBAG_DELAY_QUEUE).build();
}

// 绑定延迟队列到延迟交换机
@Bean
public Binding luckybagDelayBinding(@Qualifier(“luckybagDelayQueue”) Queue queue,
@Qualifier(“luckybagDelayExchange”) CustomExchange exchange) {
return BindingBuilder.bind(queue).to(exchange).with(RabbitConstant.LUCKYBAG_DELAY_QUEUE_ROUTING_KEY).noargs();
}

// 监听延迟队列
@RabbitListener(queues = RabbitConstant.LUCKYBAG_DELAY_QUEUE)
@RabbitHandler

五、测试

按照第二点的复现再来一遍，十分钟后…搞定！

关于 RabbitMQ 的死信队列在规定的延迟时间后没有及时触发的问题

发表评论

共0条评论