小课堂 | 浅谈Quartz任务调度 – 作者:jordanx-安全小百科

基本简介

随着项目的横向发展，不同服务间的交互增多，某些需求需要系统自动或者定时执行任务。企业自主研发一个定时服务耗时耗力还容易出现问题，而此时选择用一个成熟的第三方应用直接投入更为便捷、优质。Quartz 是一个完全由Java开发的开源的任务日程管理系统，是在一个预定的时间负责执行（通知）其他软件的组件系统。

功能介绍

能够嵌入到任务独立的应用中运行
能够在服务器或者Servlet容器中实例化，并且能够参与XA事务
能够独立的方式运行（在自己的Java虚拟机中）
可以被实例化独立程序的集群（有负载均衡和容错能力）
任务是任何实现简单Job接口的Java类，这样开发者能够执行任何完成他们工作的任务。
Quartz 设计中包括了一个JobStore接口，这样，实现这个接口的Job类可以以多种机制实现Job的存储

Quartz的使用

1.Scheduler

使用Scheduler之前应首先实例化它，使用SchedulerFactory可以完成Scheduler的实例化。有些Quartz用户将工厂类的实例放在JNDI中存储，其他用户可以直接实例化这个工厂类并且直接使用工厂的实例。一旦一个Scheduler被实例化，它就可以被启动(start),并且处于驻留模式，直到被关闭(shutdown)。注意，一旦Scheduler被关闭（shutdown）,则它不能再重新启动，除非重新实例化它。除非Scheduler被启动或者不处于暂停状态，否则触发器不会被触发(任务也不能被执行)。

2.Jobs & JobDetails & Trigger

Scheduler 相关的事件包括：增加Job 或者 Trigger,移除 Job 或者Trigger, Scheduler内部发生的错误，Scheduler的通知将被关闭。

SchedulerListeners在调度程序的ListenerManager中注册，SchedulerListeners几乎可以实现任何监听接口的对象。

3.JobStores

JobStore 负责保持对所有Scheduler“工作数据”的追踪，这些工作数据包括：Ob（任务）Trigger（触发器）Calendar(日历)等。为Quartz Scheduler 选择合适的 JobStore 是非常重要的一步，幸运的是，当理解了不同的JobStore之间的差别，那么选择就变得非常简单。在提供产生 Scheduler 实例的SchedulerFactory的属性文件中声明Scheduler所使用的 JobStore（以及它的配置）。

RAMJobStore

配置简单，速度快，但程序停止，数据丢失

JDBCJobStore

配置略微复杂，可以保存数据

RAMjobStore 配置比较简单只需要做如下配置：

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

然后直接启动项目正常运行即可

JDBCjobStore 配置文件如下：

JDBCJobStore 几乎可以在任何数据库上工作，它广泛地使用 Oracle, MySQL, MS SQLServer, HSQLDB, PostgreSQL以及 DB2。要使用 JDBCJobStore，首先必须创建一套Quartz所需的数据库表，可以在 Quartz 的 Docs/dbTables 找到创建库表的 SQL 脚本。如果没有找到数据库类型的脚本，那么找到一个已有的，修改成所需要的即可。需要注意的一件事情就是所有 Quartz库表名都以QRTZ_作为前缀（例如表”QRTZ_TRIGGERS”,及”QRTZ_JOB_DETAIL”），实际上，设置前缀只要告诉JDBCJobStore是什么即可（在 Quartz 属性文件中配置）。对于一个数据库中使用多个Scheduler实例，那么配置不同的前缀可以创建多套库表，十分有用。

4.Clustering 集群

设置”org.quartz.jobStore.isClustered”属性为true才可以进行集群，集群中的每个实例都使用quartz.properties的相同拷贝。集群使用的属性文件机制是一致的，下面是被允许的例外：不同的线程池数量，”org.quartz.scheduler.instanceId”的不同属性值。集群中的每个节点必须有唯一的instanceId，通过替换这个属性的值为”AUTO”就可以轻松做到。