1、Quartz任务调度的基本实现原理
Quartz是OpenSymphony开源组织在任务调度领域的一个开源项目，完全基于Java实现。作为一个优秀的开源调度框架，Quartz具有以下特点：
（1）强大的调度功能，例如支持丰富多样的调度方法，可以满足各种常规及特殊需求；
（2）灵活的应用方式，例如支持任务和调度的多种组合方式，支持调度数据的多种存储方式；
（3）分布式和集群能力，Terracotta收购后在原来功能基础上作了进一步提升。本文将对该部分相加阐述。
1.1 Quartz 核心元素
Quartz任务调度的核心元素为：Scheduler——任务调度器、Trigger——触发器、Job——任务。其中trigger和job是任务调度的元数据，scheduler是实际执行调度的控制器。
Trigger是用于定义调度时间的元素，即按照什么时间规则去执行任务。Quartz中主要提供了四种类型的trigger：SimpleTrigger，CronTirgger，DateIntervalTrigger，和NthIncludedDayTrigger。这四种trigger可以满足企业应用中的绝大部分需求。
Job用于表示被调度的任务。主要有两种类型的job：无状态的（stateless）和有状态的（stateful）。对于同一个trigger来说，有状态的job不能被并行执行，只有上一次触发的任务被执行完之后，才能触发下一次执行。Job主要有两种属性：volatility和durability，其中volatility表示任务是否被持久化到数据库存储，而durability表示在没有trigger关联的时候任务是否被保留。两者都是在值为true的时候任务被持久化或保留。一个job可以被多个trigger关联，但是一个trigger只能关联一个job。
Scheduler由scheduler工厂创建：DirectSchedulerFactory或者StdSchedulerFactory。第二种工厂StdSchedulerFactory使用较多，因为DirectSchedulerFactory使用起来不够方便，需要作许多详细的手工编码设置。Scheduler主要有三种：RemoteMBeanScheduler，RemoteScheduler和StdScheduler。
Quartz核心元素之间的关系如图1.1所示：
图1.1 核心元素关系图
1.2 Quartz 线程视图
在Quartz中，有两类线程，Scheduler调度线程和任务执行线程，其中任务执行线程通常使用一个线程池维护一组线程。
图1.2 Quartz线程视图
fire now OR wait for the next fire)。
1.3 Quartz Job数据存储
Quartz中的trigger和job需要存储下来才能被使用。Quartz中有两种存储方式：RAMJobStore,JobStoreSupport，其中RAMJobStore是将trigger和job存储在内存中，而JobStoreSupport是基于jdbc将trigger和job存储到数据库中。RAMJobStore的存取速度非常快，但是由于其在系统被停止后所有的数据都会丢失，所以在集群应用中，必须使用JobStoreSupport。
2、Quartz集群原理
2.1 Quartz 集群架构
一个Quartz集群中的每个节点是一个独立的Quartz应用，它又管理着其他的节点。这就意味着你必须对每个节点分别启动或停止。Quartz集群中，独立的Quartz节点并不与另一其的节点或是管理节点通信，而是通过相同的数据库表来感知到另一Quartz应用的，如图2.1所示。
图2.1 Quartz集群架构
2.2 Quartz集群相关数据库表
因为Quartz集群依赖于数据库，所以必须首先创建Quartz数据库表，Quartz发布包中包括了所有被支持的数据库平台的SQL脚本。这些SQL脚本存放于<quartz_home>/docs/dbTables 目录下。这里采用的Quartz 1.8.4版本，总共12张表，不同版本，表个数可能不同。数据库为mysql，用tables_mysql.sql创建数据库表。全部表如图2.2所示，对这些表的简要介绍如图2.3所示。
图2.2 Quartz 1.8.4在mysql数据库中生成的表
图2.3 Quartz数据表简介
2.2.1 调度器状态表（QRTZ_SCHEDULER_STATE）
说明：集群中节点实例信息，Quartz定时读取该表的信息判断集群中每个实例的当前状态。
instance_name：配置文件中org.quartz.scheduler.instanceId配置的名字，如果设置为AUTO,quartz会根据物理机名和当前时间产生一个名字。
last_checkin_time：上次检入时间
checkin_interval：检入间隔时间
2.2.2 触发器与任务关联表（qrtz_fired_triggers）
存储与已触发的Trigger相关的状态信息，以及相联Job的执行信息。
2.2.3 触发器信息表（qrtz_triggers)
trigger_name：trigger的名字,该名字用户自己可以随意定制,无强行要求
trigger_group：trigger所属组的名字,该名字用户自己随意定制,无强行要求
job_name：qrtz_job_details表job_name的外键
job_group：qrtz_job_details表job_group的外键
trigger_state：当前trigger状态设置为ACQUIRED,如果设为WAITING,则job不会触发
trigger_cron：触发器类型,使用cron表达式
2.2.4 任务详细信息表（qrtz_job_details）
说明：保存job详细信息,该表需要用户根据实际情况初始化
job_name：集群中job的名字,该名字用户自己可以随意定制,无强行要求。
job_group：集群中job的所属组的名字,该名字用户自己随意定制,无强行要求。
job_class_name：集群中job实现类的完全包名,quartz就是根据这个路径到classpath找到该job类的。
is_durable：是否持久化,把该属性设置为1，quartz会把job持久化到数据库中
job_data：一个blob字段，存放持久化job对象。
2.2.5权限信息表（qrtz_locks）
说明：tables_oracle.sql里有相应的dml初始化，如图2.4所示。
图2.4 Quartz权限信息表中的初始化信息
2.3 Quartz Scheduler在集群中的启动流程
schedulerStarted()方法，它告诉JobStore Scheduler已经启动了。schedulerStarted() 方法是在JobStoreSupport类中实现的。JobStoreSupport类会根据quartz.properties文件中的设置来确定Scheduler实例是否参与到集群中。假如配置了集群，一个新的ClusterManager类的实例就被创建、初始化并启动。ClusterManager是在JobStoreSupport类中的一个内嵌类，继承了java.lang.Thread，它会定期运行，并对Scheduler实例执行检入的功能。Scheduler也要查看是否有任何一个别的集群节点失败了。检入操作执行周期在quartz.properties中配置。
2.4 侦测失败的Scheduler节点
当一个Scheduler实例执行检入时，它会查看是否有其他的Scheduler实例在到达他们所预期的时间还未检入。这是通过检查SCHEDULER_STATE表中Scheduler记录在LAST_CHEDK_TIME列的值是否早于org.quartz.jobStore.clusterCheckinInterval来确定的。如果一个或多个节点到了预定时间还没有检入，那么运行中的Scheduler就假定它(们) 失败了。
2.5 从故障实例中恢复Job
当一个Sheduler实例在执行某个Job时失败了，有可能由另一正常工作的Scheduler实例接过这个Job重新运行。要实现这种行为，配置给JobDetail对象的Job可恢复属性必须设置为true（job.setRequestsRecovery(true)）。如果可恢复属性被设置为false(默认为false)，当某个Scheduler在运行该job失败时，它将不会重新运行；而是由另一个Scheduler实例在下一次触发时间触发。Scheduler实例出现故障后多快能被侦测到取决于每个Scheduler的检入间隔（即2.3中提到的org.quartz.jobStore.clusterCheckinInterval）。
