Lyd的笔记
批量处理
XXL-JOB框架使用

XXL-JOB框架使用

  1. 依赖于Spring-boot时，通过xxl-job的注解@XxlJob来注册JobHandler
  2. xxl-job-core是一个依赖库，xxl-job-admin是一个可视化的web网页，xxl-job-executor-samples是执行器

xxl-job的框架使用即在该项目中改写或增加

  1. “调度中心”平台自身不承担业务逻辑，负责调度；任务抽象分散成JobHandler，交由执行器JobExecutor统一管理，负责任务
  2. xxl-job使用的自研调度模块，早于Quartz

参考：XXL-JOB

一、调度模块剖析

1 quartz的不足

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

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

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

2 自研调度模块

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

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

3 调度中心HA（集群）

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

4 调度线程池

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

5 并行调度

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

XXL-JOB的不同任务之间并行调度、并行执行。

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

6 过期处理策略

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

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

7 日志回调服务

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

8 调度日志

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

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

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

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

10 任务依赖

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

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

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

11 执行器

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

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

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

二、任务注册, 任务自动发现

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

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

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

三、执行器灰度上线

调度中心与业务解耦，只需部署一次后常年不需要维护。但是，执行器中托管运行着业务作业，作业上线和变更需要重启执行器，尤其是Bean模式任务。

执行器重启可能会中断运行中的任务。但是，XXL-JOB得益于自建执行器与自建注册中心，可以通过灰度上线的方式，避免因重启导致的任务中断的问题。 步骤如下：

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

四、任务超时控制

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

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

五、命令行任务

原生提供通用命令行任务Handler（Bean任务，”CommandJobHandler”）；业务方只需要提供命令行即可；

如任务参数 “pwd” 将会执行命令并输出数据；

Spring batch Notes