Skip to content
zywaited edited this page Aug 26, 2020 · 1 revision

A: 大致精度

目前配置的时间刻度是秒级别

B: 访问

BA: HTTP

类型 方法 方式
添加任务 /task/add POST
删除任务 /task/remove POST、DELETE
查询任务 /task/get GET

BB: GRPC

尽量不使用,线上可能会关闭该协议,因为对于延迟任务不会频繁请求,长连接意义不太大

1: 添加任务

1.1: 参数说明(json)

字段 类型 是否必须 说明
name string 业务名称
args string 业务自定义数据(尽量不要传输复杂逻辑,业务方自行存储)
time object(json) 执行时间
time.duration nt 执行时间戳(如果是相对则是延迟时间)
time.relative Bool 是否是相对时间(如果是相对时间,那么真正执行时间为NOW()+duration)
callback object(json) 回调路径(如果是HTTP,uri为schema+address+path)
callback.schema tring 协议: 支持http:https:grpc
callback.address string 地址(域名或者ip+port)
callback.path string 路径

1.2: 返回值(json)

字段 类型 说明
uid string 任务唯一标识(根据传入参数计算,相对时间会转为绝对时间计算,尽量都用绝对时间)

2: 回调

2.1: 参数(json)

字段 类型 是否必须 说明
uid string 与添加任务返回值一致
name string 与添加任务参数name一致
args string 与添加任务参数args一致
url string 拼接的回调地址

2.2: HTTP

返回值参考2.1,回调只能是POST方式

2.3: GRPC

3 任务检测

  • 目前配置的最大检测次数是8次
  • 每次回调配置次数是3次

3.1 回调

  • 2次重试回调的时间:2,4 (s)
  • 回调HTTP必须是返回的状态码为<400才算成功, GRPC不返回err即可
  • 如果回调失败会钉钉报警(除却1-2次(执行效率问题),后续的报警都是5分钟以后)

3.2 检测

  • 实际检测次数会比配置多一次,比如配置8次,实际检测是9次,最后一次不进入队列,只是为了确认任务是否回调成功,没有成功就打印日志并且去除当前任务(防止无效任务过多)

每次检测延后执行时间

  • 1-3:15、30、60 (s)
  • 4-6:15、30、60 (m)
  • 7-9:4、8、12 (h)
  • >=10:1 (d)