XXL-JOB源码分析

本文档以2.2.0版本为基准

一、表结构

xxl_job_group	执行器表	保存执行器列表，客户端地址列表
xxl_job_info	任务调度表	保存任务列表，下次调度时间
xxl_job_lock	并发锁表	Admin集群场景
xxl_job_log	任务日志表	保存每次任务调度情况
xxl_job_log_report	任务统计表	保存每日任务执行情况
xxl_job_registry	客户端实例表	保存客户端实例信息，心跳时间
xxl_job_user	管理台用户表
xxl_job_logglueer

二、客户端

2.1扫描handler

XxlJobSpringExecutor扫描spring容器中，所有的bean，遍历各bean的Method，将其中带有@XxlJob注解的method，放置进一个currentHashMap

2.2注册executor

XxlJobExecutor执行initEmbedServer，EmbedServer创建了一个守护线程，通过netty监听端口情况；并且再创建了一个守护线程ExecutorRegistryThread，维持与服务端admin的心跳（30s）

心跳规则：

当xxl_job_register表不存在该客户端数据， insert；否则更新字段 update_time

2.3任务调度

EmbedHttpServerHandler通过守护线程，监听端口；获取run指令后，判断阻塞处理策略，invoke相应Method

三、服务端

3.1检查客户端心跳

       JobRegistryMonitorHelper创建一个守护线程，每30s执行一次

       心跳规则：

       移除xxl_job_register表中update_time 为 90s前的的记录，并刷新xxl_job_group表

3.2任务调度

       JobScheduleHelper创建了一个守护线程，每秒扫描xxl_job_info表，将到达执行时间的 任务放入JobTriggerPoolHelper。

       JobTriggerPoolHelper从线程池中选取线程，execute

四、需注意点

1.xxl_job_group没有对app_name做唯一索引，因此当误操作（创建相同app_name的执行器）后，客户端注册会存在问题从而引发调度问题

2.分片场景，分片总数以xxl_job_group.address_list字段来确定，

当客户端宕机后，短时间内(120s)，分片总数 > 实际客户端数量，会导致宕机部分的数据没有进行处理，等获取到新分片总数后，才会进行补偿

当新增客户端后，短时间内(30s)，分片总数 < 实际客户端数量

       上述2种场景，由于不同分片机器的执行效率不同，均可能出现相同数据，由于新分片后，在不同分片机器进行处理的可能。(即A分片还在处理a数据，发生了重新分片，a数据归到了B分片)