SpringBoot 整合：Redis延时队列的简单实现

业务流程

首先我们分析下这个流程

1. 用户提交任务。首先将任务推送至延迟队列中。
2. 延迟队列接收到任务后，首先将任务推送至 job pool 中，然后计算其执行时间。
3. 然后生成延迟任务（仅仅包含任务 id）放入某个桶中
4. 时间组件时刻轮询各个桶，当时间到达的时候从 job pool 中获得任务元信息。
5. 监测任务的合法性如果已经删除则 pass。继续轮询。如果任务合法则再次计算时间
6. 如果合法则计算时间，如果时间合法：根据 topic 将任务放入对应的 ready queue，然后从 bucket 中移除。如果时间不合法，则重新计算时间再次放入 bucket，并移除之前的 bucket 中的内容
7. 消费端轮询对应 topic 的 ready queue。获取 job 后做自己的业务逻辑。与此同时，服务端将已经被消费端获取的 job 按照其设定的 TTR，重新计算执行时间，并将其放入 bucket。
8. 完成消费后，发送 finish 消息，服务端根据 job id 删除对应信息。

用户任务池延时任务时间循环待完成任务提交任务提交延时任务轮询任务任务已经到达时间用户领取任务设置其完成超时时间, 然后保存进延时任务中任务超时任务完成或者任务删除检测到任务不存在队列中移除用户任务池延时任务时间循环待完成任务

对象

我们现在可以了解到中间存在的几个组件

1. 延迟队列，为 Redis 延迟队列。实现消息传递
2. Job pool 任务池保存 job 元信息。根据文章描述使用 K/V 的数据结构，key 为 ID，value 为 job
3. Delay Bucket 用来保存业务的延迟任务。文章中描述使用轮询方式放入某一个 Bucket 可以知道其并没有使用 topic 来区分，个人这里默认使用顺序插入
4. Timer 时间组件，负责扫描各个 Bucket。根据文章描述存在多个 Timer，但是同一个 Timer 同一时间只能扫描一个 Bucket
5. Ready Queue 负责存放需要被完成的任务，但是根据描述根据 Topic 的不同存在多个 Ready Queue。

其中 Timer 负责轮询，Job pool、Delay Bucket、Ready Queue 都是不同职责的集合。

任务状态

• ready：可执行状态，
• delay：不可执行状态，等待时钟周期。
• reserved：已被消费者读取，但没有完成消费。
• deleted：已被消费完成或者已被删除。

对外提供的接口

接口	描述	数据
add	添加任务	Job 数据
pop	取出待处理任务	topic 就是任务分组
finish	完成任务	任务 ID
delete	删除任务	任务 ID

额外的内容

1. 首先根据状态状态描述，finish 和 delete 操作都是将任务设置成 deleted 状态。
2. 根据文章描述的操作，在执行 finish 或者 delete 的操作的时候任务已经从元数据中移除，此时 deleted 状态可能只存在极短时间，所以实际实现中就直接删除了。
3. 文章中并没有说明响应超时后如何处理，所以个人现在将其重新投入了待处理队列。
4. 文章中因为使用了集群，所以使用 redis 的 setnx 锁来保证多个时间循环处理多个桶的时候不会出现重复循环。这里因为是简单的实现，所以就很简单的每个桶设置一个时间队列处理。也是为了方便简单处理。关于分布式锁可以看我之前的文章里面有描述。

实现

现在我们根据设计内容完成设计。这一块设计我们分四步完成

任务及相关对象

目前需要两个对象，一个是任务对象（job）一个负责保存任务引用的对象（delay job）

任务对象

@Data
@AllArgsConstructor
@NoArgsConstructor
public class Job implements Serializable {

    /**
     * 延迟任务的唯一标识，用于检索任务
     */
    @JsonSerialize(using = ToStringSerializer.class)
    private Long id;

    /**
     * 任务类型（具体业务类型）
     */
    private String topic;

    /**
     * 任务的延迟时间
     */
    private long delayTime;

    /**
     * 任务的执行超时时间
     */
    private long ttrTime;

    /**
     * 任务具体的消息内容，用于