这是我参与「第五营」笔记创作活动的的第15天。
分布式定时任务那些事儿（下）
实现原理
整体架构
核心架构
分布式定时任务核心要解决触发、调度、执行三个关键问题
- 触发器: Trigger，解析任务，生成触发事件
- 调度器: Scheduler，分配任务，管理任务生命周期
- 执行器: Executor，取执行任务单元，执行任务逻辑
除此之外，还需要提供一个控制台(Admin)，提供任务管理和干预的功能。
数据流
功能架构
控制台Admin
任务元数据：Job，是用户对任务属性定义，包括任务类型调度时机、执行行为等。
任务实例: JobInstance，是一个确定的Job的一次远行实例。
任务结果: JobResult，任务实例运行的结果。
任务历史: JobHistor，用户可以修改任务信息，任务实例对应的任务元数据可以不同，因而使用任务历史存储。
触发器Trigger
核心职责：给定一系列任务，解析它们的触发规则，在规定的时间点触发任务的调度。
设计约束：
- 需支持大量任务
- 需支持秒级的调度
- 周期任务需要多次执行
- 需保证秒级扫描的高性能，并避免资源浪费
方案1
定期扫描+延时消息（腾讯、字节方案）
方案2
时间轮（Quartz所用方案）
时间轮是一种高效利用线程资源进行批量化调度的一种调度模型。时间轮是采用数组实现，数组中的每个元素可以存放一个定时任务列表。
目标: 遍历任务列表，从中找出当前时间点需触发的任务列表
高可用
核心问题
- 不同业务之间，任务的调度相互影响怎么办?
- 负责扫描和触发的机器挂了怎么办?
解法思路
- 存储上，不同国别、业务做资源隔离
- 运行时，不同国别、业务分开执行
- 部署时，采用多机房集群化部署，避免单点故障，通过数据库锁或分布式锁保证任务只被触发一次
问题引出
数据库行锁模式：在触发调度之前，更新数据库中JobInstance的状态，成功抢锁的才会触发调度。多台机器频繁竞争数据库锁，节点越多性能越差。
分布式锁模式：在触发调度之前，尝试抢占分布式锁，可使用Redis或Zookeeper锁。性能较高，多家公司使用此方案。
调度器Scheduler
资源来源
资源调度
节点选择
- 随机节点执行: 选择集群中一个可用的执行节点执行调度任务。适用场景: 定时对账。
- 广播执行: 在集群中所有的执行节点分发调度任务并执行。适用场景: 批量运维。
- 分片执行: 按照用户自定义分片逻辑进行拆分，分发到集群中不同节点并行执行，提升资源利用效率。适用场景: 海量日志统计。
任务分片：通过任务分片来提高任务执行的效率和资源的利用率。
- N个执行器Executor，M个业务数据区段，最好MN，且M是N的整数倍
高级特性
任务编排：使用有向无环图 DAG(Directed Acyclic Graph) 进行可视化任务编排。
故障转移：确保部分执行单元任务失败时，任务最终成功。
- 分片任务基于一致性hash策略分发任务，当某Executor异常时，调度器会将任务分发到其他Executor
调度器
调度器可以集群部署，做到完全的无状态，靠消息队列的重试机制保障任务一定会被调度。
执行器Executor
任务应用
所有需要定时、延时、周期性执行任务的业务场景，都可以考虑使用分布式定时任务。
电商
- 订单30分钟未付款自动关闭订单
- 定时给商家、达人发送消息，给用户发放优惠券等
互动
- 支付宝集五福
- 字节春节集卡瓜分红包
游戏
- 活动结束后批量补发用户未领取的奖励
- 定期更新游戏内榜单
其他解决方案
发货后超过10天未收货时系统自动确认收货
- 使用分布式定时任务的延时任务
- 使用消息队列的延时消息或者定时消息
春节集卡活动统计完成集卡的用户个数和总翻倍数
- 使用分布式定时任务的MapReduce任务
- 使用大数据离线处理引擎Hive离线做统计
- 使用大数据实时处理引擎Flink实时做累计
| 时效性 | 可控性 | 简洁性 | 主要缺点 | |
|---|---|---|---|---|
| 分布式定时任务 | 秒级 | 高 | 高 | - |
| 单机定时任务 | 秒级 | 高 | 高 | 无法支撑很大业务体量 |
| 延时消息 | 实时 | 低 | 中 | 在任务有变化时，已发送的延时消息不便于做变更 |
| 离线计算 | 小时级 | 中 | 高 | 时延至少小时级 |
| 实时计算 | 秒级 | 高 | 中 | 仅能做数据处理，无法调用HTTP/RPC请求完成业务逻辑处理 |
