Quartz集群增强版_01.集群及缺火处理(ClusterMisfireHandler)

Quartz集群增强版_01.集群及缺火处理(ClusterMisfireHandler)

转载请著名出处 https://www.cnblogs.com/funnyzpc/p/18542452

主要目的

• 应用(app)与节点(node)状态同步

  不管是 node 还是 app，都可以通过对应 state 来控制节点及整个应用的启停，这是很重要的功能，同时对于集群/缺火的锁操作也是基于 app 来做的，同时附加在 app 上的这个锁是控制所有应用及集群之间的并发操作，同样也是很重要的~

• 任务状态与执行状态更新

  因为任务扫描主要操作的是执行时间项(execute)信息，同时变更的也是执行项的状态(state)，故此需要更新任务(job)状态

• 熄火任务恢复执行

  任务扫描调度的过程可能存在 GC 及 DB断连 的情况，需要及时修正 next_fire_time 以保证在异常恢复后能正常被扫到并被执行

• 清理历史记录

  清理的执行频度很低，如果可以的话建议是后管接入 click sdk 手动操作，这里的自动清理是兜底方案，基于数据库锁的任务并发在表数据越少时性能理论上就越好~ ，自动清理有两大任务：

  • 1.清理执行无效应用及非执行节点
  • 2.清理任务及执行配置

• 创建应用及执行节点

这是必要的操作，预创建节点及应用方便后续管理，同时执行调度也依赖于节点及应用的状态

前置处理

前置处理指的是 Quartz 启动时必做的维护，主要包含三部分主要内容：

• 01.写入应用（app） 及 节点（node） ，这是很重要的
• 02.恢复/更新应用状态

• 将执行中或异常的 job 拿出来并检查其关联的执行项，通过执行项（execute）的状态更新任务（job）状态,如果
  
  多执行项存在多个状态，状态的优先级为（从高到低）：ERROR->EXECUTING->PAUSED->COMPLETE
  
  代码表象为 :

 List<QrtzExecute> executes = getDelegate().getExecuteByJobId(conn,job.getId());
      boolean hasExecuting = false;
      boolean hasPaused = false;
      boolean hasError = false;
      boolean hasComplete = false;
      for( QrtzExecute execute:executes ){
          final String state = execute.getState();
          if("EXECUTING".equals(state)){
              hasExecuting=true;
          }else if("PAUSED".equals(state)){
              hasPaused=true;
          }else if("ERROR".equals(state)){
              hasError=true;
          }else if("COMPLETE".equals(state)){
              hasComplete=true;
          }else{
              continue; // 这里一般是INIT
          }
      }
      // 如果所有状态都有则按以下优先级来
      String beforeState = job.getState();
      if(hasError){
          job.setState("ERROR");
      }else if(hasExecuting){
          job.setState("EXECUTING");
      }else if(hasPaused){
          job.setState("PAUSED");
      }else if(hasComplete){
          job.setState("COMPLETE");
      }else{
          continue; // 这里对应上面的INIT状态，不做处理
      }
      // 不做无谓的更新...
      if(!job.getState().equals(beforeState)){
          job.setUpdateTime(now);
          getDelegate().updateRecoverJob(conn,job);
      }

• 03.恢复/更新执行状态

获取当前应用下的所有执行中或异常的任务(job),并逐步恢复任务下所有执行中(EXECUTING)或异常(ERROR)的任务，主要是重新计算 next_fire_time

后置处理

• 01.后置处理的内容是包含所有前置处理，同时对集群并发做了加锁 （这个很重要，后一段会讲到）
• 02.同步节点状态与应用状态不一致的问题
• 03.更新 check 标志，这个 check 标志主要方便于后续清理之使用,同时 app 上的 check (time_next) 是作为锁定周期的判断依据

？关于并发锁的处理

这个问题可以详细说明一下，一般一个loop（循环）是 15s(TIME_CHECK_INTERVAL) ,在集群环境中同时存在多个节点的并发问题，所以对集群及缺火的处理就存在重复执行

一开始我的思考是按照乐观锁的思路来做，代码大概是这样的：

    int ct = getDelegate().updateQrtzAppByApp(conn,app);
    // 5.获取app锁的才可执行 clear 清理以及 recover 恢复，以减少读写
    if( ct>0 ){
      // 获取到锁后的处理
    }

但是这样存在重复执行的情况，具体情况先看图：

上图中node1 与 node2 的开始时间相差5s，所以造成了他们获取锁的时间存在5s的时间差异，因为有这5s的存在，多个节点几乎都可以执行这个update语句以获取锁，这样往下的逻辑必然存在重复执行！

任务调度扫描(QuartzSchedulerThread)是统一等到 next_fire_time 的那一刻来竞争锁，而集群/缺火处理(ClusterMisfireHandler)在一个 while 的大循环内 这个循环每次是15s，所以每个节点的所执行的周期是15s(TIME_CHECK_INTERVAL)，而锁的竞争却是在执行 update 的那一刻

如果借用 任务扫描（QuartzSchedulerThread ）的处理思路就是 再加一个 while 或者 sleep 等待到下一个 check_time（time_next）,代码将如下:

    long t=0;
    // 这里的 check_time 就是应用的check时间，loop_time则是当前循环开始时间
    if( (t=check_time-loop_time)> 0 ){
      Thread.sleep(t);
    }
    int ct = getDelegate().updateQrtzAppByApp(conn,app);
    // 5.获取app锁的才可执行 clear 清理以及 recover 恢复，以减少读写
    if( ct>0 ){
      // 获取到锁后的处理
    }

以上这样就可以可以基本保证多个node在同一时间竞争同一把锁了... ，这样做还有一个好处，就是基本保证了各个节点的 ClusterMisfireHandler 的循环时间基本一致，同时通过sleep可以随机打散循环时间（添加偏移量）将

ClusterMisfireHandler 的循环处理打散在其他节点执行 。

但是，但是哦，如果使用 sleep + update 的方式 也可能导致同一时间加锁（update）竞争的开销，所以，我借鉴了 shedlock 开源项目的启发，就是思考能不能在竞争锁之前判断锁定时间，获取到锁之后加一个锁定时间

锁定时间内的不再去竞争锁，锁定时间外的则可以，大致如图：

看图，如果我们假定 node1 是先于 node2 执行， 当 node1 在 14:15 成功获取锁后 他的下一次执行时间预期就是 14:30 ,同时如果加一个10s的锁定时间(图中蓝线)，就是在 15:25 及之前是不可以去竞争锁，这样当

node2 在 14:20 去尝试获取锁之前发现最近一个锁定时间点是 14:25 (及之后) ，此时 node2 会自动放弃竞争锁（执行update），同时进入下一时间点 14:35 并再次判断锁定时间点儿，当然这并不是没有代价的，各位自行领悟吧

经过改造后的代码如下:

   // TIME_CHECK_INTERVAL 是循环周期，固定为15秒
   long tw = TIME_CHECK_INTERVAL/10*3;  // 70% 减少并发
   if( (app.getTimeNext()-_start)>tw ){
       continue;
   }

   // 5.获取app锁的才可执行 clear 清理以及 recover 恢复，以减少读写
   if( ct>0 ){
       // 获取到锁后的处理
   }