一、背景需求
作为平台的基础服务之一，延迟任务都是必不可少的，它的作用主要是延迟，解决我们常遇到的订单定时关闭，自动上下架等业务需求。
由业务方来调用延迟任务通知服务，可以新增、编辑或删除任务，由延迟任务通知服务返回任务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"
}
]
