热门标签 | HotTags
当前位置:  开发笔记 > 后端 > 正文

rockemq发送延迟消息_RabbitMQ的延迟消息究竟是多少?

最近正好因为开发碰到了使用过程中发现,延迟消息没有效果,消息直接就被消费了的情况。因此就继续深入研究了一下问题原因,在此记录下来ÿ
35db0c540a2ab464f06b555d989a2e64.png

最近正好因为开发碰到了使用过程中发现,延迟消息没有效果,消息直接就被消费了的情况。因此就继续深入研究了一下问题原因,在此记录下来,给碰到类似问题的童鞋们参考。

问题定位

因为不是所有的消息都出现了没有延迟消息效果的因素,通过有问题的消息特征,大致猜测可能是延迟时间过长导致了消息延迟失败。为了验证这个原因,先拿之前文章中的例子,来测试一下延迟时间是否与问题直接相关。

对之前的延迟消息使用样例,接口做一下微改,增加了一个请求参数delay来控制延迟时间:

648cfcde333893c570ce3bcde083c0ef.png

然后尝试发起了两个请求:

请求1:延迟5000毫秒。消息发送到MQ之后确实延迟了5秒之后才得到了消费,没有任何问题。

f506d6b1bde5a8f8b3dde9997a18cb85.png

请求2:延迟1年(31536000000毫秒)。消息发送到MQ之后马上就被消费者消费了,完全没有延迟效果。

750509515f93a0a6c194c7776b4b9ef4.png

在明确了问题原因之后&#xff0c;需要对该功能的时候做一些明确的限定(延迟时间的极限)&#xff0c;以避免再次出现类似的问题。深入探索下去&#xff0c;这里的失败主要与消息的过期时间(TTL)有直接的关系。在RabbitMQ中&#xff0c;消息的过期时间必须是非负 32 位整数&#xff0c;即&#xff1a;0 <&#61; n <&#61; 2^32-1&#xff0c;以毫秒为单位。 其中&#xff0c;2^32-1 &#61; 4294967295。

这里我们可以尝试下面两个请求&#xff0c;分别设置延迟时间为4294967295何4294967296&#xff1a;

ce26082ebc120483cd2abc1f6f111a9a.png

可以发现&#xff0c;当延迟时间为4294967295毫秒的时候&#xff0c;延迟消息工作正常&#xff1b;当延迟时间为4294967296毫秒的时候&#xff0c;消息被直接消费&#xff0c;没有延迟效果。

所以&#xff0c;我们在使用RabbitMQ的延迟消息功能时候&#xff0c;必须注意它的延迟极限是4294967296毫秒。如果你的业务需求会超过这个临界值&#xff0c;就必须避开这个坑&#xff0c;采用其他方法来实现需要延迟或者定时执行的任务了。

如果你对此感兴趣&#xff0c;欢迎关注&#xff0c;收藏&#xff0c;转发&#xff01;学习上有问题的可以私信我或者加qun(630——455——594)获取资料

91245509372245f7ae3a74f4e55ecddc.png



推荐阅读
author-avatar
大眼妹886
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有