背景

如今的互联网应用中充斥着大量的任务，这些任务往往体量大、实时性要求高，单机难以完成任务的处理。而随着微服务化架构的逐步演进，逐渐演进出了分布式任务调度系统，解决了大批量任务的调度与执行问题。

什么时候需要分布式任务？

1、每天饭点的时候向所有订阅的工作群发送饭点通知。如何在短时间内找到所有需要的群聊，完成通知的发送？

2、有大量的视频/图片需要转码，且它们对应着不同的业务线和下游转码队列，如何合理的管理这一系列任务的调度和执行？

3、有上万张照片需要处理，处理若干小时后后再给用户回调，如何保证任务的成功执行，数据不丢失？

类似于这种：1、基于准确的时刻或者固定的时间间隔触发的任务；2、有批量数据需要处理；3、要实现两个动作解耦的场景；我们都可以用分布式任务来实现。

任务定义

任务类型

根据任务的特点，可以将分布式任务大概可以分为以下四种类型：

• 单机任务：随机触发一台机器执行任务，适用于计算量小、并发度低的任务
• 广播任务：广播到所有机器上执行同一个任务，比如所有机器一起清理日志
• Map任务：一个任务可以分出多个子任务，每个子任务负责一部分的计算。适用于计算量大，单机无法满足要求的任务
• MapReduce任务：在Map任务的基础上，还可以对所有子任务的结果做汇总计算，适用于计算量大，并需要对子任务结果做汇总的任务

基本概念

• 任务(Job)：任务元数据，其中主要包括：基础信息：任务的原信息调度时机：什么时机触发任务执行行为：任务的行为是什么，需要通过代码定义执行方式：如何执行，单机任务 or 广播任务 or map任务 or map reduce任务
• 任务实例(JobInstance)：任务运行的一个实例，代表任务的一次执行。其中主要包括Job_id、触发时间、执行状态、执行结果、过程信息等。
• 任务结果(JobResult)：任务实例运行的结果（任务实例可能在执行时失败，并重试）
• 任务历史(JobHistory)：用户可以修改任务信息，任务实例对应的任务元数据可以不同，因此使用任务历史存储

核心架构

分布式任务核心要解决触发、调度、执行三个问题，除此之外还需要提供一个控制台

• 触发器(Trigger)：解析任务，生成触发事件，保证任务在合适的时机被触发
• 调度器(Scheduler)：分配任务，管理任务生命周期，面对多种下游资源如何进行合理地调度
• 执行器(Executor)：获取执行任务单元，执行任务逻辑
• 控制台(Admin)：提供执行任务管理和干预的功能

运行流程

分布式任务调度平台运行的大致流程为：

1. 用户首先把任务的基础信息（who）、触发规则（when）、任务代码（what）在控制台中配置好，控制台会将以上的信息存入DB中
2. Trigger会判断任务应该在什么时机去执行，在需要执行的时候进行任务的触发
3. Scheduler会对任务做整体的协调，决定任务的执行方式和资源分配
4. Executor收到执行通知后，进行任务的执行

触发器

触发方式

定时扫描

1. Trigger中有扫描器负责定时扫描，判断是否有任务满足触发条件
2. 将满足触发条件的任务发送到MQ中，若任务不需立刻执行则可以使用延时队列
3. 修改DB中任务的状态，防止任务被重复触发
4. Scheduler进行任务调度

时间轮算法

时间轮 是一种 实现延迟功能（定时器） 的 算法。如果一个系统存在大量的任务调度，时间轮可以高效的利用线程资源来进行批量化调度。把大批量的调度任务全部都绑定在时间轮上，通过时间轮进行所有任务的管理，触发以及运行。能够高效地管理各种延时任务，周期任务，通知任务等。

时间轮（TimingWheel）是一个 存储定时任务的环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表。定时任务列表是一个链表，链表中的每一项表示的都是定时任务项，其中封装了真正的定时任务。时间轮结构中有一个代表当前时间的指针（currentTime），定时器每超时一次，就把当前指针指向环形队列的下一个格子，并执行对应时间内任务列表中的任务。

时间轮算法的查询复杂度、修改复杂度均为O(1)。

上图所展示的时间轮，可以表示一分钟内每一秒所对应的任务。但是如果设置一个3分48秒后触发的任务，已经超出了该时间轮所能表示的范围，需要怎么处理呢？有多种思路：

• 对任务增加round字段，指针每扫过一次就将round减1，代表时间已经过去了一分钟，当round变为0时就需要对任务进行执行
• 多级时间轮：多层时间轮分别代表时、分、秒。通过时间轮的升、降级来表示更大尺度的时间跨度。 假设我们的任务需要在每天的 6:20:40 秒执行一次。由于时间执行时间大于秒级和分钟级的时间轮，所以任务首先将添加于小时级的第6号刻度上。当其轮询指针访问到第6号刻度时，就将此任务转移到分钟级别时间轮的第20号刻度上。当分钟级的时间轮指针访问到第20号刻度时，就将此任务转移到秒级别时间轮的第40号刻度上。当秒级别时间轮指针访问到第40号刻度时，会将任务交给异步线程负责执行，然后将任务再次注册到小时级别的时间轮中。

其他

针对不同的业务场景也会存在很多其他触发规则，比如根据下游资源的拥塞情况进行触发等。

高可用

不同业务、场景之间的触发如何避免互相影响？

1. 存储上，可以根据国家、场景等做资源隔离
2. 运行时，可以将不同国家、场景分开执行

如何避免单点故障、任务重复触发？

可以通过部署多个Trigger实例来避免单点故障，但同时需要保证任务不会被重复触发

• 数据库行锁：触发任务前更新数据库中任务实例的状态，若更新成功则进行调度，抢锁失败则放弃调度。但是数据库瓶颈较低
• 分布式锁：通过Redis/ZooKeeper实现分布式锁，从而避免重复触发

调度器

资源调度策略

单个调度器所能调度的执行器往往不是单一的，对于不同的任务应该选择的调度策略大概可以分为以下几类：

• 随机节点执行：随机选择集群中一个可用的节点执行调度任务。
• 广播执行：向集群中所有节点分发调度任务并执行。
• 分片执行：按照一定的逻辑对任务进行拆分，并分发到集群中不同的节点并行执行，该方式可以提高执行效率和资源利用率。分片任务通常基于一致性hash策略分发任务

重试策略

Executor的执行并不是完全可靠的，因此在任务调度失败后，如何进行重试就显得尤为重要。

• 如果Scheduler是通过hash的方式进行任务分配，则调度失败后可以通过rehash的方式实现任务的重试
• 如果通过MQ的方式进行任务分配，则可以通过重发任务消息的方式进行重试

执行器

总结

本文介绍了分布式任务调度系统的整体架构设计，并对其核心组成：触发器、调度器、执行器、控制台分别做了介绍。在工作中，很多系统其实都可以借鉴分布式任务调度系统的设计思路，希望本文所提到的一些内容在大家今后的架构设计中能够有所助益。