业务流程
首先我们分析下这个流程
- 用户提交任务。首先将任务推送至延迟队列中。
- 延迟队列接收到任务后,首先将任务推送至job pool中,然后计算其执行时间。
- 然后生成延迟任务(仅仅包含任务id)放入某个桶中
- 时间组件时刻轮询各个桶,当时间到达的时候从job pool中获得任务元信息。
- 监测任务的合法性如果已经删除则pass。继续轮询。如果任务合法则再次计算时间
- 如果合法则计算时间,如果时间合法:根据topic将任务放入对应的ready queue,然后从bucket中移除。如果时间不合法,则重新计算时间再次放入bucket,并移除之前的bucket中的内容
- 消费端轮询对应topic的ready queue。获取job后做自己的业务逻辑。与此同时,服务端将已经被消费端获取的job按照其设定的TTR,重新计算执行时间,并将其放入bucket。
- 完成消费后,发送finish消息,服务端根据job id删除对应信息。
对象
我们现在可以了解到中间存在的几个组件
- 延迟队列,为Redis延迟队列。实现消息传递
- Job pool 任务池保存job元信息。根据文章描述使用K/V的数据结构,key为ID,value为job
- Delay Bucket 用来保存业务的延迟任务。文章中描述使用轮询方式放入某一个Bucket可以知道其并没有使用topic来区分,个人这里默认使用顺序插入
- Timer 时间组件,负责扫描各个Bucket。根据文章描述存在多个Timer,但是同一个Timer同一时间只能扫描一个Bucket
- Ready Queue 负责存放需要被完成的任务,但是根据描述根据Topic的不同存在多个Ready Queue。
其中Timer负责轮询,Job pool、Delay Bucket、Ready Queue都是不同职责的集合。
任务状态
- ready:可执行状态,
- delay:不可执行状态,等待时钟周期。
- reserved:已被消费者读取,但没有完成消费。
- deleted:已被消费完成或者已被删除。
对外提供的接口
额外的内容
- 首先根据状态状态描述,finish和delete操作都是将任务设置成deleted状态。
- 根据文章描述的操作,在执行finish或者delete的操作的时候任务已经从元数据中移除,此时deleted状态可能只存在极短时间,所以实际实现中就直接删除了。
- 文章中并没有说明响应超时后如何处理,所以个人现在将其重新投入了待处理队列。
- 文章中因为使用了集群,所以使用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;
/**
* 任务具体的消息内容,用于处理具体业务逻辑用
*/
private String message;
/**
* 重试次数
*/
private int retryCount;
/**
* 任务状态
*/
private JobStatus status;
}
任务引用对象