基于Netty+Zookeeper+Quartz调度分析

前言

前几篇文章分别从使用和源码层面对Quartz做了简单的分析，在分析的过程中也发现了Quartz不足的地方；比如底层调度依赖数据库的悲观锁，谁先抢到谁调度，这样会导致节点负载不均衡；还有调度和执行耦合在一起，导致调度器会受到业务的影响；下面看看如何来解决这几个问题；

思路

调度器和执行器拆成不同的进程，调度器还是依赖Quartz本身的调度方式，但是调度的并不是具体业务的QuartzJobBean，而是统一的一个RemoteQuartzJobBean，在此Bean中通过Netty远程调用执行器去执行具体业务Bean；具体的执行器在启动时注册到Zookeeper中，调度器可以在Zookeeper获取执行器信息，并通过相关的负载算法指定具体的执行器去执行，以下看简单的实现；

执行器

1.执行器配置文件

配置了执行器的名称，执行器启动的ip和端口以及Zookeeper的地址信息；

2.执行器服务

ExecutorServer通过Netty启动服务，并向Zookeeper注册服务，部分代码如下：

在Netty中指定了编码器解码器，同时指定了ExecutorServerHandler用来处理调度器发送来的消息（更多代码查看项目源码）；最后向Zookeeper注册服务，路径格式如下：

job_registry是固定值，firstExecutor是配置的具体执行器名称；

3.配置加载任务

添加注解类，用来指定具体的业务Job：

例如具体的业务Task如下所示：

在启动执行器服务时，加载有ExecutorTask注解的任务类，此处定义的name要和调度端的名称相互匹配；

4.执行具体业务

Netty中指定了ExecutorServerHandler用来处理接受的调度器信息，通过反射的方式来调用具体的业务Job，部分代码如下：

serviceName对应的就是定义的”firstTask”，然后通过serviceName找到对应的Bean，然后反射调用，最终返回结果；

调度器

调度器还是依赖Quartz的原生调度方式，只不过调度器不在执行相关业务Task，所以相关配置也是类似，同样依赖数据库；

1.定义调度任务

同样在调度端定义了名称问firstTask的任务，可以发现此类是RemoteQuartzJobBean，并不是具体的业务Task；同时也指定了jobDataMap，用来指定执行器名称和发现的Zookeeper地址；

2.RemoteQuartzJobBean

此类同样继承于QuartzJobBean，这样Quartz才能调度Bean，在此Bean中通过jobKey和executorBean创建了IJobHandler的代理类，具体代码如下：

在Request中指定了InterfaceName为jobKey.getName()，也就是这里的firstTask；通过Zookeeper发现服务时指定了executor.getExecutorName()，这样可以在Zookeeper中找到具体的执行器地址，当然这里的地址可能是一个列表，可以通过负载均衡算法(随机，轮询，一致性hash等等)进行分配，获取到地址后通过Netty远程连接执行器，发送执行job等待返回结果；

简单测试

分别执行调度器和执行器，相关日志如下：

1.执行器日志

2.调度器日志

总结

本文通过一个实例来分析如何解决原生Quartz调度存在不足的问题，主要体现在调度器与执行器的隔离上，各司其责发挥各自的优势；