分布式定时任务elastic-job(四)

目录

目录.png

---

分布式定时任务系列

• 分布式定时任务elastic-job(一)
• 分布式定时任务elastic-job(二)
• 分布式定时任务elastic-job(三)
• 分布式定时任务elastic-job(四)

---

自诊断恢复

• 解决分布式作业不一致状态ReconcileService，AbstractScheduledService是guava提供的，scheduler方法配合runOneIteration，定时操作

  
  
  ReconcileService.png
• 如果是主作业节点 而且 当前作业不需要重新分片 而且 查询是包含有分片节点的不在线服务器，那么设置需要重新分片的标记。这样达到自诊断修复

// 定时每分钟执行的方法
@Override
protected void runOneIteration() throws Exception {
   LiteJobConfiguration config = configService.load(true);
   int reconcileIntervalMinutes = null == config ? -1 : config.getReconcileIntervalMinutes();
   if (reconcileIntervalMinutes > 0 && (System.currentTimeMillis() - lastReconcileTime >= reconcileIntervalMinutes * 60 * 1000)) { // 校验是否达到校验周期
       // 设置最后校验时间
       lastReconcileTime = System.currentTimeMillis();
       // 主作业节点 而且 当前作业不需要重新分片 而且 查询是包含有分片节点的不在线服务器
       if (leaderService.isLeaderUntilBlock() 
               && !shardingService.isNeedSharding() 
               && shardingService.hasShardingInfoInOfflineServers()) {
           log.warn("Elastic Job: job status node has inconsistent value,start reconciling...");
           // 设置需要重新分片的标记
           shardingService.setReshardingFlag();
       }
   }
}

// 定时每分钟执行
@Override
protected Scheduler scheduler() {
    return Scheduler.newFixedDelaySchedule(0, 1, TimeUnit.MINUTES);
}

---

事件追踪

• 基于guava的EventBus实现，是一种优雅的观察者模式实现方式。
• 两种作业事件
  JobStatusTraceEvent, 作业状态追踪事件，比如五个分片就记录一条, 整体的状态
  JobExecutionEvent, 作业执行追踪事件，比如五个分片记录每个分片执行的情况
• JobEventRdbStorage, 作业事件数据库存储, 存储时是用jdbc执行的，基于数据库的操作，查询也是基于数据库查询
• 当然也可以自定义事件追踪，比如es实现，通过配置JobEventConfig中JobEventListener自定义就可以实现了

// JobEventBus注册监听器，不同监听器可以实现不同的存储方式，比如默认的关系型数据库存储
private void register() {
    try {
        eventBus.register(jobEventConfig.createJobEventListener());
        isRegistered = true;
    } catch (final JobEventListenerConfigurationException ex) {
        log.error("Elastic job: create JobEventListener failure, error is: ", ex);
    }
}

---

elastic-job cloud

• 额外提供了进程隔离之类的，瞬时任务提供进程级调度场景mesos是c++写的, 瞬时任务是cloud提供的能力，长时间执行资源不紧张时，创建进程，执行完，销毁进程，nginx也是进程级的
• elastic-Job-cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理, 应用分发以及进程隔离等服务

---

elastic-job的一些思考

• 用分布式锁进行失效任务拿取是为了集群能力能提供服务，有master节点是为了分配分片之类的这样就不用每次获取分布式锁了，简单高效
• elastic-job异常情况

1. 扩容收容 有监听
2. 宕机
3. zk失连 又连上
4. 分片时节点下线，先选主再分片

• 这种主节点选举方式有可能脑裂？实际上elastic-job用了zk分布式锁，zk分布式锁后续可以深入研究下，zk本身也能防止脑裂，而且连不上zk的作业服务器将立刻停止执行作业，防止主节点已重新分片，而脑裂的服务器还在执行
• elastic-job无中心的思想，cloud是中心化外提供了高级特性
• elastic-job通过zk节点变化感知服务上线下线，连接失连，感知后，可以通过代码保证高可用

---

分布式定时任务技术选型

quartz

• 不提供分布式

xxl-job

• 基于数据库，瓶颈在数据库，适合服务时的情况，服务量大，数据库压力大，性能下降，个人维护

elastic-job

• lite无中心化，适合服务多，量大，性能不受数据库影响，当当维护贡献给apache了

其他

• 其他的开源框架文档少

总结

• 借用参考文章7的图

  
  
  总结.png

---

参考文章

1. 脑裂是什么？Zookeeper是如何解决的？
2. Kafka研究系列之kafka 如何避免脑裂？如何选举leader
3. 如何防止ElasticSearch集群出现脑裂现象
4. elastic-job调度模型
5. 芋道源码-elastic-job
6. Quartz原理解密
7. 分布式定时任务调度系统技术选型