Quartz 2.2.3持久化

JobStore持久化（第一篇）

1.Job存储

我们所讨论的与Scheduler有关的Job和Trigger保存到哪里了呢，默认是以保存在内存里，但是如果我们为了解决一些生产上的问题，不得不采取数据库存储。

2.Quartz的Job存储

Quartz支持两种不同类型的存储机制：
- 内存（持久化）存储
- 持久化存储
   默认情况下是以内存存储

3.JobStore接口

Quartz为所有的Job存储提供了一个接口，即org.quartz.sqp.JobStore

该接口的API可以分为：
- Job相关的API
- Trigger相关的API
- Calendar相关的API
- Scheduler相关的API

4.使用内存来存储Scheduler

Quartz的内存Job存储是以org.quartz.simpl.RAMJobStore来处理实现的。该类是持久化的默认方式，好处有：
 - RAMJobStore配置简单
 - 有默认配置，可以不再配置  
 - 走的是内存，所以存储速度快
 当我们使用Quartz时候，其实已经默认配置使用了RAMJobStore，它是在默认的quartz.properties中可以看到，如下是从/org/quartz/quartz.properties中提取的截图：

4.1 配置quartz的RAMJobStore

参考上面的quartz.properties的截图，我们仅需要配置如下即可：
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

4.2加载Job到RAMJobStore中

RAMJobStore 的目的是存储 Scheduler 信息，那么那些信息一开始是如何被加载到内存中的呢？有两种方式：
- 硬编码Job，Trigger,Calendar和Listener到代码中。
- 使用插件JobInitializationPlugin

4.3RAMJobStore缺点

掉电或者程序宕了，我们的Job也就没有

5.使用持久化的JobStore

Quartz提供了两种持久化JobStore，而其带来的所有持久化的JobStore都扩展自org.quartz.impl.jdbcjobstore.JobStoreSupport 类。

5.1JobStoreSupport类

 public abstract class JobStoreSupport implements JobStore, Constants
 该类是一个抽象类，它为所有的JobStore提供了基本的功能，下面是类图：

6.开始为Job使用数据库存储

6.1独立环境中的持久化存储

JobStoreTX类设计为用于独立环境中。这里“独立”指不存在与应用容器的事务集成。它不是设计来让它的事务受到容器管理。区别就是Quzrtz的事务是否要参加到容器的事务中去。

6.2程序容器中的持久性存储

JobStoreCMT类设计当你想要程序容器爱为你的JobStore管理事务时，并且那些事务要参与到容器管理的事务边界中时使用。他的名字来源于（Contain Managed Transactions），就是CMT了

7.创建Quartz数据库结构

Quartz需要12张数据库的表，表的功能如下：

所有表的都是以QRTZ_开始，如果不想用这个。可以更改quartz.properties，来更改前缀。
表的存放位置是在distribute分发文件的/docs/dbTables 位置上。

8.使用JobStoreTX

如果我们构建的JavaEE项目并不适用到应用服务器，例如webLogic或者JBoss，那么JobStoreTX无疑是正确的选择。

8.1配置JobStoreTX

①告知Quartz使用JobStoreTX来持久化，而不是RAMJobStore
org.quartz.jobStore.class = org.quartz.ompl.jdbcjobstore.JobStoreTX
②配置驱动代理
JDBC API依赖于专属于某个数据库平台的JDBC驱动，同样Quartz也需要给定数据库的驱动，才可以使用数据库。
所有的DriverDelegate类都继承自org.quartz.impl.jdbcjobstore.StdDriverDelegate类。StdDriverDelegate只有所有代理可用的，与平台数据库无关的基本功能，因此我们需要配置针对平台的特定代理。

8.3配置数据库表的前缀

默认的表的前缀是QRTZ_，我们假设要自定义表前缀，那么就像下面标识：
org.quartz.jobStore.tablePrefix = 前缀_
PS:数据库表和列的命名
   假使你还有所疑惑，数据库表的名字(除却前缀) 和表的列名定义在 org.quartz.impl.jdbcjobstore.Constants 接口中。这个接口为 JobStoreSupport 类所实现，因而那些常量值在 JobStoreTX 或 JobStoreCMT 类中是可用的。 

8.4其他可调的配置属性

org.quartz.jobStore.driverDelegateClass
描述：能理解不同数据库系统中某一特定方言的驱动代理
org.quartz.jobStore.dataSource
描述：用于 quartz.properties 中数据源的名称
org.quartz.jobStore.tablePrefix    默认值：QRTZ_
描述：指定用于 Scheduler 的一套数据库表名的前缀。假如有不同的前缀，Scheduler 就能在同一数据库中使用不同的表。
org.quartz.jobStore.userProperties   默认值：False
描述：："use properties" 标记指示着持久性 JobStore 所有在 JobDataMap 中的值都是字符串，因此能以 名-值 对的形式存储，而不用让更复杂的对象以序列化的形式存入 BLOB 列中。这样会更方便，因为让你避免了发生于序列化你的非字符串的类到 BLOB 时的有关类版本的问题。
org.quartz.jobStore.misfireThreshold   默认值：60000ms
描述：很重要的一个属性，设置一个超时时间30分钟，假设任务在11点执行，但是11点前宕机了，我们在11点30之前重启了，那么超时时间没有超过30分钟，所以还是可以执行的，但是如果11点30前没启动程序起来，那么就不会再执行了。这个参数在内存持久化中也可以用。
org.quartz.jobStore.isClustered     默认值：False
描述：设置为 true 打开集群特性。如果你有多个 Quartz 实例在用同一套数据库时，这个属性就必须设置为 true。
org.quartz.jobStore.clusterCheckinInterval   默认值：15000ms
描述：设置一个频度(毫秒)，用于实例报告给集群中的其他实例。这会影响到侦测失败实例的敏捷度。它只用于设置了 isClustered 为 true 的时候。
org.quartz.jobStore.maxMisfiresToHandleAtATime  默认值:20
这是 JobStore 能处理的错过触发的 Trigger 的最大数量。处理太多(超过两打) 很快会导致数据库表被锁定够长的时间，这样就妨碍了触发别的(还未错过触发) trigger 执行的性能。
org.quartz.jobStore.dontSetAutoCommitFalse   默认值；False
描述：设置这个参数为 true 会告诉 Quartz 从数据源获取的连接后不要调用它的 setAutoCommit(false) 方法。这在少些情况下是有帮助的，比如假如你有这样一个驱动，它会抱怨本来就是关闭的又来调用这个方法。这个属性默认值是 false，因为大多数的驱动都要求调用 setAutoCommit(false)。
org.quartz.jobStore.selectWithLockSQL
默认值：SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE
描述：这必须是一个从 LOCKS 表查询一行并对这行记录加锁的 SQL 语句。假如未设置，默认值就是 SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE，这能在大部分数据库上工作。{0} 会在运行期间被前面你配置的 TABLE_PREFIX 所替换。
org.quartz.jobStore.txIsolationLevelSerializable默认值：False
描述：值为 true 时告知 Quartz(当使用 JobStoreTX 或 CMT) 调用 JDBC 连接的 setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) 方法。这有助于阻止某些数据库在高负载和长时间事物时锁的超时。

9.为JobStoreTX创建数据源

当使用持久化，必然用到数据库，数据源扮演者产生数据连接工厂的角色。在java中，所有的数据源都要事先java.sql.Datasource接口。Quartz本身不提供数据源，而是接触第三方例如Cpmmons DBCP或者通过JNDI查找应用服务器中定义的DataSource。
当我们使用JobStoreTX时，必须在quartz.properties文件中指定DataSource属性。这允许Quartz为你创建并管理Datasource。下面是我们需要配置的属性：
org.quartz.dataSource.NAME.driver   必须
描述：JDBC 驱动类的全限名
org.quartz.dataSource.NAME.URL      必须
描述：连接到你的数据库的 URL(主机，端口等)
org.quartz.dataSource.NAME.user
描述：用于连接你的数据库的用户名
org.quartz.dataSource.NAME.password
描述：用于连接你的数据库的密码
org.quartz.dataSource.NAME.maxConnections     
描述：DataSource 在连接接中创建的最大连接数 
org.quartz.dataSource.NAME.validationQuary     
描述：一个可选的 SQL 查询字串，DataSource 用它来侦测并替换失败/断开的连接。例如，Oracle 用户可选用 select table_name from user_tables，这个查询应当永远不会失败，除非直的就是连接不上了。 
注意：上面列出的每一个属性，你需要用你选择的名字替换掉属性的 NAME 部分。只要保证 Datasource 的所有属性的 NAME 部分相同就行了。这个名字用于唯一的标识 Datasource。假如你需要配置多个 Datasource (在使用 JobStoreCMT 时你将会这么做)，每一个 Datasource 应该有一个唯一的 NAME 值。
下面是简易版的properties配置：
org.quartz.dataSource.atp.driver = 
org.quartz.dataSource.atp.URL = 
org.quartz.dataSource.atp.user = pass
org.quartz.dataSource.atp.password = pass
org.quartz.dataSource.atp.maxConnections = 10 
我们还是需要指定一个datasource来让上面的配置对于Quartz的JobStoreTX是可用的，那么就必须加上如下的配置：
org.quartz.jobStore.DataSource = atp
这个值然后会传递给 JobStoreSupport 并且对于你的 JobStoreTX 就可用了，这样连接就可以被获取并传递到 DriverDelegate 实例。

10.应用JobStoreTX运行Quartz

        Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();
    //创建JobDetail
    JobDetail jobDetail = JobBuilder.newJob(UltraJob.class).withIdentity(jobName, JOB_GROUP_NAME).build();
    //创建时间表
    CronScheduleBuilder cronBuilder = CronScheduleBuilder.cronSchedule(cronExpression);
    //创建Trigger
    CronTrigger cronTrigger = TriggerBuilder.newTrigger().withIdentity(jobName, TRIGGER_GROUP_NAME).startNow()
                                        .withSchedule(cronBuilder)
                                        .build();       
    //将job加入到jobDataMap
    JobDataMap jobDataMap = jobDetail.getJobDataMap();
    //将任务和Trigger添加到scheduler
    scheduler.scheduleJob(jobDetail, cronTrigger);

11.使用数据库存储Scheduler信息

`存储Scheduler信息，有三种方式：
①插件形式：JobInitializationPlugin
②使用Quartz web应用程序，比如spring集成
③SQL工具加载信息，不推荐