五、总体设计

五、总体设计

5.1 源码目录介绍

1
2
3
4
5
6
7
8
9


1.  `-  /doc : 文档资料 `
2.  `-  /db :“调度数据库”建表脚本 `
3.  `-  /xxl-job-admin : 调度中心，项目源码 `
4.  `-  /xxl-job-core : 公共 Jar 依赖 `
5.  `-  /xxl-job-executor-samples : 执行器，Sample 示例项目（大家可以在该项目上进行开发，也可以将现有项目改造生成执行器项目）`


5.2 “调度数据库”配置

XXL-JOB 调度模块基于自研调度组件并支持集群部署，调度数据库表说明如下：

1
2
3
4
5
6
7
8
9
10
11
12


1.  `- xxl_job_lock：任务调度锁表；`
2.  `- xxl_job_group：执行器信息表，维护任务执行器信息；`
3.  `- xxl_job_info：调度扩展信息表：  用于保存 XXL-JOB 调度任务的扩展信息，如任务分组、任务名、机器地址、执行器、执行入参和报警邮件等等；`
4.  `- xxl_job_log：调度日志表：  用于保存 XXL-JOB 任务调度的历史信息，如调度结果、执行结果、调度入参、调度机器和执行器等等；`
5.  `- xxl_job_log_report：调度日志报表：用户存储 XXL-JOB 任务调度日志的报表，调度中心报表功能页面会用到；`
6.  `- xxl_job_logglue：任务 GLUE 日志：用于保存 GLUE 更新历史，用于支持 GLUE 的版本回溯功能；`
7.  `- xxl_job_registry：执行器注册表，维护在线的执行器和调度中心机器地址信息；`
8.  `- xxl_job_user：系统用户表；`


5.3 架构设计

5.3.1 设计思想

将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。

将任务抽象成分散的 JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的 JobHandler 中业务逻辑。

因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；

5.3.2 系统组成

  • 调度模块（调度中心）：
    负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块；
    支持可视化、简单且动态的管理调度信息，包括任务新建，更新，删除，GLUE 开发和任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器 Failover。
  • 执行模块（执行器）：
    负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效；
    接收“调度中心”的执行请求、终止请求和日志请求等。

5.3.3 架构图

5.4 调度模块剖析

5.4.1 quartz 的不足

Quartz 作为开源作业调度中的佼佼者，是作业调度的首选。但是集群环境中 Quartz 采用 API 的方式对任务进行管理，从而可以避免上述问题，但是同样存在以下问题：

  • 问题一：调用 API 的的方式操作任务，不人性化；
  • 问题二：需要持久化业务 QuartzJobBean 到底层数据表中，系统侵入性相当严重。
  • 问题三：调度逻辑和 QuartzJobBean 耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况下，此时调度系统的性能将大大受限于业务；
  • 问题四：quartz 底层以“抢占式”获取 DB 锁并由抢占成功节点负责运行任务，会导致节点负载悬殊非常大；而 XXL-JOB 通过执行器实现“协同分配式”运行任务，充分发挥集群优势，负载各节点均衡。

XXL-JOB 弥补了 quartz 的上述不足之处。

5.4.2 自研调度模块

XXL-JOB 最终选择自研调度组件（早期调度组件基于 Quartz）；一方面是为了精简系统降低冗余依赖，另一方面是为了提供系统的可控度与稳定性；

XXL-JOB 中“调度模块”和“任务模块”完全解耦，调度模块进行任务调度时，将会解析不同的任务参数发起远程调用，调用各自的远程执行器服务。这种调用模型类似 RPC 调用，调度中心提供调用代理的功能，而执行器提供远程服务的功能。

5.4.3 调度中心 HA（集群）

基于数据库的集群方案，数据库选用 Mysql；集群分布式并发环境中进行定时任务调度时，会在各个节点会上报任务，存到数据库中，执行时会从数据库中取出触发器来执行，如果触发器的名称和执行时间相同，则只有一个节点去执行此任务。

5.4.4 调度线程池

调度采用线程池方式实现，避免单线程因阻塞而引起任务调度延迟。

5.4.5 并行调度

XXL-JOB 调度模块默认采用并行机制，在多线程调度的情况下，调度模块被阻塞的几率很低，大大提高了调度系统的承载量。

XXL-JOB 的不同任务之间并行调度、并行执行。
XXL-JOB 的单个任务，针对多个执行器是并行运行的，针对单个执行器是串行执行的。同时支持任务终止。

5.4.6 过期处理策略

任务调度错过触发时间时的处理策略：

  • 可能原因：服务重启；调度线程被阻塞，线程被耗尽；上次调度持续阻塞，下次调度被错过；
  • 处理策略：
    • 过期超 5s：本次忽略，当前时间开始计算下次触发时间
    • 过期 5s 内：立即触发一次，当前时间开始计算下次触发时间

5.4.7 日志回调服务

调度模块的“调度中心”作为 Web 服务部署时，一方面承担调度中心功能，另一方面也为执行器提供 API 服务。

调度中心提供的”日志回调服务 API 服务”代码位置如下：

1
2
3
4
5


1.  `xxl-job-admin#com.xxl.job.admin.controller.JobApiController.callback`


“执行器”在接收到任务执行请求后，执行任务，在执行结束之后会将执行结果回调通知“调度中心”：

5.4.8 任务 HA（Failover）

执行器如若集群部署，调度中心将会感知到在线的所有执行器，如“127.0.0.1:9997, 127.0.0.1:9998, 127.0.0.1:9999”。

当任务”路由策略”选择”故障转移(FAILOVER)”时，当调度中心每次发起调度请求时，会按照顺序对执行器发出心跳检测请求，第一个检测为存活状态的执行器将会被选定并发送调度请求。

调度成功后，可在日志监控界面查看“调度备注”，如下；

“调度备注”可以看出本地调度运行轨迹，执行器的”注册方式”、”地址列表”和任务的”路由策略”。”故障转移 (FAILOVER)”路由策略下，调度中心首先对第一个地址进行心跳检测，心跳失败因此自动跳过，第二个依然心跳检测失败……
直至心跳检测第三个地址“127.0.0.1:9999”成功，选定为“目标执行器”；然后对“目标执行器”发送调度请求，调度流程结束，等待执行器回调执行结果。

5.4.9 调度日志

调度中心每次进行任务调度，都会记录一条任务日志，任务日志主要包括以下三部分内容：

  • 任务信息：包括“执行器地址”、“JobHandler”和“执行参数”等属性，点击任务 ID 按钮可查看，根据这些参数，可以精确的定位任务执行的具体机器和任务代码；
  • 调度信息：包括“调度时间”、“调度结果”和“调度日志”等，根据这些参数，可以了解“调度中心”发起调度请求时具体情况。
  • 执行信息：包括“执行时间”、“执行结果”和“执行日志”等，根据这些参数，可以了解在“执行器”端任务执行的具体情况；

调度日志，针对单次调度，属性说明如下：

  • 执行器地址：任务执行的机器地址；
  • JobHandler：Bean 模式表示任务执行的 JobHandler 名称；
  • 任务参数：任务执行的入参；
  • 调度时间：调度中心，发起调度的时间；
  • 调度结果：调度中心，发起调度的结果，SUCCESS 或 FAIL；
  • 调度备注：调度中心，发起调度的备注信息，如地址心跳检测日志等；
  • 执行时间：执行器，任务执行结束后回调的时间；
  • 执行结果：执行器，任务执行的结果，SUCCESS 或 FAIL；
  • 执行备注：执行器，任务执行的备注信息，如异常日志等；
  • 执行日志：任务执行过程中，业务代码中打印的完整执行日志，见“4.8 查看执行日志”；

5.4.10 任务依赖

原理：XXL-JOB 中每个任务都对应有一个任务 ID，同时，每个任务支持设置属性“子任务 ID”，因此，通过“任务 ID”可以匹配任务依赖关系。

当父任务执行结束并且执行成功时，将会根据“子任务 ID”匹配子任务依赖，如果匹配到子任务，将会主动触发一次子任务的执行。

在任务日志界面，点击任务的“执行备注”的“查看”按钮，可以看到匹配子任务以及触发子任务执行的日志信息，如无信息则表示未触发子任务执行，可参考下图。

5.4.11 全异步化 & 轻量级

  • 全异步化设计：XXL-JOB 系统中业务逻辑在远程执行器执行，触发流程全异步化设计。相比直接在调度中心内部执行业务逻辑，极大的降低了调度线程占用时间；
    • 异步调度：调度中心每次任务触发时仅发送一次调度请求，该调度请求首先推送“异步调度队列”，然后异步推送给远程执行器
    • 异步执行：执行器会将请求存入“异步执行队列”并且立即响应调度中心，异步运行。
  • 轻量级设计：XXL-JOB 调度中心中每个 JOB 逻辑非常 “轻”，在全异步化的基础上，单个 JOB 一次运行平均耗时基本在 “10ms” 之内（基本为一次请求的网络开销）；因此，可以保证使用有限的线程支撑大量的 JOB 并发运行；

得益于上述两点优化，理论上默认配置下的调度中心，单机能够支撑 5000 任务并发运行稳定运行；

实际场景中，由于调度中心与执行器网络 ping 延迟不同、DB 读写耗时不同、任务调度密集程度不同，会导致任务量上限会上下波动。

如若需要支撑更多的任务量，可以通过 “调大调度线程数” 、”降低调度中心与执行器 ping 延迟” 和 “提升机器配置” 几种方式优化。

5.4.12 均衡调度

调度中心在集群部署时会自动进行任务平均分配，触发组件每次获取与线程池数量（调度中心支持自定义调度线程池大小）相关数量的任务，避免大量任务集中在单个调度中心集群节点；

5.5 任务 “运行模式” 剖析

5.5.1 “Bean 模式” 任务

开发步骤：可参考 “章节三” ；
原理：每个 Bean 模式任务都是一个 Spring 的 Bean 类实例，它被维护在“执行器”项目的 Spring 容器中。任务类需要加“@JobHandler(value=”名称”)”注解，因为“执行器”会根据该注解识别 Spring 容器中的任务。任务类需要继承统一接口“IJobHandler”，任务逻辑在 execute 方法中开发，因为“执行器”在接收到调度中心的调度请求时，将会调用“IJobHandler”的 execute 方法，执行任务逻辑。

5.5.2 “GLUE 模式(Java)” 任务

开发步骤：可参考 “章节三” ；
原理：每个 “GLUE 模式(Java)” 任务的代码，实际上是“一个继承自“IJobHandler”的实现类的类代码”，“执行器”接收到“调度中心”的调度请求时，会通过 Groovy 类加载器加载此代码，实例化成 Java 对象，同时注入此代码中声明的 Spring 服务（请确保 Glue 代码中的服务和类引用在“执行器”项目中存在），然后调用该对象的 execute 方法，执行任务逻辑。

5.5.3 GLUE 模式(Shell) + GLUE 模式(Python) + GLUE 模式(PHP) + GLUE 模式(NodeJS) + GLUE 模式(Powershell)

开发步骤：可参考 “章节三” ；
原理：脚本任务的源码托管在调度中心，脚本逻辑在执行器运行。当触发脚本任务时，执行器会加载脚本源码在执行器机器上生成一份脚本文件，然后通过 Java 代码调用该脚本；并且实时将脚本输出日志写到任务日志文件中，从而在调度中心可以实时监控脚本运行情况；

目前支持的脚本类型如下：

1
2
3
4
5
6
7
8
9


1.  `- shell 脚本：任务运行模式选择为  "GLUE 模式 (Shell)" 时支持  "Shell"  脚本任务；`
2.  `- python 脚本：任务运行模式选择为  "GLUE 模式 (Python)" 时支持  "Python"  脚本任务；`
3.  `- php 脚本：任务运行模式选择为  "GLUE 模式 (PHP)" 时支持  "PHP"  脚本任务；`
4.  `- nodejs 脚本：任务运行模式选择为  "GLUE 模式 (NodeJS)" 时支持  "NodeJS"  脚本任务；`
5.  `- powershell：任务运行模式选择为  "GLUE 模式 (PowerShell)" 时支持  "PowerShell"  脚本任务；`


脚本任务通过 Exit Code 判断任务执行结果，状态码可参考章节 “5.15 任务执行结果说明”；

5.5.4 执行器

执行器实际上是一个内嵌的 Server，默认端口 9999（配置项：xxl.job.executor.port）。

在项目启动时，执行器会通过“@JobHandler”识别 Spring 容器中“Bean 模式任务”，以注解的 value 属性为 key 管理起来。

“执行器”接收到“调度中心”的调度请求时，如果任务类型为“Bean 模式”，将会匹配 Spring 容器中的“Bean 模式任务”，然后调用其 execute 方法，执行任务逻辑。如果任务类型为“GLUE 模式”，将会加载 GLue 代码，实例化 Java 对象，注入依赖的 Spring 服务（注意：Glue 代码中注入的 Spring 服务，必须存在与该“执行器”项目的 Spring 容器中），然后调用 execute 方法，执行任务逻辑。

5.5.5 任务日志

XXL-JOB 会为每次调度请求生成一个单独的日志文件，需要通过 “XxlJobHelper.log” 打印执行日志，“调度中心”查看执行日志时将会加载对应的日志文件。

(历史版本通过重写 LOG4J 的 Appender 实现，存在依赖限制，该方式在新版本已经被抛弃)

日志文件存放的位置可在“执行器”配置文件进行自定义，默认目录格式为：/data/applogs/xxl-job/jobhandler/“格式化日期”/“数据库调度日志记录的主键 ID.log”。

在 JobHandler 中开启子线程时，子线程将会把日志打印在父线程即 JobHandler 的执行日志中，方便日志追踪。

5.6 通讯模块剖析

5.6.1 一次完整的任务调度通讯流程

1
2
3
4
5
6
7


1.  `-  1、“调度中心”向“执行器”发送 http 调度请求:  “执行器”中接收请求的服务，实际上是一台内嵌 Server，默认端口 9999;`
2.  `-  2、“执行器”执行任务逻辑；`
3.  `-  3、“执行器”http 回调“调度中心”调度结果:  “调度中心”中接收回调的服务，是针对执行器开放一套 API 服务;`


5.6.2 通讯数据加密

调度中心向执行器发送的调度请求时使用 RequestModel 和 ResponseModel 两个对象封装调度请求参数和响应数据, 在进行通讯之前底层会将上述两个对象对象序列化，并进行数据协议以及时间戳检验, 从而达到数据加密的功能;

5.7 任务注册, 任务自动发现

自 v1.5 版本之后, 任务取消了”任务执行机器”属性, 改为通过任务注册和自动发现的方式, 动态获取远程执行器地址并执行。

1
2
3
4
5
6
7
8


1.  `AppName:  每个执行器机器集群的唯一标示,  任务注册以  " 执行器 "  为最小粒度进行注册 ;  每个任务通过其绑定的执行器可感知对应的执行器机器列表;`
2.  ` 注册表:  见"xxl_job_registry" 表,  " 执行器 "  在进行任务注册时将会周期性维护一条注册记录，即机器地址和 AppName 的绑定关系;  " 调度中心 "  从而可以动态感知每个 AppName 在线的机器列表;`
3.  ` 执行器注册:  任务注册Beat 周期默认 30s;  执行器以一倍Beat 进行执行器注册,  调度中心以一倍Beat 进行动态任务发现;  注册信息的失效时间为三倍Beat;` 
4.  ` 执行器注册摘除：执行器销毁时，将会主动上报调度中心并摘除对应的执行器机器信息，提高心跳注册的实时性；`


为保证系统”轻量级”并且降低学习部署成本，没有采用 Zookeeper 作为注册中心，采用 DB 方式进行任务注册发现；

5.8 任务执行结果

自 v1.6.2 之后，任务执行结果通过 “IJobHandler” 的返回值 “ReturnT” 进行判断；
当返回值符合 “ReturnT.code == ReturnT.SUCCESS_CODE” 时表示任务执行成功，否则表示任务执行失败，而且可以通过 “ReturnT.msg” 回调错误信息给调度中心；
从而，在任务逻辑中可以方便的控制任务执行结果；

5.9 分片广播 & 动态分片

执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；

“分片广播” 以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。

“分片广播” 和普通任务开发流程一致，不同之处在于可以获取分片参数，获取分片参数进行分片业务处理。

  • Java 语言任务获取分片参数方式：BEAN、GLUE 模式(Java)```

    1. // 可参考 Sample 示例执行器中的示例任务 "ShardingJobHandler" 了解试用
    2. int shardIndex = XxlJobHelper.getShardIndex();
    3. int shardTotal = XxlJobHelper.getShardTotal();
    1
    2
    3
    4
    5
    6
    7
    8
    9

    *   脚本语言任务获取分片参数方式：GLUE 模式(Shell)、GLUE 模式(Python)、GLUE 模式(Nodejs)```


        1.  `// 脚本任务入参固定为三个，依次为：任务传参、分片序号、分片总数。以 Shell 模式任务为例，获取分片参数代码如下 `
        2.  `echo " 分片序号 index = $2"`
        3.  `echo " 分片总数 total = $3"`

分片参数属性说明：

1
2
3
4
5
6


1.  `index：当前分片序号 (从0 开始)，执行器集群列表中当前执行器的序号；`
2.  `total：总分片数，执行器集群的总机器数量；`


该特性适用场景如：

  • 1、分片任务场景：10 个执行器的集群来处理 10w 条数据，每台机器只需要处理 1w 条数据，耗时降低 10 倍；
  • 2、广播任务场景：广播执行器机器运行 shell 脚本、广播集群节点进行缓存更新等

5.10 访问令牌（AccessToken）

为提升系统安全性，调度中心和执行器进行安全性校验，双方 AccessToken 匹配才允许通讯；

调度中心和执行器，可通过配置项 “xxl.job.accessToken” 进行 AccessToken 的设置。

调度中心和执行器，如果需要正常通讯，只有两种设置；

  • 设置一：调度中心和执行器，均不设置 AccessToken；关闭安全性校验；
  • 设置二：调度中心和执行器，设置了相同的 AccessToken；

5.11 故障转移 & 失败重试

一次完整任务流程包括”调度（调度中心） + 执行（执行器）”两个阶段。

  • “故障转移”发生在调度阶段，在执行器集群部署时，如果某一台执行器发生故障，该策略支持自动进行 Failover 切换到一台正常的执行器机器并且完成调度请求流程。
  • “失败重试”发生在”调度 + 执行”两个阶段，支持通过自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；

5.12 执行器灰度上线

调度中心与业务解耦，只需部署一次后常年不需要维护。但是，执行器中托管运行着业务作业，作业上线和变更需要重启执行器，尤其是 Bean 模式任务。
执行器重启可能会中断运行中的任务。但是，XXL-JOB 得益于自建执行器与自建注册中心，可以通过灰度上线的方式，避免因重启导致的任务中断的问题。

步骤如下：

  • 1、执行器改为手动注册，下线一半机器列表（A 组），线上运行另一半机器列表（B 组）；
  • 2、等待 A 组机器任务运行结束并编译上线；执行器注册地址替换为 A 组；
  • 3、等待 B 组机器任务运行结束并编译上线；执行器注册地址替换为 A 组 +B 组；
    操作结束；

5.13 任务执行结果说明

系统根据以下标准判断任务执行结果，可参考之。

— Bean/Glue(Java) Glue(Shell) 等脚本任务
成功 IJobHandler.SUCCESS 0
失败 IJobHandler.FAIL -1（非 0 状态码）

5.14 任务超时控制

支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；

需要注意的是，任务超时中断时与任务终止机制（可查看“4.9 终止运行中的任务”）类似，也是通过 “interrupt” 中断任务，因此业务代码需要将 “InterruptedException” 外抛，否则功能不可用。

5.15 跨语言

XXL-JOB 是一个跨语言的任务调度平台，主要体现在如下几个方面：

  • 1、RESTful API：调度中心与执行器提供语言无关的 RESTful API 服务，第三方任意语言可据此对接调度中心或者实现执行器。（可参考章节 “调度中心 / 执行器 RESTful API” ）
  • 2、多任务模式：提供 Java、Python、PHP……等十来种任务模式，可参考章节 “5.5 任务 “运行模式” ”；理论上可扩展任意语言任务模式；
  • 2、提供基于 HTTP 的任务 Handler（Bean 任务，JobHandler=”httpJobHandler”）；业务方只需要提供 HTTP 链接等相关信息即可，不限制语言、平台；（可参考章节 “原生内置 Bean 模式任务” ）

5.16 任务失败告警

默认提供邮件失败告警，可扩展短信、钉钉等方式。如果需要新增一种告警方式，只需要新增一个实现 “com.xxl.job.admin.core.alarm.JobAlarm” 接口的告警实现即可。可以参考默认提供邮箱告警实现 “EmailJobAlarm”。

5.17 调度中心 Docker 镜像构建

可以通过以下命令快速构建调度中心，并启动运行；

1
2
3
4
5
6
7


1.  `mvn clean package`
2.  `docker build -t xuxueli/xxl-job-admin ./xxl-job-admin`
3.  `docker run --name xxl-job-admin -p 8080:8080  -d xuxueli/xxl-job-admin`


5.20 避免任务重复执行

调度密集或者耗时任务可能会导致任务阻塞，集群情况下调度组件小概率情况下会重复触发；
针对上述情况，可以通过结合 “单机路由策略（如：第一台、一致性哈希）” + “阻塞策略（如：单机串行、丢弃后续调度）” 来规避，最终避免任务重复执行。

5.21 命令行任务

原生提供通用命令行任务 Handler（Bean 任务，”CommandJobHandler”）；业务方只需要提供命令行即可；
如任务参数 “pwd” 将会执行命令并输出数据；

5.22 日志自动清理

XXL-JOB 日志主要包含如下两部分，均支持日志自动清理，说明如下：

  • 调度中心日志表数据：可借助配置项 “xxl.job.logretentiondays” 设置日志表数据保存天数，过期日志自动清理；详情可查看上文配置说明；
  • 执行器日志文件数据：可借助配置项 “xxl.job.executor.logretentiondays” 设置日志文件数据保存天数，过期日志自动清理；详情可查看上文配置说明；

5.23 调度结果丢失处理

执行器因网络抖动回调失败或宕机等异常情况，会导致任务调度结果丢失。由于调度中心依赖执行器回调来感知调度结果，因此会导致调度日志永远处于 “运行中” 状态。

针对该问题，调度中心提供内置组件进行处理，逻辑为：调度记录停留在 “运行中” 状态超过 10min，且对应执行器心跳注册失败不在线，则将本地调度主动标记失败；