由一次管理后台定时推送功能引发的对 RabbitMQ 延迟队列的思考 (一)

关注

发布于: 2020 年 06 月 13 日

有天下午，同事问了一个问题：有没有遇到过带 TTL 的消息不能自动过期导致该条消息无法被路由到死信队列的问题。

当我听到这个问题时，脑子里其实是空荡荡的就像被捅了的马蜂窝一样，仿佛再次置身于一场面试中，而自己作为应聘者再次被面试官问了一个自己毫无头绪的问题。我本可说出"没有"二字来答复对方但是为了让自己不至于太尴尬，所以镇定自若的说了一句：“没有遇到过哦”。努力将"没有"二字延长到"没有遇到过哦"六个字，似乎这样可以弥补自己技术上的不足。

需求的这样的：

要实现的功能很简单，在管理后台实现定时发送 消息推送 的功能。具体发送的时间点可以随意设置。

介于此，有关开发人员决定要使用 RabbitMQ 的 TTL 和死信队列的特性来实现延迟队列，然后就紧张旗鼓的开始做，当然要做的功能多的数也数不清，这只是其中一个，所以一直到上线前夕才抛出开头提到的问题，就像在信心满满的代码中抛出一个迄今为止都没有遇到过的异常一样，顿时茫然无措

要给我做的话，二话不说肯定是上 spring 的定时器，我并没有使用过 RabbitMQ 延迟队列的特性，定时器的话常规套路，熟门熟路，稳打稳扎，是最保险的一种做法，不过也正因为此，一味求稳却缺乏创新，导致技术提升缓慢。

问题是这样的：

每当有一场比赛的时候，在比赛开始前总会给特定用户推送一条消息。所以会把带有 TTL 的消息放入普通队列（起名为 GeneralQ），静静等候（TTL 的值就是自消息入队后开始直到准备要推送消息的那一刻的时间差）。等到消息过期时，通过 DLX(死信交换机)将过期的消息路由到与之关联的 DLQ 中(死信队列)，在 DLQ 的那一头，连接着的是一头微伏的消费者，静候其中，一旦有 DLM(死信消息)过来,他便猛扑上去。

经过一番调试，总会有一部分本该过期的消息没有正常到达死信队列。“出现这种情况的概率大不大”，我问道，依然想通过这种问题来掩饰自己的不足，这样的问题再一次完美的暴露了自己的无知和见识短浅，“挺常见的”，他说。我又一次假装陷入沉思。其实我并不是一个不求上进不思进取之人。

然后我开始查找资料，我先是查 TTL，再查死信队列，再查延迟队列；此时：

另一个同事给他仍过去一张截图，说："你看，给每个消息单独设置 TTL 确实不能及时丢弃消息，而在队列上设置一个全局的 TTL 是可以，我们可以试试这么做"。而这张图片就像闷热的午后三点想起的一声惊雷一样，完全惊醒了我

“能不能把连接发过来，不要只发从上面截取的一张图片”。

“好的”，同事说

而全局设置 TTL 的方式，经过短暂讨论一票否决。

突然间我恍然大悟，过期消息只有在给消费者下发的时候才会丢弃。或者说只有当到达队头的时候才会被丢弃，我突然间又想到了 redis 对于过期健的处理方式，做的异曲同工，只有用的时候才会判断，当然 redis 并不是只有这一种处理方式。

考虑一种情况：第一条入队的消息过期时间是 2 个小时，第二条入队的消息过期时间是 2 分钟，也就是说入队时间是按 TTL 倒叙入队，此时就会陷入一种尴尬之地，由于第一条消息拥有很长的存活时间，它会一直霸占着队首，使得第二条消息在 2 分钟后不能被清理，因为它没在队首，所以没有机会被丢弃。（基于此，我提出了第一个解决方案，后面说）

鉴于此，我想到了队列的顺序问题，自然地想到了优先级队列，所以后面我又迷失在 TTL、死信、优先级队列这三个概念的混乱中长达 11 个小时之久

再考虑第二种情况：如果将上面的消息按 TTL 时间正序入队，那么是不会出现问题的。

我将这一结论告知于他，完美的解释了他的问题。他将信将疑的做了几次实践，结果完全吻合，充分证明实践出真知。

简短总结

我们总是想当然的以为时间一到便自动清理，就和闹钟一样，时间一到，立刻响起。但其实它就像在冰箱里过期了的馒头，不吃的时候你不知道它发霉没有，等到吃的时候，才拿起来随手扔到垃圾桶。技术不能想当然，而是需要不折不扣的去实践，当然最后可能以失败告终，就像这次我后续的研究结果一样，但是这并不妨碍我们在实践的过程中学到很多知识。并且失败了以后你才能知道怎样做才能成功，才能理解某一个技术点的边界所在。