xxl-job介绍参考资料： XXL官网：https://www.xuxueli.com/xxl-job/ git-hu

参考资料：

XXL官网：www.xuxueli.com/xxl-job/

git-hub：github.com/xuxueli/xxl…

3千字带你搞懂XXL-JOB任务调度平台 developer.aliyun.com/article/775…

分布式任务调度系统xxl-job搭建(基于docker) www.cnblogs.com/xiao9873341…

xxl-job介绍

（1）架构图

（2）特性

1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；

2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；

3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；

4、执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；

5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；

6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；

7、触发策略：提供丰富的任务触发策略，包括：Cron触发、固定间隔触发、固定延时触发、API（事件）触发、人工触发、父子任务触发；

8、调度过期策略：调度中心错过调度时间的补偿处理策略，包括：忽略、立即补偿触发一次等；

9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；

10、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；

11、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；

12、任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式；

13、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；

14、分片广播任务：执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；

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

16、故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。

17、任务进度监控：支持实时监控任务进度；

18、Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志；

19、GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。

20、脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本;

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

22、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；

23、一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；

24、自定义任务参数：支持在线配置调度任务入参，即时生效；

25、调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；

26、数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；

27、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；

28、推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用;

29、运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；

30、全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；

31、跨语言：调度中心与执行器提供语言无关的 RESTful API 服务，第三方任意语言可据此对接调度中心或者实现执行器。除此之外，还提供了 “多任务模式”和“httpJobHandler”等其他跨语言方案；

32、国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文；

33、容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用；

34、线程池隔离：调度线程池进行隔离拆分，慢任务自动降级进入”Slow”线程池，避免耗尽调度线程，提高系统稳定性；

35、用户管理：支持在线管理系统用户，存在管理员、普通用户两种角色；

36、权限控制：执行器维度进行权限控制，管理员拥有全量权限，普通用户需要分配执行器权限后才允许相关操作；

部署xxl-job

（1）初始化“调度数据库”：部署mysql数据库并初始化

docker run -d -e MYSQL_ROOT_PASSWORD=xxxxxx  -p 3306:3306  -v /mysql_data:/opt mysql:8.0  --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

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

（2）配置部署“调度中心”：部署xxl-job-admin

docker run -e PARAMS="--spring.datasource.url=jdbc:mysql://xxx.xxx.xxx.xx:3306/xxl_job?Unicode=true&characterEncoding=UTF-8 --spring.datasource.username=root --spring.datasource.password=xxxxxx" -p 8080:8080 -v /xxl_job_data:/data/applogs --name xxl-job-admin xuxueli/xxl-job-admin:2.3.0

执行器管理

任务管理

（3）配置部署“执行器项目”

配置文件：

### 调度中心部署跟地址 [选填]：如调度中心集群部署存在多个地址则用逗号分隔。执行器将会使用该地址进行"执行器心跳注册"和"任务结果回调"；为空则关闭自动注册；
xxl.job.admin.addresses=http://127.0.0.1:8080/xxl-job-admin
### 执行器通讯TOKEN [选填]：非空时启用；
xxl.job.accessToken=
### 执行器AppName [选填]：执行器心跳注册分组依据；为空则关闭自动注册
xxl.job.executor.appname=xxl-job-executor-sample
### 执行器注册 [选填]：优先使用该配置作为注册地址，为空时使用内嵌服务 ”IP:PORT“ 作为注册地址。从而更灵活的支持容器类型执行器动态IP和动态映射端口问题。
xxl.job.executor.address=
### 执行器IP [选填]：默认为空表示自动获取IP，多网卡时可手动设置指定IP，该IP不会绑定Host仅作为通讯实用；地址信息用于 "执行器注册" 和 "调度中心请求并触发任务"；
xxl.job.executor.ip=
### 执行器端口号 [选填]：小于等于0则自动获取；默认端口为9999，单机部署多个执行器时，注意要配置不同执行器端口；
xxl.job.executor.port=9999
### 执行器运行日志文件存储磁盘路径 [选填] ：需要对该路径拥有读写权限；为空则使用默认路径；
xxl.job.executor.logpath=/data/applogs/xxl-job/jobhandler
### 执行器日志文件保存天数 [选填] ：过期日志自动清理, 限制值大于等于3时生效; 否则, 如-1, 关闭自动清理功能；
xxl.job.executor.logretentiondays=30

执行器：

@XxlJob("demoJobHandler2")
public void demoJobHandler2() throws Exception {    
    logger.info("XXL-JOB, Hello World.");
}

注册多个执行器，只会有一个执行

任务支持以下策略：

- 路由策略：当执行器集群部署时，提供丰富的路由策略，包括；
FIRST（第一个）：固定选择第一个机器；
LAST（最后一个）：固定选择最后一个机器；
ROUND（轮询）：；
RANDOM（随机）：随机选择在线的机器；
CONSISTENT_HASH（一致性HASH）：每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。
LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举；
LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举；
FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度；
BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度；
SHARDING_BROADCAST(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；

（4）集群部署

XXL有中心化的思想，一旦调度中心挂机会导致整体不可使用，所以要引入集群。

需要考虑点：

db配置保持一致
登录账号配置保持一致
集群机器时钟保持一致（单机集群可忽视）

建议：推荐通过nginx为调度中心集群做负载均衡，分配域名。调度中心访问、执行器回调配置、调用API服务等操作均通过该域名进行。

基于nginx实现xxl-job-admin集群：其实现机制是主备关系的。

操作的数据库都是相同的，集群是tomcat服务器集群，但是连接的都是相同的数据库同表，不会产生Job的重复执行问题。

调度中心高可用是怎么实现的呢？

当有两个调度中心时，就会通过分布式锁，看谁拿到了这个分布式锁，再去数据库查询那个触发器将要触发，到达触发时间的任务进行调度。

使用xxl-job

（1）通过接口操作定时任务，需要先登录

blog.csdn.net/MrFlameDrag…

接口明细：

操作

接口

备注

创建执行器

xxl-job-admin/jobgroup/save

修改执行器

xxl-job-admin/jobgroup/update

删除执行器

xxl-job-admin/jobgroup/remove

创建任务

xxl-job-admin/jobinfo/add

修改任务

xxl-job-admin/jobinfo/update

删除任务

xxl-job-admin/jobinfo/remove

启动任务

xxl-job-admin/jobinfo/start

停止任务

xxl-job-admin/jobinfo/stop

查询任务

xxl-job-admin/jobinfo/pageList

没有单独任务的查询接口，需要自己过滤数据

查询执行器

xxl-job-admin/jobgroup/pageList

没有单独执行器的查询接口，需要自己过滤数据

（1）获取登录cookie

访问登录接口http://xxxxxxxx :8080/xxl-job-admin/login获取cooike中的字段：XXL_JOB_LOGIN_IDENTITY

（2）执行操作

操作时，在headers中增加XXL_JOB_LOGIN_IDENTITY

xxl-job问题

（1）执行器自动注册

执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；

首先要在注册中心创建执行器的配置，执行器启动时会自动注册自己上去。

### 调度中心部署跟地址 [选填]：如调度中心集群部署存在多个地址则用逗号分隔。执行器将会使用该地址进行"执行器心跳注册"和"任务结果回调"；为空则关闭自动注册；
xxl.job.admin.addresses=http://127.0.0.1:8080/xxl-job-admin

（2）阻塞处理策略

调度过于密集执行器来不及处理时的处理策略，策略包括：

单机串行（默认）
丢弃后续调度
覆盖之前调度

同一任务并发执行？github.com/xuxueli/xxl… 自己实现一个基于logId的jobThreadRepository就可以了？待验证

（3）全异步

任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；

（4）分片广播任务

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

（5）故障转移和失败重试

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

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

juejin.cn/post/704415…

5.1 故障转移

发生在调度阶段，对列表中的执行器进行心跳检测

5.2 失败重试

125 195同时在线，手动触发执行一次
任务调度到195上，执行过程中，将195上的程序杀掉
任务调度到125上重新执行

7 执行器如果宕机了，任务会丢失吗

执行器如果宕机，admin平台会报错连接执行器失败，但是任务不会丢失，底层会把每次失败的任务记录下来，等执行器启动的时候再一次性执行。

xxl-job原理

XXL-job原理 juejin.cn/post/699923…

（1）任务调度流程

从xxl_job_info表中找出当前时间 + 5s的所有执行器的数据，然后，根据其调度时间判断是立即调度还是加入到时间轮中（如果任务很多的话，在循环过程中有可能导致当前时间已经大于调度时间的情况）
对加入到时间轮中的数据进行遍历调用

以上是将5s内的任务加入到时间轮中，那么加入时间轮之后是怎么运行的呢？其实内部有一个ringThread 线程来负责对该时间轮遍历运行；其流程如下：

（2）任务触发流程

快慢线程池：在1分钟内，如果一个任务有10次提交时间花费大于500ms（虽然是异步执行，但是由于网络原因，可能会大于500ms），就认为这个任务是慢任务，为了防止这种慢任务影戏系统吞吐量，就将其放在慢线程池中运行；

（3）执行器心跳检测流程

更新appName对应的IP组，将新增的IP添加到组中，将断线的IP进行清理（因为我们的执行器是会上下线的。我们需要及时更新当前在线的执行器）其流程图如下

注：xxl-job有心跳机制，客户端会向注册中心发送心跳，xxl-job会把这个心跳信息保存在xxl_job_registry 此时，就能够实现心跳检测机制，保证机器下线能够及时清除，机器上线能够及时发现

（4）失败重试和报警流程

调度失败情况有很多：

比如无法将调度信息发送给执行器（可能没有存活执行器）
或者任务的超时时间到了，系统会给执行器一个中断信号
或者任务在执行的过程中，突然宕机

以上都会导致调度失败，但是都会把失败的情况记录到数据库中，然后，通过对调度日志进行分析来判断是否需要重试和报警。

（4）任务调度流程

注册中心，执行器的原理

juejin.cn/post/697417…

juejin.cn/post/697641…

tips

触发参数
停止过程，disable，不要直接删除，保留日志供查障使用
通过代码实现接口对接
实际场景下的方案流程

端口号问题

xxl-job在客户端会单独开一个接口给xxl-job-admin使用，默认是9999端口号，如果9999端口号被占用，端口号会依次+1重试。我认为这里单独开一个端口号是完全没有必要的，浪费执行器资源先不谈，开两个端口号感觉就挺扯，像是swagger ui集成到spring-boot程序中也没有单独开一个端口号啊。。

最重要的是多开一个端口号没问题，问题是这个端口号都是9999，这里假设几个场景，看看怎么做

所有服务都使用了xxl-job，部署在同一个ECS机器上。每个服务都想占用默认的9999端口号，第一个占用成功了，第二个端口号10000，第三个依次增加1。。。。在这个场景下没问题，每个java程序共享ECS资源，可以探知端口号占用情况，无端口号冲突。
所有服务都使用了xxl-job，都使用docker部署，部署在同一个ECS机器上。这时候就不好办了，运行在docker中的java程序无法知道其他docker中的java程序运行情况，因为docker把环境隔离了，只能由docker开放指定端口号和容器内运行的java程序端口号映射。这就极大增加了运维成本。

我认为正确的做法就是复用原来的端口号，这样一个端口号就能解决问题。

实际上已经有人提了PR：改造在SpringBoot环境下，直接使用SpringBoot端口但是迟迟没有被合并，实际上这个开源项目下的issue已经多达五百多个，PR数量也已经近四十个，其实这个项目还是有人继续维护的，最近的2.3.0版本release在两个月以前，但是这么多issue和pr都没人管，说明作者实际上不关心使用者的感受，只能这么认为了。

一台机器部署多个使用了xxl-job的不同服务实例问题 github.com/xuxueli/xxl…

xxl-job滥用netty导致的问题和解决方案 www.cnblogs.com/kuangdaoyiz…

改造在SpringBoot环境下，直接使用SpringBoot端口 #2266 github.com/xuxueli/xxl…