概述
本文档以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分片)
最后
以上就是虚拟战斗机为你收集整理的XXL-JOB源码分析的全部内容,希望文章能够帮你解决XXL-JOB源码分析所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复