本文共 1772 字,大约阅读时间需要 5 分钟。
点击蓝色“程序猿DD”关注我
回复“资源”获取独家整理的学习资料!
之前在写Spring Cloud Stream专题内容的时候,特地介绍了一下。最近正好因为开发碰到了使用过程中发现,延迟消息没有效果,消息直接就被消费了的情况。因此就继续深入研究了一下问题原因,在此记录下来,给碰到类似问题的童鞋们参考。
问题定位
因为不是所有的消息都出现了没有延迟消息效果的因素,通过有问题的消息特征,大致猜测可能是延迟时间过长导致了消息延迟失败。为了验证这个原因,先拿之前中的例子,来测试一下延迟时间是否与问题直接相关。
对之前的延迟消息使用样例(文末的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/SpringCloud-Learning/tree/master/4-Finchley
Gitee: https://gitee.com/didispace/SpringCloud-Learning/tree/master/4-Finchley
如果您对这些感兴趣,欢迎star、follow、收藏、转发给予支持!
留言交流不过瘾?添加微信:zyc_enjoy
根据指引加入各种主题讨论群
每日一问
今日问题:请问把一盒蛋糕切成8份,分给8个人,但蛋糕盒里还必须留有一份。大家如何把蛋糕分给这八个人。
(留言说说你的方案吧,明日推文公布答案)
昨日答案:将第二个杯子里的水倒入第五个杯子
(昨日问题可在昨日推文的文末查看)
推荐阅读
来星球聊聊技术人的斜杠生活
点一点“阅读原文”小惊喜在等你
转载地址:https://didispace-wx.blog.csdn.net/article/details/97062638 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!