简介
经常在网上看别人的源码分析，但大家的思路路径一般不一致，所以往往看归看，忘归忘。刚好最近项目用到了定时任务，所以借此深入了解下quartz。
从使用开始讲起
简单使用
如何使用分为两个部分：quartz独立使用，和Spring结合使用。之所以分开，是因为spring的存在，虽然增加了易用性，但掩盖了大量细节，影响了我们对程序的直观感觉。quartz独立使用的例子可以参见 深入解读Quartz的原理，基本流程就是
- 创建Job
- 创建Trigger
- 创建Scheduler（工厂模式），
scheduleJob(jobDetail, strigger)。 - 最后，
Scheduler.start()和scheduler.shutdown(true)，quartz就开始工作了。
quartz和spring的结合也非常的简单，上述第一步到第三步可由配置文件代替，第4步中的Scheduler则随着spring容器的启动而启动，停止而停止。Spring对程序的介入几乎没有，开发人员只要告诉配置文件什么时间运行哪个类的哪个方法即可。
Spring与其它框架的结合，往往从代码上改变了框架的使用“感觉”。其实，spring的本质是ioc（及其基础上的aop），spring为框架提供的“方便”主要是ioc提供的，包括bean的生成，生命周期的管理（比如quartz的scheduler随着ioc容器的启动而启动，shutdown而shutdown）等，并不会改变框架（所提供类的）的使用方式（即一些接口方法的调用）。
动态调度
public interface Scheduler{
// 默认变量或常量的设置
// 属性的设置与获取(增删改查job与trigger、calendar)
// 调度器本身的控制
void start() throws SchedulerException;
void startDelayed(int seconds) throws SchedulerException;
void standby() throws SchedulerException;
void shutdown() throws SchedulerException;
void shutdown(boolean waitForJobsToComplete)
void clear() throws SchedulerException;
// 任务的调度
Date scheduleJob(JobDetail jobDetail, Trigger trigger)
Date scheduleJob(Trigger trigger) throws SchedulerException;
void scheduleJobs(Map<JobDetail, Set<? extends Trigger>> triggersAndJobs, boolean replace) throws SchedulerException;
void scheduleJob(JobDetail jobDetail, Set<? extends Trigger> triggersForJob, boolean replace) throws SchedulerException;
boolean unscheduleJob(TriggerKey triggerKey)
boolean unscheduleJobs(List<TriggerKey> triggerKeys)
Date rescheduleJob(TriggerKey triggerKey, Trigger newTrigger)
void triggerJob(JobKey jobKey)
void triggerJob(JobKey jobKey, JobDataMap data)
//// 暂停与恢复job的调度
void pauseJob(JobKey jobKey)
void pauseJobs(GroupMatcher<JobKey> matcher) throws SchedulerException;
void pauseTrigger(TriggerKey triggerKey)
void pauseTriggers(GroupMatcher<TriggerKey> matcher) throws SchedulerException;
void resumeJob(JobKey jobKey)
void resumeJobs(GroupMatcher<JobKey> matcher) throws SchedulerException;
void resumeTrigger(TriggerKey triggerKey)
void resumeTriggers(GroupMatcher<TriggerKey> matcher) throws SchedulerException;
void pauseAll() throws SchedulerException;
void resumeAll() throws SchedulerException;
//// 中断job
boolean interrupt(JobKey jobKey) throws UnableToInterruptJobException;
boolean interrupt(String fireInstanceId) throws UnableToInterruptJobException;
}
通过观察上层的Scheduler接口即可发现，只要我们提供相应的数据类，便可以自如的控制任务的状态。
如果quartz对调度信息进行了持久化，Scheduler相关类还可以作为Quartz调度信息的dao类。
程序 = 数据结构 + 算法
尼古拉斯·沃斯（Niklaus Wirth）（专门搜了人名）说了：程序=数据结构+算法。以这个角度切入，我们来分析下quartz如何工作。从quartz的较低版本的最简单例子入手，参见深入解读Quartz的原理中的quartz demo代码。
-
从
scheduler.scheduleJob(JobDetail jobDetail,Trigger trigger)入手，发现这个方法只是做了一些数据的存储和通知listener的工作。其中比较重要的一点是调用了QuartzScheduler.notifySchedulerThread方法，这说明有一个SchedulerThread负责执行工作。结合到“一个程序的执行，必然会有初始化数据部分”。那么，这个初始化数据的部分在哪里，启动SchedulerThread的部分又在哪里？ -
第一点先按下不表，既然scheduler.scheduleJob没有看到任务的执行，那么看看
Scheduler.start()做了什么。在这个方法中，我们发现了QuartzSchedulerThread schedThread成员，它是一个Thread类，理所当然，分析下它的run方法，while循环的主要逻辑是：- 找下一个要触发的trigger
- 等着这个trigger运行
- 根据trigger拿到相应的组件TriggerFiredBundle，触发相应任务的执行（使用JobRunShell实际执行），QuartzSchedulerThread本身不管。
在代码当中，还发现了一个
QuartzSchedulerResources qsRsrcs提供了run方法操作的必要数据，其初始化代码在QuartzSchedulerThread构造方法中，顺着构造方法的调用链，发现其最终在DirectSchedulerFactory.createScheduler被构造。
这样，quartz的基本逻辑就清楚了，QuartzSchedulerResources基本封装了quartz运行的基本数据，然后由一个QuartzSchedulerThread不断的检查数据状态，触发最近的下一个任务执行。有意思的是，Scheduler本身不执行任务，只是将job和trigger存入到QuartzSchedulerResources中，并向QuartzSchedulerThread发送信号而已（以这样一种方式，为开发人员提供了操作quartz的入口）。
那么，这个发送信号和接收信号的过程值得研究下（其实就是两个线程通信的过程）。回到Date scheduleJob(JobDetail jobDetail,Trigger trigger)方法的实现
Date scheduleJob(JobDetail jobDetail,Trigger trigger){
// 数据判空等
// 关键操作
resources.getJobStore().storeJobAndTrigger(jobDetail, trig);
notifySchedulerListenersJobAdded(jobDetail);
notifySchedulerThread(trigger.getNextFireTime().getTime());
notifySchedulerListenersSchduled(trigger);
// 返回值
}
protected void notifySchedulerThread(long candidateNewNextFireTime) {
if (isSignalOnSchedulingChange()) {
signaler.signalSchedulingChange(candidateNewNextFireTime);
}
}
signaler是一个SchedulerSignaler接口，其实现类SchedulerSignalerImpl有一个构造方法SchedulerSignalerImpl(QuartzScheduler sched, QuartzSchedulerThread schedThread)，原来它保有了一个QuartzSchedulerThread引用。这里的线程通信，只是一个线程保有了另一个线程的引用。不过，线程归线程，线程对象归线程对象，两个线程不可以互操作，线程对象却可以。毕竟，线程只是一个方法的执行体，而线程对象或者说对象，却是一个方法和数据的结合体，不是一个维度的概念。
显然，这个Scheduler ==> SchedulerSignaler ==> QuartzSchedulerThread控制流要比Scheduler ==> QuartzSchedulerThread清晰很多。
使用建议
- 尽量持久化。在生产环境中，项目会因为迭代版本而多次重启。任务调度信息如果没有“记住”，那么项目重新启动时，就会有意料之外的行为发生。
layout: post title: 分布式定时 category: 技术 tags: Java keywords:quartz
分布式定时
问题描述
一个数据库表记录有不同的状态值，定时从中拉取符合条件的状态值的记录，处理（调用其它业务的rpc，进行数据的增删改），然后更新数据库。
对于一个定时任务，单机环境存在负载有限及可靠性问题。
在集群环境中，同样的定时任务，在集群中的每台机器都会执行，这样定时任务就会重复执行，不但会增加服务器的负担，还会因为定时任务重复执行造成额外的不可预期的错误（对同一个增加rpc操作进行多次调用）
在分布式定时任务中（或者集群），同一时刻只会有一个定时任务运行。
那如何做到，一会儿定时任务这个机器上运行，一会儿在那个机器上运行呢？
思维方式问题
找到“元问题”的思维方法之一：回到需求本身，而不是改进现有方案。
笔者在第一次碰到这个问题的时候，直观的感觉就是分布式锁，然后就陷入了分布式锁的各种方案的取舍中，分布式锁的三种实现的对比。