Quartz的故障恢复

     在默认的情况下，Quartz中所提交的任务都是独立的运行在内存中的线程，这意味着一旦机器出现故障或任何原因这个线程被干掉，那么提交的任务就无法继续也无法恢复。如果我们想要在系统出现故障的情况下恢复Quartz中的任务，就要把当前任务状态持久化，然后在系统恢复之后恢复任务的执行，这就是基本的解决思路。Quartz在这方面也提供了支持。

 

     首先，持久化的问题。要进行恢复就要将任务进行的状态保存下来，Quartz内置了数据库持久化的模块，我们要做的只是在配置文件中增加数据源，并在数据库中手动建好表就可以了。在%Quartz_HOME%/docs/dbTables目录下有大部分数据的建表语句，可以直接拿到数据库中进行建表操作。

 

 

org.quartz.jobStore.misfireThreshold=60000
org.quartz.dataSource.DATA_SOURCE_NAME.driver=com.mysql.jdbc.Driver
org.quartz.dataSource.DATA_SOURCE_NAME.URL=jdbc:mysql://host:port/dbname
org.quartz.dataSource.DATA_SOURCE_NAME.user=root
org.quartz.dataSource.DATA_SOURCE_NAME.password=
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.dataSource=DATA_SOURCE_NAME

    配置好以后再启动Quartz，就会发现提交的任务在相应的数据库表中可以找到，Quartz已经把任务的状态都记录下来了。

 

    剩下的恢复操作就很简单了，我们只要设置一个监听器（Tomcat、Spring中都有类似的模块，如果没有用到Tomcat、Spring的话也可以在自己的系统中设置启动的入口），在系统启动的时候去数据库中找到提交的任务，然后重新交给Quartz去管理就可以了。JobDetail类中有requestsRecovery属性，默认是false，当设置为true时，重新提交之后Quartz会检测当前的任务时候错过了应该触发的时间，如果错过了会立即触发一个任务。

 

    对于有状态的任务，如果需要保存任务中所传递的参数，则需要让工作类实现StateFulJob接口，这样Quartz在进行持久化的时候会把参数也保存下来，以便恢复。

 

    在系统启动的时候，启动quartz，quartz就会从数据库里恢复之前持久化的任务信息，错过触发时间，trigger有一系列的应对策略，这里在声明触发器的时候要设置好，如trigger.setMisfireInstruction(Trigger.INSTRUCTION_RE_EXECUTE_JOB);

 

public void recovery() {
        Scheduler scheduler = null;

        try {
            SchedulerFactory sf = new StdSchedulerFactory();
            scheduler = sf.getScheduler();

            scheduler.start();
        } catch (SchedulerException e) {
            e.printStackTrace();
        }
    }

 

 

 

PS： 评论里有同学说设置了requestsRecovery属性以后不需要重新提交，LZ作了 测试，确实是这样的，Quartz启动的时候会自动把持久化的任务提取出来执行，scheduler.rescheduleJob这个方法是用来以当前时间为基准来调整下一次触发的时间。如果没有调用这个方法的话，恢复的任务会假设自己处在系统退出前的时间，把错过的执行次数一次性全部执行一遍。

 

 

 

 

 

 

 

评论

18 楼 须等待 2013-12-09  

heathcliffchen 写道

StdSchedulerFactory schFac = new StdSchedulerFactory();
Scheduler scheduler = schFac.getScheduler();
scheduler.start();

我按上面的写了后，为什么没见数据库的已有的任务自动开始调度

怎样在系统启动的时候去数据库中找到提交的任务，然后重新交给Quartz去管理？

配置文件里有一条是选择任务的持久化方式，这里要设置好quartz把任务持久化到数据库，你系统启动的时候启动quartz就会自动去数据库里把持久化的任务拿出来，该重跑的重跑，该调度的调度

17 楼 heathcliffchen 2013-12-09  

StdSchedulerFactory schFac = new StdSchedulerFactory();
Scheduler scheduler = schFac.getScheduler();
scheduler.start();

我按上面的写了后，为什么没见数据库的已有的任务自动开始调度

怎样在系统启动的时候去数据库中找到提交的任务，然后重新交给Quartz去管理？

16 楼 heathcliffchen 2013-12-09  

StdSchedulerFactory schFac = new StdSchedulerFactory();
Scheduler scheduler = schFac.getScheduler();
scheduler.start();

我按上面的写了后，为什么没见数据库的已有的任务自动开始调度

15 楼 须等待 2013-05-29  

liaochengfeng 写道

十分感谢， 关于次数计算， 我发现触发器每次的触发时间不那么准确，有时会有些偏差， 所以有点担心，以最后触发时间计算错过次数，会不那么准确

多线程环境下时间点误差是无法避免的额。。

14 楼 liaochengfeng 2013-05-29  

十分感谢， 关于次数计算， 我发现触发器每次的触发时间不那么准确，有时会有些偏差， 所以有点担心，以最后触发时间计算错过次数，会不那么准确

13 楼 须等待 2013-05-29  

liaochengfeng 写道

你好，我已配置好持久化，并设置了JobDetail的RequestsRecovery属性为true。
但是目前的现象是， 停机时错过多次任务的触发，但是重启后只恢复了一次。
请问，怎样才能达到 “把错过的执行次数一次性全部执行一遍。”呢？

谢谢了

我映像中quartz应该是在启动的时候检查数据库里持久化的任务发现错过了就执行，并不会去计算错过多少次，你可以在任务被触发的时候手动检查一下上次触发的时间，然后自己去计算错过了多少次，然后根据你自己的业务来手动触发任务

12 楼 liaochengfeng 2013-05-29  

你好，我已配置好持久化，并设置了JobDetail的RequestsRecovery属性为true。
但是目前的现象是， 停机时错过多次任务的触发，但是重启后只恢复了一次。
请问，怎样才能达到 “把错过的执行次数一次性全部执行一遍。”呢？

谢谢了

11 楼 Shen.Yiyang 2012-11-20  

须等待 写道

Shen.Yiyang 写道

须等待 写道

Shen.Yiyang 写道

如果你的job已经是requestsRecovery，难道quartz不会自动recover吗？还需要重新提交？

好吧，看来我之前的理解还是有偏差，我作了一些测试：即使没有requestsRecovery属性，只要配置了持久化信息，Quartz都会把Job的信息存如数据库，并且在启动的时候恢复数据库中的所有任务。

我说重新提交指的是scheduler.rescheduleJob(t, groupName, trigger);  方法，这个方法会以当前时间为基准调整下次触发的时间，不调用也可以恢复任务，但是这时恢复的任务会假设自己还是处在系统退出前的时间状态，会把错误的没有执行的次数一次性执行一遍。

  如果你的requestsRecovery是false，并且你没有rescheduleJob，难道quartz不会以现在为基准，去触发下一次？

不仅仅是触发下一次，是触发很多个下一次，执行（now-last）/period次

我这样问好了，如果没有reschedule，也没有requestsRecovery，但是job已经存在数据库了，服务器重启以后quartz会怎么运行，和你的reschedule有什么不同？

10 楼 须等待 2012-11-20  

Shen.Yiyang 写道

须等待 写道

Shen.Yiyang 写道

如果你的job已经是requestsRecovery，难道quartz不会自动recover吗？还需要重新提交？

好吧，看来我之前的理解还是有偏差，我作了一些测试：即使没有requestsRecovery属性，只要配置了持久化信息，Quartz都会把Job的信息存如数据库，并且在启动的时候恢复数据库中的所有任务。

我说重新提交指的是scheduler.rescheduleJob(t, groupName, trigger);  方法，这个方法会以当前时间为基准调整下次触发的时间，不调用也可以恢复任务，但是这时恢复的任务会假设自己还是处在系统退出前的时间状态，会把错误的没有执行的次数一次性执行一遍。

  如果你的requestsRecovery是false，并且你没有rescheduleJob，难道quartz不会以现在为基准，去触发下一次？

不仅仅是触发下一次，是触发很多个下一次，执行（now-last）/period次

9 楼 zhongliangjun1 2012-11-20  

hot66hot 写道

看看项目中使用Quartz集群分享.
传送门:http://hot66hot.iteye.com/blog/1726143

优质链接，马一个了~

8 楼 Shen.Yiyang 2012-11-20  

须等待 写道

Shen.Yiyang 写道

如果你的job已经是requestsRecovery，难道quartz不会自动recover吗？还需要重新提交？

好吧，看来我之前的理解还是有偏差，我作了一些测试：即使没有requestsRecovery属性，只要配置了持久化信息，Quartz都会把Job的信息存如数据库，并且在启动的时候恢复数据库中的所有任务。

我说重新提交指的是scheduler.rescheduleJob(t, groupName, trigger);  方法，这个方法会以当前时间为基准调整下次触发的时间，不调用也可以恢复任务，但是这时恢复的任务会假设自己还是处在系统退出前的时间状态，会把错误的没有执行的次数一次性执行一遍。

  如果你的requestsRecovery是false，并且你没有rescheduleJob，难道quartz不会以现在为基准，去触发下一次？

7 楼 须等待 2012-11-20  

coffeesweet 写道

呵呵，我觉得说的挺仔细的，算作自己学习的文章吧，挺好，一点一点慢慢积累。

6 楼 coffeesweet 2012-11-20  

呵呵，我觉得说的挺仔细的，算作自己学习的文章吧，挺好，一点一点慢慢积累。

5 楼 Bsklqgy 2012-11-20  

    

4 楼 须等待 2012-11-20  

Shen.Yiyang 写道

如果你的job已经是requestsRecovery，难道quartz不会自动recover吗？还需要重新提交？

好吧，看来我之前的理解还是有偏差，我作了一些测试：即使没有requestsRecovery属性，只要配置了持久化信息，Quartz都会把Job的信息存如数据库，并且在启动的时候恢复数据库中的所有任务。

我说重新提交指的是scheduler.rescheduleJob(t, groupName, trigger);  方法，这个方法会以当前时间为基准调整下次触发的时间，不调用也可以恢复任务，但是这时恢复的任务会假设自己还是处在系统退出前的时间状态，会把错误的没有执行的次数一次性执行一遍。

3 楼 freezingsky 2012-11-19  

我以为是讲什么新鲜的。

2 楼 hot66hot 2012-11-19  

看看项目中使用Quartz集群分享.
传送门:http://hot66hot.iteye.com/blog/1726143

1 楼 Shen.Yiyang 2012-11-19  

如果你的job已经是requestsRecovery，难道quartz不会自动recover吗？还需要重新提交？