关于Redisson延迟队列的一些思考(3)

关于Redisson延迟队列的一些思考

将上述代码运行起来，一端投递数据，一端消费数据，然后连接上Redis，你会发现有两个队列存在：

这两个队列中，带有timeout关键字的那条是一个ZSet集合，另一个是普通的List。

但是为什么要设计两条队列呢，后边我查阅了相关资料，大概整理了下Redisson的延迟队列原理如下：

• 客户端启动，redisson先订阅一个key，同时 BLPOP key 0 无限监听一个阻塞队列（等里面有数据了就返回）。
• 当有数据put时，redisson先把数据放到一个zset集合（按延时到期时间的时间戳为分数排序），同时发布上面订阅的key，发布内容为数据到期的timeout，此时客户端进程开启一个延时任务，延时时间为发布的timeout。
• 客户端进程的延时任务到了时间执行，从zset分页取出过了当前时间的数据，然后将数据rpush到第一步的阻塞队列里。然后将当前数据从zset移除，取完之后，又执行 BLPOP key 0 无限监听一个阻塞队列。这一部分的逻辑，客户端会发送一个lua脚本给到服务端去操作：org.redisson.RedissonDelayedQueue源码里面的pushTaskAsync函数有lua脚本内容。

• 上一步客户端监听的阻塞队列返回取到数据，回调到 RBlockingQueue 的 take方法。于是，我们就收到了数据。

ps：可能有些同学对Redis的发布订阅不是很了解，你大概可以理解为是Redis做的一种消息广播机制。客户端订阅了A渠道之后，往A渠道发送内容，此时所有的订阅方立即可以收到消息内容。关于订阅发布的原理，可以看看这篇文章：https://cloud.tencent.com/developer/article/2297090

利用了Redis的订阅发布，确实可以减少客户端长时间轮询ZSet带来的网络性能开销，但需要依靠客户端的延迟任务，隔一段时间再去拉去zset。

Redisson为啥要多搞一个List出来

但是为什么从ZSet中取到消息之后，还得放入一个List队列中，然后再利用bLPop去获取元素呢？

这里说下我自己的一些思考：

Redisson的延迟消息设计的初衷，只是提供了一个到时间弹出到特定队列的功能，但是至于这条消息队列你要如何操作，反而是留给了开发者自己去思考。（例如消息的重试方面）

所以如果要用Redisson去做延迟消息，而且你自己也希望能具备一些重试机制的话，那么这个List是可以去自由发挥的。

而如果只是单纯的到时间了，直接从ZSet中取出来就完事的话，那么可二次发挥的空间就会少了些许。

上面IT袋网为您介绍的关于Redisson延迟队列的一些思考的具体介绍，希望大家能喜欢！