分布式定时任务系列

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

自诊断恢复

解决分布式作业不一致状态ReconcileService，AbstractScheduledService是guava提供的，scheduler方法配合runOneIteration，定时操作
如果是主作业节点而且当前作业不需要重新分片而且查询是包含有分片节点的不在线服务器，那么设置需要重新分片的标记。这样达到自诊断修复

// 定时每分钟执行的方法
@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异常情况

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

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