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

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

为网友们详解关于Redisson延迟队列的一些思考方面的知识，具体详情如下：

最近部门在做一套告警治理相关的系统，专门用于对整个业务线杂七杂八的告警进行治理管控。

例如Kakfa异常，业务异常，Dubbo超时等等场景，全部都首先会被这套系统给监控到，然后再通过一定的策略分配，将异常内容转换为特定的消息模版告知给特定的业务方。

然后，这里面涉及到一个告警升级的问题需要处理，例如告警消息发送给A员工，但是A员工可能没有看到消息，那么超过一定时限之后，该消息需要升级发送给B员工，以此类推。

关于升级这块的链路，我早期一开始想的是设计扫表+定时任务的思路去做，后边发现这套方案数据存储会有冗余，维护成本高，所以打算换个思路去实现–延迟消息。

延迟队列的选型

最早是计划用mq的延迟消息去做的，但是公司内部用的都是Kafka集群，Kafka不支持延迟队列。

如果想用RocketMQ的延迟队列，那么就得搭建一套RocketMQ的环境，运维成本也比较高。

所以后边看了下目前已有的基建设施，打算试试Redis的延迟队列。

为什么敢选择Redis做延迟队列？

衡量了一下业务场景的指标，首先异常通知的并发量不会特别多，即使说异常故障瞬间爆发，上游也会有“聚合”（例如100条异常合成1条告知下游）。

所以到达升级这一环节的并发量很小。正应为数据量不高，所以才敢尝试用Redis做延迟队列。

加上目前Redis的基建也比较完善，内存空间足够大，而且对于消息通知的可靠性要求不会说要100%那么高。

Redis可以怎么做延迟队列

很早以前自己也试过基于Redis的Zset去实现一套延迟队列。这里可以利用到一个redis的zset数据结构。

zset结构中基本存储信息和set结构类似，但是会给每个元素都有一个排分的score标示，根据排分的大小会在内存中进行排序操作。

然后由客户端定时扫描ZSet中达到提取时间的数据，这里推荐使用zrangebyscore函数去实现。

zrangebyscore用法扫盲

>> zrangebyscore key min max [WITHSCORES] [LIMIT offset count]
分页获取指定区间内(min - max)，带有分数值(可选)的有序集成员的列表。

扫描出来的数据，就是延迟时间截止的数据，从而实现延迟处理的效果。

这套思路是自己早两年的设计方式，然而最近又重新去看了下延迟队列的设计，发现Redisson的部分设计却有些许不同。