一、 概述
xxl-job的执行器注册过程如下,执行器自启动开始,每30s进行一次注册,注册同时兼具了心跳机制。
而调度器则是在接收到注册请求之后,判断该执行器是否已经注册,如果已注册,则更新心跳时间。
二、 源码分析
1.调度器与执行器的交互
首先看一下xxl-job-core子项目的两个接口,AdminBiz与ExecutorBiz:
先看AdminBiz,负责执行器向调度器的各类请求的聚合,比如 执行器任务完成后的回调(callback),执行器注册请求(registry)等。
继续看registry方法,会发现有两个实现类,一个是core子项目下的,一个是admin子项目下的。
由下图可知,这两个实现,一个是执行器端,一个是调度器端,执行器端只是进行http请求,调度端才是实际逻辑。
同理,ExecutorBiz则是调度器对执行器的请求,包含任务执行,取消等接口,调度器与执行器实现分别如下:
2. 调度器端服务注册线程启动
简单了解了调度器与执行器交互的接口,我们便来解答另一个问题,执行器是如何注册到调度器上的。
- 回到调度器的init,在国际化之后第二步即服务注册线程的启动。
- JobRegistryMonitorHelper.getInstance().start()
看下面这段代码之前,先回忆一下第一章提到的表结构,其中:
- xxl_job_group:执行器信息表,维护任务执行器信息;
- xxl_job_registry:执行器注册表,维护在线的执行器和调度中心机器地址信息;
第一步,从xxl_job_group获取到所有执行器数据,addressType=0的即为自动注册的执行器。
第二步,清理xxl_job_registry中心跳机制大于3倍心跳时间的“死执行器”。
第三四步,从xxl_job_registry中获取“活执行器”,然后将地址拼接成 "ip1,ip2"的形式,存储在xxl_job_group中。
最后,睡眠一个心跳时间,等待下次执行。
简单总结,此处线程做的操作很简单,即通过xxl_job_registry提供的心跳/注册数据,更新xxl_job_group表,也就是最终我们从页面看到的执行器列表