quartz - misfire错过触发时机的处理-阿里云开发者社区

1. 引言

要弄清楚作业的misfire，首先需要了解几个重要的概念：

触发器超时：

举个例子说明这个概念。比如调度引擎中有5个线程，然后在某天的下午2点有6个任务需要执行，那么由于调度引擎中只有5个线程，所以在2点的时候会有5个任务会按照之前设定的时间正常执行，有1个任务因为没有线程资源而被延迟执行，这个就叫触发器超时。下面这些情况会造成触发器超时：

1）系统因为某些原因被重启。在系统关闭到重新启动之间的一段时间里，可能有些任务会被 misfire；

2）Trigger 被暂停（suspend）的一段时间里，有些任务可能会被 misfire；

3）线程池中所有线程都被占用，导致任务无法被触发执行，造成 misfire；

4）有状态任务在下次触发时间到达时，上次执行还没有结束；

misfireThreshold ：

misfireThreshold 即触发器超时的临界值，它可以在quartz.properties文件中配置。misfireThreshold是用来设置调度引擎对触发器超时的忍耐时间。假设misfireThreshold设置为6000(单位毫秒)，那么它的意思说当一个触发器超时时间大于misfireThreshold时，调度器引擎就认为这个触发器真正的超时(即Misfires)。换言之，如果一个触发器超时时间小于设定的misfireThreshold，那么调度引擎则不认为触发器超时。也就是说这个job并没发生misfire。

quartz.properties中的配置

#判定job为misfire的阈值，这里设置为4S
org.quartz.jobStore.misfireThreshold = 4000

那么，调度器对于触发器超时但是超时时间小于misfireThreshold 或者触发器已经misfire 的两种情况是怎么处理的呢？

2. 调度器怎么处理超时

2.1 timeout < misfireThreshold

为了制造超时的现象，实验时把线程池的大小设定为1，misfireThreshold设定为5S。实验中定义了两个job，一个是busy job，它在运行期休眠了3S（

//BusyJob.java
public class BusyJob implements Job {
    private final Logger logger = LoggerFactory.getLogger(BusyJob.class);

    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {

        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        String jobName = context.getJobDetail().getKey().getName();

        logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 开始执行");

        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 执行完毕");
    }

}

//TimeoutJob.java
public class TimeoutJob implements Job {
    private final Logger logger = LoggerFactory.getLogger(TimeoutJob.class);

    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {

        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        String jobName = context.getJobDetail().getKey().getName();

        logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 开始执行");

        logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 执行完毕");
    }

}

//TimeoutButNotMisfireTest.java
/**
 * 触发器超时，但没有misfire
 */
public class TimeoutButNotMisfireTest {

    public static void main(String[] args) throws SchedulerException, InterruptedException {

        Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();

        // busy job
        JobDetail busyJob = JobBuilder //
                .newJob(BusyJob.class)//
                .withIdentity("busy job", "group1")//
                .build();

        SimpleTrigger busyTrigger = TriggerBuilder //
                .newTrigger() //
                .withIdentity("busy job trigger", "group1")//
                .startNow() //
                .withPriority(5) // 高优先级
                .withSchedule(SimpleScheduleBuilder.simpleSchedule() //
                        .withRepeatCount(0) //
                ).build();
        scheduler.scheduleJob(busyJob, busyTrigger);

        // timeout job
        JobDetail timeoutJob = JobBuilder //
                .newJob(TimeoutJob.class)//
                .withIdentity("timeout job", "group2")//
                .build();

        SimpleTrigger timeoutTrigger = TriggerBuilder //
                .newTrigger() //
                .withIdentity("timeout job trigger", "group2")//
                .startNow() //立即触发
                .withPriority(1) // 低优先级
                .withSchedule(SimpleScheduleBuilder.simpleSchedule() //
                        .withIntervalInSeconds(1) //每隔1S触发一次
                        .withRepeatCount(7) // 循环7次
                ).build();
        scheduler.scheduleJob(timeoutJob, timeoutTrigger);

        scheduler.start();

        Thread.sleep(20 * 1000);

        scheduler.shutdown(true);

    }
}

运行结果：

INFO  11:31:11,420 com.github.thinwonton.quartz.sample.misfire.BusyJob: [busy job] 在  : [ 11:31:11] 开始执行
 INFO  11:31:14,420 com.github.thinwonton.quartz.sample.misfire.BusyJob: [busy job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,423 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,423 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,426 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,426 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:15,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:15] 开始执行
 INFO  11:31:15,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:15] 执行完毕
 INFO  11:31:16,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:16] 开始执行
 INFO  11:31:16,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:16] 执行完毕
 INFO  11:31:17,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:17] 开始执行
 INFO  11:31:17,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:17] 执行完毕
 INFO  11:31:18,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:18] 开始执行
 INFO  11:31:18,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:18] 执行完毕

通过观察运行结果，我们可以得到结论：

超时的触发器（超时时间小于misfireThreshold）在获取到运行线程后，将会立即运行前面错过的作业job，然后按照前面制定的周期性任务正常运行。

2.2 timeout >= misfireThreshold

对于触发器超时，并且超时时间大于设定的misfireThreshold 这种情况，调度器引擎为简单触发器SimpleTrigger和表达式CronTrigger提供了多种处理策略，我们可以在定义触发器时指定需要的策略。

2.2.1 对于SimpleTrigger的处理策略

MISFIRE_INSTRUCTION_FIRE_NOW ：调度引擎在MisFire的情况下，将任务(JOB)马上执行一次。需要注意的是这个指令通常被用做只执行一次的Triggers，也就是没有重复的情况（non-repeating），如果这个Triggers的被安排的执行次数大于0。那么这个执行与 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT 相同。
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT：调度引擎重新调度该任务，repeat count 保持不变，按照原有制定的执行方案执行repeat count次，但是，如果当前时间，已经晚于 end-time，那么这个触发器将不会再被触发。举个例子：比如一个触发器设置的时间是 10:00 执行时间间隔10秒重复10次。那么当10：07秒的时候调度引擎可以执行这个触发器的任务，然后按照原有制定的时间间隔执行10次。但是如果触发器设置的执行时间是10：00，结束时间为10：10，由于种种原因导致该触发器在10：11分才能被调度引擎触发，这时，触发器将不会被触发了。
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT：这个策略跟上面的 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 策略类似，唯一的区别就是调度器触发触发器的时间不是“现在” 而是下一个 scheduled time。
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT：这个策略跟上面的策略 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 比较类似，调度引擎重新调度该任务，repeat count 是剩余应该执行的次数，也就是说本来这个任务应该执行10次，但是已经错过了3次，那么这个任务就还会执行7次。
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT：这个策略跟上面的 MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT 策略类似，区别就是repeat count 是剩余应该执行的次数而不是全部的执行次数。比如一个任务应该在2:00执行，repeat count=5，时间间隔5秒，但是在2:07才获得执行的机会，那任务不会立即执行，而是按照机会在2点10秒执行。
MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY：这个策略跟上面的 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 策略类似，但这个策略是忽略所有的超时状态，快速执行之前错过的次数，然后再按照之前制定的周期触发触发器。举个例子，一个SimpleTrigger 每个15秒钟触发, 但是超时了5分钟才获得执行的机会，那么这个触发器会被快速连续调用20次，追上前面落下的执行次数。

2.2.2 对于CronTrigger的处理策略

MISFIRE_INSTRUCTION_FIRE_ONCE_NOW：指示触发器超时后会被立即安排执行。
MISFIRE_INSTRUCTION_DO_NOTHING：这个策略与策略 MISFIRE_INSTRUCTION_FIRE_ONCE_NOW 正好相反，它不会被立即触发，而是获取下一个被触发的时间，并且如果下一个被触发的时间超出了end-time 那么触发器就不会被执行。

文章转载自开源中国社区 [http://www.oschina.net]

quartz - misfire错过触发时机的处理

1. 引言

2. 调度器怎么处理超时

热门文章

最新文章

相关电子书