这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天
常见框架
- xxl-job
- SchedulerX 2.0
- TCT
分布式定时任务的实现原理
核心架构
三个核心问题
- 触发
- 调度
- 执行
触发器：解析任务，生成触发事件 调度器：分配任务，管理任务声明周期 执行器：获取任务单元，执行任务逻辑 除此之外还需要Admin来管理任务
基本概念
- 任务：Job，任务元数据
- 任务实例：Joblnstance，周期任务会生成多个任务实例
- 任务结果：JobResult，任务实例运行的结果
- 任务历史：JobHistory，用户可以修改任务信息，任务实例对应的任务元数据可以不同，因而使用任务历史存储
任务元数据
- 基础信息
- 调度时机
- 执行行为
- 执行方式
任务示例
- job id
- 触发时间
- 状态&结果
- 过程信息
触发器
核心职责
给定一系列任务，解析它们的触发规则，在规定的时间点触发任务的调度
设计约束
- 需支持大量任务
- 需支持秒级的调度
- 周期任务需要多次执行
- 需保证秒级扫描的高性能，井避免资源浪费
设计方案1
定期扫描+延时消息
设计方案2
时间轮（Quartz方案） 时间轮是一种高效利用线程资源进行批量化调度的一种调度模型。时间轮是一个存储环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表。
解析
目标：遍历任务列表，从中找出当前时间需要触发的任务
- 使用链表存储任务，每个元素代表一个任务，查询复杂度O(n)，修改复杂度O(1）
- 使用最小堆存储任务，按执行时间排序，每个节点存储同执行时间任务列表,查询复杂度O(1)，修改复杂度O(logn)
不需要知道所有的任务什么时候执行，只需要知道最近要执行的任务什么时候执行->最小堆
- 使用时间轮存储任务，每个节点存储同执行时间任务列表 每个位置是当前时间需要执行的任务列表 查询复杂度O(1)，修改复杂度O(1）
如果刻度不够用，可以在刻度中增加count来计数，时间轮转过几次才执行
- 使用多级时间轮存储任务，上一级时间轮转过对应刻度后把任务塞入下级时间轮中（时轮，分轮，秒轮）
高可用
核心问题
- 不同业务之间，任务的调度相互能响怎么办？
- 负责扫描和触发的机器挂了怎么办？
问题引出
单Trigger模式，机器故障时平台崩溃 Trigger 集群模式：需要避免同一个任务多次触发
数据库行锁模式
多Trigger抢锁，抢锁成功才调度 缺点是，多节点竞争数据库所，节点变多性能差
分布式锁
抢分布式锁（redis锁，zookeeper锁）
调度器
业务系统提供机器资源
优点：
- 任务执行逻辑与业务系统共用同一份资源利用率更高
缺点：
- 更容易发生定时任务脚本影响在线服务的 事故
- 不能由定时任务平台控制扩缩容
定时任务平台提供机器资源
优点：
- 任务执行逻輯与业务系统提供的在线服务隔离，避免相互影响
- 可以支持优雅地扩缩容
缺点：
- 消耗更多机器资源
- 需要额外为定时任务平台申请接口调用权限，而不能直接继承业务系统的权限
节点选择
随机节点选择执行
性能低
广播执行
适用于批量运维
分片执行
- 把任务用单机任务的形式，分片
- 把任务分到不同的机器
任务编排
使用有向无环图
执行器
基于调度中心
- 执行器，机器注册
- 调度器，调度请求
- 执行器，发日志
- 执行器，回调请求
- 执行器的状态上报
