这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记
本篇文章分为四部分
（一）前言
（二）实现原理
（三）业务应用
1.前言
春节瓜分红包项目：用户集卡，开奖时对集齐卡片的用户发放随机红包。
简要流程：系统用脚本扫描集卡信息，汇总用户数据（MapReduce任务），计算用户获得的金额然后发放红包（Map任务）。
难点：亿级用户规模、亿级资金规模、百万级读写QPS。
自动化+定时执行+海量数据+高效稳定=分布式定时任务
2.实现原理
2.1 核心架构
分布式定时任务核心要解决触发、调度、执行三个关键问题。
- 触发器：Trigger，解析任务，生成触发事件。
- 调度器：Scheduler，分配任务，管理任务生命周期。
- 执行器：Executor，获取执行任务单元，执行任务逻辑。
除此之外，还需要提供一个控制台（Admin），提供任务管理和干预功能。
2.1.1 数据流
用户将 任务基础信息（创建人等），触发规则（定时、延迟、周期），任务代码发送给控制台。控制台将其存入任务数据库。触发器触发任务执行并调用调度器对任务进行协调与分配。最后执行器执行任务。
2.1.2 功能架构
| 组件 | 功能 |
|---|---|
| 控制台Admin | 元数据存储、元数据状态流转、任务分片、任务依赖、规则引擎、任务暂停/恢复、日志管理、监控报警、指标统计...... |
| 触发器Trigger | 解析引擎、Scanner、可靠投递（可能用到MQ）、状态流转、补偿策略 |
| 调度器Scheduler | 调度、负载均衡、幂等控制、容错、故障转移、限流、计费、优雅启停、状态管控...... |
| 执行器Executor | 注册、任务获取、任务执行、状态上报、日志处理、本地幂等、任务回调...... |
2.2 控制台
2.2.1 基本概念
名词解释：
- 任务：job，任务元数据。
- 任务实例：jobinstance，任务运行的实例。
- 任务结果：jobresult，任务实例的运行结果。
- 任务历史：jobhistory，用户可以修改任务信息，任务实例对应的任务元数据可
对应关系：
- 任务与任务实例是一对多的关系。因为任务能执行多次。
- 任务实例和任务结果是一对多的关系。因为任务可能失败，需要重试。
- 任务和任务历史是一对多的关系。记录用户对任务元数据的修改日志。
2.3.2 任务元数据
任务元数据是用户对任务的属性定义，包括任务类型调度时机、执行行为等。
Job：{基础信息（Who，任务名，属于什么业务），调度时机（When，什么时间调度），执行行为（What，要做什么事情），执行方式（How，单机、广播分片）}
2.2.3 任务实例
任务实例是一个确定的job的一次运行实例。
JobInstance：{Job_id（与元数据建立关联，记录是哪个任务的实例），触发时间（预期何时执行，实际上何时执行），状态&结果，过程信息（记录执行路径，可以进行消息追回）}
2.3 触发器
2.3.1 核心职责
给定一系列任务，解析它们的触发规则，在规定的时间点触发任务的调度。
设计约束：
- 需支持大量任务。
- 需支持秒级（精确）的调度。
- 周期任务需执行多次，需要计算执行时间。
- 需保证秒级扫描的高性能，并避免资源浪费。
2.3.2 方案1
定时扫描+延时消息（腾讯、字节方案）
Scanner周期性扫描db，将需要执行的任务传给消息队列。由于存在延迟，所以扫描时提前将任务取出，发送延时消息（如10分钟后执行某任务）。为了避免重复执行任务，要对db中的数据修改，避免下次扫描又被取出。
2.3.3 方案2
时间轮（Quartz方案）
时间轮是一种高效利用线程资源进行批量化调度的一种调度模型。时间轮是一个存储环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表。
目标：遍历任务列表，从中找出当前时间点需触发的任务列表。
- 使用链表存储任务，每个元素代表一个任务。查询复杂度O(n)，修改复杂度O(1)。
- 由于不需要知道全部任务什么时候执行，而是知道最先执行的任务即可。因此考虑使用最小堆存储任务，按执行时间排序，每个节点存储同执行时间的任务的列表。查询复杂度O(1)，修改复杂度O(logn)。此方法仍然有缺点，因为最小堆实际上是一个数组，而执行时间不同的任务要被存放在不同的节点里，所以当任务量大且任务执行时间各不相同时，最小堆将是一个无限扩大的数组。
- 使用时间轮（像是一个时钟）存储任务，每个节点存储同执行时间的任务的列表。查询复杂度O(1)，修改复杂度O(1)。缺点是一个时钟可能只有60个刻度（记录每秒要执行的任务），如果一个任务在一分钟后执行，则在任务中加入一个count标致，每次经过任务时count减1，当count等于0时执行任务。
- 使用多级时间轮存储任务，上级时间轮转过对应刻度后把任务塞入下级时间轮中。如任务距离下次执行1时5分0秒，则它被插入小时时间轮。当小时时间轮指到1时，将所有1时的任务插入到分钟时间轮。这个任务被插入到5分处，而此时分的指针指在0的位置。同理，5分钟后它被插入到0秒的位置然后直接被触发器送进消息队列等待调度器调度。
2.3.4 高可用
核心问题：不同业务之间，任务的调度相互影响怎么办（业务A占用过多资源导致业务B无资源可用）？负责扫描和触发的机器挂了怎么办？
解法思路：
- 存储上不同地区不同业务做资源隔离。
- 运行上不同地区不同业务分开执行。
- 部署时采用多机房集群化部署，避免单点故障，通过数据库锁或分布式锁保证任务只被触发一次。
单trigger模式会有单点故障，机器故障时平台崩溃。trigger集群模式可避免单点故障，需要避免同一任务被多次触发导致业务紊乱。
防止业务紊乱的方法：在触发调度之前，更新数据库中JobInstance的状态（行级锁），成功抢锁的trigger才会触发调度。缺点是多台机器频繁竞争数据库锁，节点越多性能越差。
也可以使用分布式锁的方式，在触发调度之前，尝试抢占分布式锁，可使用Redis锁或Zookeeper锁。性能较高，多家公司使用此方案。
2.4 调度器
要解决的问题：资源来源（机器注册）、资源调度（调度算法）、执行任务
2.4.1 资源来源
-
由业务系统提供及其资源（阿里、美团、字节等）
- 优点：任务执行逻辑与业务系统公用一份资源，利用率更高。
- 缺点：更容易发生定时任务脚本影响在线服务的事故（因为平时的流量较为均匀而定时任务往往会触发大量的并发任务）。不能由定时任务平台控制扩缩容。
-
定时任务平台提供机器资源（字节等）
- 优点：任务执行逻辑与业务系统提供的在线服务隔离，避免相互影响。可以支持优雅的扩缩容。
- 缺点：消耗更多机器资源。需要额外为定时任务平台申请调用权限，而不能直接继承业务系统的权限。
相当于一个是自己要估算好需要的资源数，另一个是先建立一个云平台（资源足够）之后用户就不再考虑需要多少资源而是交给平台分配资源。
2.4.2 节点选择
- 随机节点执行：选择集群中一个可用的执行节点执行调度任务。适用场景：定时对账。
- 广播执行：在集群中所有的执行节点分发调度任务并执行。适用场景：批量运维。
- 分片执行：按照用户自定义分片逻辑进行拆分，分发到集群中不同节点并行执行，提升资源利用效率。适用场景：海量日志统计。
任务分片
通过任务分片可以提高任务执行的效率和资源的利用率。
- 将业务数据分段。假设有N个执行器，最好将业务分为k*N段（让每个执行器负载均匀）。
- 将任务通过单机任务的方式进行任务分片（用单机将任务拆分），然后通过Map任务把处理逻辑分配到N个执行器上。
- 前两步给每个执行器传输了数据与程序，执行器即可进行工作。
2.4.3 任务编排
由于子任务的执行会有依赖关系，因此可以使用有向无环图DAG（Directed Acyclic Graph）进行可视化任务编排，用户可以通过图形用户界面（拖拽图的节点与箭头）完成任务的编排，而不是让用户进行硬编码。
故障转移
确保部分执行单元任务失败时，任务最终成功（分片任务基于一致性hash策略分发任务，当某Executor异常时，调度器会对分配到这台机器上的任务进行rehash，将这些任务分发到其它Executor上）。
2.4.4 高可用
调度器可以集群部署，做到完全的无状态，靠消息队列的重试机制保障任务一定会被调度。
2.5 执行器
执行器是最后真正执行任务的组件，基于注册中心，可以做到执行器的弹性扩缩容（发现资源不够时再启动新的执行器并注册）。
- 执行器进行机器注册，让调度中心知道执行器的存在。
- 调度器发出调度请求之后执行器在自己的handler里执行任务流程。
- 执行器执行任务过程中，会向调度中心回传执行日志、回调请求。
- 任务执行中定时向调度中心进行状态上报（心跳检测），确保执行器故障时调度中心能及时感知，摘除故障执行器并将其任务分派给其它执行器。
3.业务应用
所有需要定时、延时、周期性执行的业务场景都可以考虑使用分布式定时任务。
电商
- 订单30分钟未付款自动关闭订单。
- 定时给商家、达人发送消息，给用户发放优惠券等。
互动
- 集五福、集卡片，瓜分红包。
游戏
- 活动结束后批量补发用户未领取的奖励。
- 定期更新游戏内排行榜。
其他解决方案
发货后超十天未收货时系统自动确认收货。
- 使用分布式定时任务的延时任务。
- 使用消息队列的延时消息或定时消息。
春节集卡活动统计完成集卡的用户个数和其奖励系数。
- 使用分布式定时任务的MapReduce任务。
- 使用大数据离线处理引擎Hive离线做统计。
- 使用大数据实时处理引擎Flink实时做累计。
方案对比
| 时效性 | 可控性 | 简洁性 | 主要缺点 | |
|---|---|---|---|---|
| 分布式定时任务 | 秒级 | 高 | 高 | - |
| 单机定时任务 | 秒级 | 高 | 高 | 无法支撑很大业务体量 |
| (消息队列)延时消息 | 实时 | 低 | 中 | 在任务有变化时，已发送的延时消息（延时消息要提前发送）不便于做变更 |
| 离线计算 | 小时级 | 中 | 高 | 延时过高，至少小时级 |
| (flink等)实时计算 | 秒级 | 高 | 中（可能要学新语言语法） | 仅能做数据处理，无法调用HTTP/RPC请求完成业务逻辑处理 |
到这里就先结束啦!
翻过这座山，他们就会听到你的故事！加油！
