XXL-JOB最佳实践与升级指南

前言：

xxl-job是国内一款使用者比较多的分布式任务调度平台，我们内部从19年开始使用该款开源软件，使用的是2.0.1版本，并在此基础上做了二次开发，添加了一些定制化的功能。随着使用该定时器的业务组越来越多，有些业务组提出想要使用xxl-job新版本中引入的一些功能。因此，我们着手考虑了xxl-job的升级方案。

通过该文章，你可以学习到如下内容：

1. xxl-job的版本从2.0.1升级到2.3.1存在不兼容的问题，而且生产环境已经在使用，如何做到无缝迁移

2. xxl-job中主要功能的具体处理流程和底层原理，遇到问题可以快速排查

3. xxl-job在使用的过程中有哪些注意事项，避免踩坑

升级方案选型：

xxl-job升级面临的问题

xxl-job的版本从2.0.1升级到2.3.1存在不兼容的问题，而且生产环境已经在使用，如何做到无缝迁移
内部使用的过程中进行过二次开发，对代码进行过修改，如何顺利迁移已经修改过的逻辑

xxl-job升级步骤

检查xxl-job-core是否向后兼容

经过测试发现，xxl-job-core的2.0.1版本无法成功注册到xxl-job-admin上面去。

为了能够实现升级的平滑过渡，我们考虑了如下三个方案：

（1）修改xxl-job-admin的源代码为了能够保证已有job的正常工作，使得2.3.1版本的xxl-job-admin同时支持2.0.1版本和2.3.1两个版本的xxl-job-core

（2）修改xxl-job-core的代码使得2.3.1版本的xxl-job-core同时识别2.0.1版本和2.3.1版本的注解和配置

（3）admin端和core端都不做修改，升级后各个业务自己修改JobHandler的相关代码

经过调研分析，我们决定采用第二种修改方案，这样我们的改动比较小，而且对各个业务方也基本上是透明的，基本不用对代码进行修改。

检查数据存储对应关系，编写数据迁移脚本

2.0.1版本的数据库表如下：

XXL_JOB_QRTZ_BLOB_TRIGGERS	Quartz框架中使用的数据表，该项目中目前未使用到
XXL_JOB_QRTZ_CALENDARS	同上
XXL_JOB_QRTZ_CRON_TRIGGERS	存储定时任务的cron信息和时区信息
XXL_JOB_QRTZ_FIRED_TRIGGERS	Quartz框架中存储当前已经运行的触发器状态信息
XXL_JOB_QRTZ_JOB_DETAILS	Quartz框架中存储触发器的详细信息
XXL_JOB_QRTZ_LOCKS	Quartz框架中的悲观锁
XXL_JOB_QRTZ_PAUSED_TRIGGER_GRPS	Quartz框架中暂停的触发器组信息
...................................................	忽略Quartz框架下的其他数据库表，Quartz框架下的数据表和数据迁移工作内容无关
XXL_JOB_QRTZ_TRIGGER_GROUP	定时任务所属分组，也就是各个工程的相关信息
XXL_JOB_QRTZ_TRIGGER_INFO	定时任务的基本信息
XXL_JOB_QRTZ_LDAP_GROUP	LDAP分组与定时任务分组的关联关系表（二次开发添加）
XXL_JOB_QRTZ_TRIGGER_LOGGLUE	以GLUE模式运行的定时任务对应的源码信息
XXL_JOB_QRTZ_TRIGGER_REGISTRY	注册的执行器信息
XXL_JOB_QRTZ_TRIGGER_LOG	记录定时任务的调度结果，这里需要注意的时候，调度成功并不代表着该定时任务执行成功。

2.3.1版本xxl-job数据库表信息如下：

xxl_job_group	对应2.0.1版本中XXL_JOB_QRTZ_TRIGGER_GROUP数据表
xxl_job_info	对应2.0.1版本中的XXL_JOB_QRTZ_TRIGGER_INFO
xxl_job_lock	JobScheduleHelper通过该数据库表实现对定时任务的互斥调度；如果要实现一个简单的分布式调度器，实现JobScheduleHelper这个类基本就够了
xxl_job_log	对应2.0.1版本中的XXL_JOB_QRTZ_TRIGGER_LOG表
xxl_job_log_report	定时任务调度结果的汇总报表
xxl_job_logglue	对应2.0.1版本中的XXL_JOB_QRTZ_TRIGGER_LOGGLUE表
xxl_job_registry	对应2.0.1版本中的XXL_JOB_QRTZ_TRIGGER_REGISTRY表
xxl_job_user	新增的用户信息表，在我们内部不会使用到
手动新增：xxl_job_ldap_group	存储各个技术组的信息

注：有关Quartz框架中数据库表字段解释可以参考这篇技术博客：

https://www.cnblogs.com/zyulike/p/13671130.html

3. 修改2.3.1版本的xxl-job-admin

这个步骤里面的主要工作是迁移和添加二次开发的代码到新版本的xxl-job-admin，主要功能包括：登录逻辑修改，权限管理逻辑修改，邮件报警通知修改成企业微信通知，执行器和定时任务进行分组管理，针对不合理的逻辑进行性能优化。

4. 修改2.3.1版本的xxl-job-core

修改xxl-job-core的代码使得2.3.1版本的xxl-job-core同时识别2.0.1版本和2.3.1版本的注解和配置

注意事项：

如果在JobHandler实现类中有需要进行一次性初始化的操作，务必避免使用init()这个方法，因为JobHandler每次运行的时候都会重复执行init()方法
定时任务执行失败可以通过企业微信通知相关的负责人，注意需要抛异常出来才可以
注册的执行器节点最好使用自动注册的方式

xxl-job定时任务处理流程：

v.2.0.1版本控制台侧xxl-job手动触发定时任务的处理流程：

自动触发定时任务是通过XxlJobDynamicSchedulerConfig中创建的SchedulerFactoryBean来调度完成

v2.3.1版本控制台侧手动触发定时任务的处理流程：

自动触发定时任务是通过XxlJobAdminConfig中创建的XxlJobScheduler来调度完成的

v2.0.1版本业务侧定时任务的处理流程如下：

v2.3.1版本业务侧定时任务的处理流程和v2.0.1版本的处理流程并没有太多的区别，主要的差异在于EmbedServer从JettyServer切换成了NettyServer，底层信息的协议格式依然是HTTP协议。

新版本主要功能底层实现原理解析：

功能解析一：

调度线程池隔离，拆分为”Fast”和”Slow”两个线程池，1分钟窗口期内任务耗时达500ms超过10次，该窗口期内判定为慢任务，慢任务自动降级进入”Slow”线程池，避免耗尽调度线程，提高系统稳定性

上述功能是通过在JobScheduleHelper中设置两个线程池来实现的，不过实在不太理解这个功能的作用是什么，因为只要调度成功给业务侧的EmbedServer后EmbedServer就会返回成功的消息给控制台一端，而不需要等待定时任务具体逻辑真正执行结束。

功能解析二：自研调度组件，移除quartz依赖：一方面是为了精简系统降低冗余依赖，另一方面是为了提供系统的可控度与稳定性；

该自研的调度组件是依赖JobScheduleHelper来完成的，具体处理流程如下所示：

功能解析三：GLUE-JAVA模式的定时任务是如何工作的

通过Groovy ClassLoader将Java源码动态编译成为class，具体处理可以查看GlueFactory类

总结：

今天就写到这里吧，如果有想继续深入沟通的小伙伴儿，请加微信群聊或者本人微信进一步沟通和交流。