分布式定时任务(二)｜青训营笔记

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

1. 概述

我将主要介绍如下知识点：

1. 分布式定时任务实现原理
2. 分布式定时任务业务应用

2. 实现原理

2.1 核心架构

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

• 触发器：Trigger，解析任务，生成触发事件
• 调度器：Scheduler，分配任务，管理任务生命周期
• 执行器：Executor，获取执行任务单元，执行任务逻辑

除此之外，还需要一个控制台(Admin) ，提供任务管理和干预的功能

2.2 控制台 Admin

基本概念：

• 任务：Job，任务元数据

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

  

• 任务实例：JobInstance，任务运行的实例

  

• 任务结果：JobResult，任务实例运行的结果

• 任务历史：JobHistory，用户可以修改任务信息，任务实例对应的任务元数据可以不同，因而使用任务历史存储

2.3 触发器 Trigger

2.3.1 核心职责

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

2.3.2 设计约束

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

2.3.3 实现方案

• 方案一：

  • 定期扫描 + 延时消息 (腾讯、字节方案)

• 方案二：

  • 时间轮 (Quartz 所用方案)

  时间轮是一种高效利用线程资源进行批量化调度的一种调度模型

  时间轮是一个存储环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表

2.3.4 高可用

• 核心问题：

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

• 解法思路：

  • 存储上，不同国别、业务做资源隔离

  • 运行时，不同国别、业务分开执行

  • 部署时，采用多机房集群化部署，避免单点故障，通过数据库锁或分布式锁保证任务只被触发一次

    数据库行锁模式(节点越多性能越差)：在触发调度之前，更新数据库中 JobInstance 的状态，成功抢锁的才会触发调度

    分布式锁模式(性能较高)：在触发调度之前，尝试抢占分布式锁，可用 Redis 锁或 Zookeeper 锁

2.4 调度器

2.4.1 资源来源

业务系统提供机器资源：

• 优点：
  • 任务执行逻辑与业务系统共用同一份资源，利用率更高
• 缺点：
  • 更容易发生定时任务脚本影响在线服务的事故
  • 不能由定时任务平台控制扩缩容

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

• 优点：
  • 任务执行逻辑与业务系统提供的在线服务隔离，避免相互影响
  • 可以支持优雅地扩缩容
• 缺点：
  • 消耗更多机器资源
  • 需要额外为定时任务平台申请接口调用权限，而不能直接继承业务系统的权限

2.4.2 资源调度

节点选择：

• 随机节点执行：

  • 选择集群中一个可用的执行节点执行调度任务。
  • 适用场景：定时对账

• 广播执行：

  • 在集群中所有的执行节点分发调度任务并执行。
  • 适用场景：批量运维

• 分片执行：

  • 按照用户自定义分片逻辑进行拆分，分发到集群中不同节点并行执行，提升资源利用效率。
  • 适用场景：海量日志统计

任务编排：

• 使用有向无环图 DAG(Directed Acyclic Graph) 进行可视化任务编排

故障转移：

• 确保部分执行单元任务失败时，任务最终成功

2.4.3 高可用

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

2.5 执行器

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

  注册、调度、回调、心跳检测

3. 业务应用

3.1 业务领域

• 电商
• 互动
• 游戏

3.2 其它解决方案对比

	时效性	可控性	简洁性	主要缺点
分布式定时任务	秒级	高	高	-
单机定时任务	秒级	高	高	无法支撑很大业务体量
延时消息	实时	低	中	在任务有变化时，已发送的延时消息不便于做变更
离线计算	小时级	中	高	时延至少小时级
实时计算	秒级	高	中	仅能做数据处理，无法调用 HTTP/RPC 请求完成业务逻辑处理

4. 总结

所有需要定时、延时、周期性执行任务的业务场景，都可以考虑使用分布式定时任务！

参考：

• 字节内部课：分布式定时任务实现原理