这是我参与「第五届青训营 」伴学笔记创作活动的第15天

前言

了解完分布式定时任务的发展历程之后，笔者来学习分布式定时任务的实现原理，本文是分布式定时任务实现原理的笔记，参考于课程资料。

实现原理

核心架构

分布式定时任务核心要解决触发、调度、执行三个关键问题。

• 触发器：Trigger，解析任务，生成触发事件。
• 调度器：Scheduler，分配任务，管理任务生命周期。
• 执行器：Executor，获取执行任务单元，执行任务逻辑。
• 控制台： Admin，提供任务管理和干预的功能。

数据流

功能架构

控制台基本概念

• 任务：Job，任务单元数据。
• 任务实例：JobInstance,周期任务会生成多个任务实例
• 任务结果：JobResult，任务实例运行的结果。
• 任务历史：JobHistory,用户可以修改任务信息，任务实例对应的任务单元数据可以不同，因而使用任务历史存储。

任务单元数据

任务单元数据是用户对任务的属性定义，包括任务类型调度时机，执行行为等。

任务实例

任务实例是一个确定的Job的一次运行实例。

触发器

核心职责：

• 给定一系列任务，解析它们的触发规则，在规定时间点触发任务的调度。

设计约束：

• 需要大量任务。
• 需要支持秒级别的调度。
• 周期任务需要多次执行。
• 需要保证秒级扫描的高性能，并避免浪费资源。

方案1

定时扫描+延时消息（腾讯、字节方案）

方案2

时间轮（Quartz所用方案）

时间轮是一种高效（查询和修改的复杂度都是O(1)）利用线程资源进行批量化调度的一种调度模型，时间轮是一个存储环形队列，底层采用数组实现，数组中的每一个元素可以存放一个定时任务列表。

高可用

核心问题：

• 不同业务之间，任务的调度相互影响怎么办？
• 负责扫描和触发的机器挂了怎么办？

解决思路：

• 存储上，不同的业务做资源隔离。
• 运行时，不同的业务分来执行。
• 部署时，采用多机房集群化部署，避免单点故障，通过数据库锁或分布式锁保证任务只被触发一次。

高可用-问题引出

单Trigger模式：会有单点故障，机器故障时平台崩溃。

Trigger集群模式：可避免单点故障，需要避免同一个任务多次触发导致业务紊乱。

高可用-数据库行锁模式

再触发调度之前，更新数据库中JobInstance状态，成功强锁的才会触发调度。

多台机器频繁竞争数据库锁，节点越多性能越差。

高可用-分布式锁模式

在触发器调度之前，尝试抢占分布式锁，可使用redis锁或者Zookeeper锁。

性能较高，多家公司使用此方案。

调度器

资源来源-业务系统提供机器来源

使用该方案的公司：

• 阿里、美团、字节等。

优点：

• 任务执行逻辑与业务系统共用同一份资源，利用率更高。

缺点：

• 更容易发生定时任务脚本影响在线服务的事故。
• 不能由定时任务平台控制扩缩容。

资源来源-定时任务平台提供机器资源

使用该方案的公司：

• 字节等。

优点：

• 任务执行逻辑与业务系统提供的在线服务隔离，避免相互影响。
• 可以支持优雅的扩缩容。

缺点：

• 消耗更多机器资源。
• 需要额外为定时任务平台申请接口调用权限，而不能直接继承业务系统的权限。

资源调度-节点选择

• 随机节点执行：选择集群中的一个可用的执行节点执行调度任务。适用场景：定时对账。
• 广播执行：在集群中所有的执行节点分发调度任务并执行。适用场景：批量运维。
• 分片执行：按照用户自定义分片逻辑进行拆分，分发到集群中不同节点并执行，提升资源利用率。适用场景：海量日志统计。

资源调度-任务分片

通过任务分片来提高执行效率和资源的利用率。

N个执行器Executor,M个业务数据区段，最好M>=N，且M是N的整数倍。

高级特性-任务编排

使用有向无环图进行可视化任务编排

高级特性-故障转移

保证部分执行单元任务失败，任务最终成功。

分片任务基于一致性hash策略发布任务，当Executor异常时，调度器会将任务分发到其他Executor上。

调度器-高可用

调度器可以集群部署，做到完全的无状态，靠消息队列的重试机制保障任务一定会被调度。

执行器

基于注册中心，可以做到执行器的弹性扩缩容。

小结（心得体会）

学习分布式定时任务的原理，可以让我考虑到更多的东西，或许可以借鉴该思想原理运用到其他地方上。

参考

• 字节跳动青训营《分布式定时任务》课程