RabbitMQ延迟消息的极限是多少？
source link: https://www.tuicool.com/articles/NJriiqq
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
之前在写Spring Cloud Stream专题内容的时候，特地介绍了一下 如何使用RabbitMQ的延迟消息来实现定时任务 。最近正好因为开发碰到了使用过程中发现，延迟消息没有效果，消息直接就被消费了的情况。因此就继续深入研究了一下问题原因，在此记录下来，给碰到类似问题的童鞋们参考。
问题定位
因为不是所有的消息都出现了没有延迟消息效果的因素，通过有问题的消息特征，大致猜测可能是延迟时间过长导致了消息延迟失败。为了验证这个原因，先拿之前文章中的例子，来测试一下延迟时间是否与问题直接相关。
对之前的延迟消息使用样例（文末的Git仓库中可以获取完整代码）接口做一下微改，增加了一个请求参数 delay
来控制延迟时间：
@GetMapping("/sendMessage")
public String messageWithMQ(@RequestParam String message, @RequestParam Long delay) {
log.info("Send: " + message);
testTopic.output().send(MessageBuilder.withPayload(message).setHeader("x-delay", delay).build());
return "ok";
}
然后尝试发起了两个请求：
请求1：延迟5000毫秒。消息发送到MQ之后确实延迟了5秒之后才得到了消费，没有任何问题。
curl localhost:8080/sendMessage?message=hello&delay=5000
请求2：延迟1年（31536000000毫秒）。消息发送到MQ之后马上就被消费者消费了，完全没有延迟效果。
curl localhost:8080/sendMessage?message=hello&delay=31536000000
问题小结
在明确了问题原因之后，需要对该功能的时候做一些明确的限定（延迟时间的极限），以避免再次出现类似的问题。深入探索下去，这里的失败主要与消息的过期时间（TTL）有直接的关系。在RabbitMQ中，消息的过期时间必须是非负 32 位整数，即：0 <= n <= 2^32-1，以毫秒为单位。 其中，2^32-1 = 4294967295。
这里我们可以尝试下面两个请求，分别设置延迟时间为4294967295何4294967296：
curl localhost:8080/sendMessage?message=hello&delay=4294967295 curl localhost:8080/sendMessage?message=hello&delay=4294967296
可以发现，当延迟时间为4294967295毫秒的时候，延迟消息工作正常；当延迟时间为4294967296毫秒的时候，消息被直接消费，没有延迟效果。
所以，我们在使用RabbitMQ的延迟消息功能时候，必须注意它的延迟极限是4294967296毫秒。如果你的业务需求会超过这个临界值，就必须避开这个坑，采用其他方法来实现需要延迟或者定时执行的任务了。
代码示例
本文示例读者可以通过查看下面仓库的中的stream-delayed-message项目：
- Github: https://github.com/dyc87112/SpringCloud-Learning/tree/master/4-Finchley
- Gitee: https://gitee.com/didispace/SpringCloud-Learning/tree/master/4-Finchley
如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK