延迟队列,顾名思义它是一种带有延迟功能的消息队列。那么,是在什么场景下我才需要这样的队列呢?
1. 背景
我们先看看以下业务场景:
- 当订单一直处于未支付状态时,如何及时的关闭订单
- 如何定期检查处于退款状态的订单是否已经退款成功
- 在订单长时间没有收到下游系统的状态通知的时候,如何实现阶梯式的同步订单状态的策略
- 在系统通知上游系统支付成功终态时,上游系统返回通知失败,如何进行异步通知实行分频率发送:15s 3m 10m 30m 30m 1h 2h 6h 15h
1.1 解决方案
- 最简单的方式,定时扫表。例如对于订单支付失效要求比较高的,每2S扫表一次检查过期的订单进行主动关单操作。优点是简单,缺点是每分钟全局扫表,浪费资源,如果遇到表数据订单量即将过期的订单量很大,会造成关单延迟。
- 使用RabbitMq或者其他MQ改造实现延迟队列,优点是,开源,现成的稳定的实现方案,缺点是:MQ是一个消息中间件,如果团队技术栈本来就有MQ,那还好,如果不是,那为了延迟队列而去部署一套MQ成本有点大
- 使用Redis的zset、list的特性,我们可以利用redis来实现一个延迟队列RedisDelayQueue
2. 设计目标
- 实时性:允许存在一定时间的秒级误差
- 高可用性:支持单机、支持集群
- 支持消息删除:业务会随时删除指定消息
- 消息可靠性:保证至少被消费一次
- 消息持久化:基于Redis自身的持久化特性,如果Redis数据丢失,意味着延迟消息的丢失,不过可以做主备和集群保证。这个可以考虑后续优化将消息持久化到MangoDB中
3. 设计方案
设计主要包含以下几点:
- 将整个Redis当做消息池,以KV形式存储消息
- 使用ZSET做优先队列,按照Score维持优先级
- 使用LIST结构,以先进先出的方式消费
- ZSET和LIST存储消息地址(对应消息池的每个KEY)
- 自定义路由对象,存储ZSET和LIST名称,以点对点的方式将消息从ZSET路由到正确的LIST
- 使用定时器维护路由
- 根据TTL规则实现消息延迟
3.1 设计图
还是基于有赞的延迟队列设计,进行优化改造及代码实现。有赞设计
3.2 数据结构
ZING:DELAY_QUEUE:JOB_POOL
是一个Hash_Table结构,里面存储了所有延迟队列的信息。KV结构:K=prefix+projectName field = topic+jobId V=CONENT;V由客户端传入的数据,消费的时候回传ZING:DELAY_QUEUE:BUCKET
延迟队列的有序集合ZSET,存放K=ID和需要的执行时间戳,根据时间戳排序ZING:DELAY_QUEUE:QUEUE
LIST结构,每个Topic一个LIST,list存放的都是当前需要被消费的JOB
图片仅供参考,基本可以描述整个流程的执行过程
3.3 任务的生命周期
- 新增一个JOB,会在
ZING:DELAY_QUEUE:JOB_POOL
中插入一条数据,记录了业务方消费方。ZING:DELAY_QUEUE:BUCKET
也会插入一条记录,记录执行的时间戳 - 搬运线程会去
ZING:DELAY_QUEUE:BUCKET
中查找哪些执行时间戳的RunTimeMillis比现在的时间小,将这些记录全部删除;同时会解析出每个任务的Topic是什么,然后将这些任务PUSH到TOPIC对应的列表ZING:DELAY_QUEUE:QUEUE
中 - 每个TOPIC的LIST都会有一个监听线程去批量获取LIST中的待消费数据,获取到的数据全部扔给这个TOPIC的消费线程池
- 消费线程池执行会去
ZING:DELAY_QUEUE:JOB_POOL
查找数据结构,返回给回调结构,执行回调方法。
3.4 设计要点
3.4.1 基本概念
- JOB:需要异步处理的任务,是延迟队列里的基本单元
- Topic:一组相