xxl-job 源码运行解析

xxl-job 调度中心源码解析  ( RPC请求客户端)

首先我们在调度中心里面通过add接口新增一个定时任务：

在库里面会保存相应的定时任务的信息，如下：

现在我们在调度中心点击启动，会调用start 接口：

在上图的接口中我们可以看到，它会添加一个job任务到quartz中，任务的执行类是RemoteHttpJobBean，现在我们查看一下这个类:

上图中我们可以看到会通过一个快慢线程池去执行trigger，1分钟内若有10次运行超过500ms就会启动慢线程池，继续进入XxlJobTrigger.trigger：

上述代码中首先通过jobId查询数据库中保存的定时任务信息，然后是失败重试次数和分片机制，我们先跳过，直接看  processTrigger:

上述代码中首先获取阻塞策略，默认是 Serial execution 串行执行，然后是路由策略，默认是FIRST 取第一台机器执行，然后是重点执行定时任务的函数 runExecutor: 

我们直接看 XxlJobDynamicScheduler.getExecutorBiz(address) ， 这里的 address 是执行器管理中注册的ip地址,如下图:

这里实例化了一个 XxlRpcReferenceBean ：

这里初始化了一个 netty_http 服务端和客户端 

采用 HessianSerializer 作为序列化， CallType.SYNC  采用同步的请求方式， LoadBalance.ROUND 负载使用轮询的方式。

现在我们查看getObject 方法:

看到这里我们知道这是一个典型的动态代理的设计方式（ps: 不熟悉动态代理的，可以看这里我的这篇博客 动态代理白话解析）

我们继续往下看  executorBiz.run(triggerParam) ，在执行这个方法时会去调用代理处理类  InvocationHandler 中的 invoke 方法，我们直接看上图中的 invoke 方法：

前面一段是 如果代理 XxlRpcGenericService 的 invoke 方法时做的一些特殊处理，然后若 被代理类为Object 则会抛出异常，否则 就是通过路由策略路由到一个最终请求地址。最后是来到了RPC的请求调用处理

xxl-job  的 RPC请求调用处理

首先实例化了一个 XxlRpcRequest ，有  className 类名 ( 即  com.xxl.job.core.biz.ExecutorBiz )，methodName 方法名  ( 即run )，parameterTypes 参数类型名称，parameters  方法参数 这4个重要属性。我们继续看 XxlRpcReferenceBean.this.client.asyncSend(finalAddress, xxlRpcRequest) 这里会去调用 NettyHttpClient 的 asyncSend ：

在 getPool 方法中获取到NettyHttpClient 后，会执行它的 init 方法，也就是netty 的 http 客户端初始化 ：

然后这里通过连接池获取  NettyHttpConnectClient 连接，调用其send方法发送请求：

然后会通过 NettyHttpClientHandler 获取返回结果 ：

这里获取到返回结果后会调用 channelRead0 方法，将  XxlRpcResponse 放进  XxlRpcFutureResponse 中 ，我们继续往下走 看  futureResponse.get 查看获取结果的方法：

这里会加锁调用 wait  方法阻塞只到获取返回结果，我们查看 获取返回结果的响应方法 futureResponse.setResponse ：

在获取到返回结果后会调用 notifyAll 唤醒 wait 阻塞，继续往下执行  xxlRpcResponse.getResult() 得到返回结果，到这里 调度中心的请求就执行完成了。

xxl-job 执行器源码解析  ( RPC请求服务端)

现在我们看执行器任务执行的源码解析：

首先执行器在启动时会实例化 XxlJobSpringExecutor 类，调用其 start  方法进行初始化：

调用父类的 start 方法：

这里通过配置的ip , port ,appName 初始化了 XxlRpcProviderFactory，添加了  ExecutorBizImpl 执行类 ，继续往下看 start 方法: 

这里 使用一个守护线程启动了一个netty 的 http 服务端， 在接受到调度中心调度请求后，会执行  NettyHttpServerHandler 的channelRead0 方法：

这里采用一个线程池处理请求，继续往下看  process 方法：

这里的调度请求uri 不是包含 services ，所以我们直接看  this.xxlRpcProviderFactory.invokeService 方法 :

我们看到它会通过请求过来的类名作为key 获取对应的  serviceBean ，由上文 的     xxlRpcProviderFactory.addService(ExecutorBiz.class.getName(), null, new ExecutorBizImpl())  这个方法我们知道 serviceBean 是 ExecutorBizImpl ，methodName 为  run。通过反射调用 会去执行 ExecutorBizImpl 的 run 方法 ：

前面一段代码主要是 可以通过不同的脚本来执行对应的定时任务代码，默认是 GlueTypeEnum.BEAN ，这里的 newJobHandler会在 XxlJobSpringExecutor 初始化start方法时 放进 XxlJobExecutor 的 jobHandlerRepository 中：

 也就是通过注解的 @JobHandler(value="demoJobHandler") 的 demoJobHandler类

我们直接看 XxlJobExecutor.registJobThread 方法 ：

这里会 实例化一个  JobThread 线程去调用，直接看其 run 方法 ：

这里直接会执行对应的   handler.execute ，在本例中也就是  DemoJobHandler 的 execute 方法：

我们继续回到  ExecutorBizImpl 的 run  方法中的最后一段 ：

将其放进触发器队列中，返回  ReturnT.SUCCESS 执行完成。

到这里，一次xxl-job 定时任务就处理完成了

 

扩展与发散：

上面解析了xxl-job 定时任务执行一次的过程，核心就是调度中心通过rpc请求调用执行器去执行一次任务。

其他的rpc框架依然通过类似的方式执行的，例如我们熟知的 dubbo 的服务之间的调用也是通过类似的方式执行rpc请求调用的， 只不过dubbo是采用的tcp请求，还有 springcloud 通过feign来完成各个服务之间的调用，底层也是通过动态代理+http调用的方式完成的。我们可以发散一下，java 基本所有的rpc框架都是通过类似的方式，还有thrift 和 java 的RMI等，可能会有一些扩展功能如负载、失败重试、监控、熔断、限流、降级、容灾等，但是核心就是通过rpc请求完成的。

 

总结：

xxl-job 底层就是通过封装quartz+netty http封装的rpc框架来完成每一次分布式定时任务的执行，源码调用的简易流程图如下: