我是靠谱客的博主 虚拟战斗机,最近开发中收集的这篇文章主要介绍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分片)

最后

以上就是虚拟战斗机为你收集整理的XXL-JOB源码分析的全部内容,希望文章能够帮你解决XXL-JOB源码分析所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(49)

评论列表共有 0 条评论

立即
投稿
返回
顶部