共计 1501 个字符，预计需要花费 4 分钟才能阅读完成。
之前在写 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 的延迟消息功能时候，必须注意它的延迟极限是 4294967295 毫秒。如果你的业务需求会超过这个临界值，就必须避开这个坑，采用其他方法来实现需要延迟或者定时执行的任务了。
代码示例
本文示例读者可以通过查看下面仓库的中的 stream-delayed-message 项目：
- Github: https://github.com/dyc87112/S…
- Gitee: https://gitee.com/didispace/S…
如果您对这些感兴趣，欢迎 star、follow、收藏、转发给予支持！
欢迎关注我的公众号：程序猿 DD，获得独家整理的学习资源和日常干货推送。如果您对我的专题内容感兴趣，也可以关注我的博客：didispace.com
