一、背景需求

作为平台的基础服务之一，延迟任务都是必不可少的，它的作用主要是延迟，解决我们常遇到的订单定时关闭，自动上下架等业务需求。

由业务方来调用延迟任务通知服务，可以新增、编辑或删除任务，由延迟任务通知服务返回任务ID。业务方可以主动查询任务的状态，是调度成功还是失败。

二、目标

• 1、支持任务的持久化
• 2、支持任务的失败重试
• 3、延迟回调的及时性，最大延迟不超过1秒
• 4、具备监控告警，能直观看出每个任务的执行情况，对回调异常的数据进行告警
• 5、不同的回调地址之间的任务执行互不影响，采用多个线程池隔离。

三、术语

1、任务

业务方需要在指定时间点，回调的接口及参数，被当做任务存储起来。类似于一个Postman的机器人，你事先告知它，你要在什么时间调用哪个接口，入参是什么。

• 一般是mysql/mongodb等数据库

2、冷缓存区

将回调时间是在当天的任务，抽离至某个存储区域，我们把这个区域，叫做冷缓存区。这个区域的要求是减少数据量，从而加速筛选出热数据的时间。与之相对的是热缓存区。见下。

我们会在每天的0点0时0分，把当天的任务放入冷缓存区。

• 可以是mysql/mongodb等数据库，也可以是redis内存数据库

3、热缓存区

热与冷相比较而言，是指回调时间将在最近N分钟后。我们把这样的数据从冷数据区抽离至热数据区。热数据的要求是遍历要快，除了数据量少之外，最好还是内存这样的介质，减少IO次数。

• 内存，至少是redis分布式的内存数据库，最好是JVM内存。
• 如果是JVM内存，需要面临并发重复执行的问题，怎么协调各个节点上的任务执行。好处是循环遍历，压力比redis要小得多。
• 如果是redis，由于是分布式的，不用考虑各节点之间的协调问题了，但是可能因为数据量大而导致大key，每N秒拉取一次的频率，还是会产生N秒的延迟。

四、数据的流转图

image.png

下面是以新增任务为示例的一个流程：

image.png

五、任务的状态机

image.png

六、数模设计

image.png

• “任务表”只有在任务执行成功的时候，才会归档至“任务归档表”
• 冷数据缓存区的有效期一般为24小时
• 热数据缓存区，每次拿取的任务如果是到了调度时间，那么就删除该任务。至于执行失败的任务，则会进入到下一次的重试流程。

七、主流程图

image.png

• 1、热数据缓存区，使用jvm内存存储，开启一个线程，循环读取待执行的任务列表。
• 2、需要考虑分布式环境下，多个节点之间的并发问题。这里我们采用的redis分布式锁，竞争锁失败的时候，采取快速失败的机制，不进行重试，既忽略执行。（说明其他节点已获取锁，已经在执行中）
• 3、在加入到线程池前，以及执行任务前，都要判断任务的状态是否已删除或已完成，忽略掉无需执行的任务。
• 4、为了并发执行任务，这里针对不同的Url地址，转入到不同的线程池。通过线程池隔离，做到不同的业务之间互不影响。
• 5、任务执行失败时，重试次数+1，并计算下次重试时间，建议这个重试时间是指数级的。然后更新任务的重试次数和下次重试时间。

八、接口设计

1、新增任务

支持批量新增，List<TaskDTO>

[
    {
        "content":"",
        "notifyUrl":"",
        "notifyTime":"",
    }
]

返回任务ID给业务方

1003

2、编辑任务

支持批量编辑，必须传入taskId。后面的删除和查询也一样。

[
    {
        "content":"",
        "notifyUrl":"",
        "notifyTime":"",
        "taskId":""
    }
]

返回成功还是失败

3、删除任务

传入多个任务ID，List<String> taskIds

["1003","2003"]

返回成功还是失败

4、查询任务

传入多个任务ID，List<String> taskIds

["1003","2003"]

返回任务的详情

[
    {
        "content":"",
        "notifyUrl":"",
        "notifyTime":"",
        "taskId":"1003"
    },
    {
        "content":"",
        "notifyUrl":"",
        "notifyTime":"",
        "taskId":"2003"
    }
]