【ElasticJob源码解析】任务调度器

作业需要执行，必然需要一个调度器，去统筹作业执行的逻辑，这也是ElasticJob的核心内容；ElasticJob依赖注册中心实现分片，所以调度器主要需要做的的事就是在任务启动的时候，将任务的信息写到注册中心，其次就是启动任务，具体的执行逻辑需要慢慢分析；

1，作业调度器-JobScheduler

首先来看看JobScheduler的构造器；

1.1，构造器

private JobScheduler(final CoordinatorRegistryCenter regCenter, 
                    final LiteJobConfiguration liteJobConfig, 
                    final JobEventBus jobEventBus, 
                    final ElasticJobListener... elasticJobListeners) {
    JobRegistry.getInstance().addJobInstance(liteJobConfig.getJobName(), new JobInstance());
    this.liteJobConfig = liteJobConfig;
    this.regCenter = regCenter;
    List elasticJobListenerList = Arrays.asList(elasticJobListeners);
    setGuaranteeServiceForElasticJobListeners(regCenter, elasticJobListenerList);
    schedulerFacade = new SchedulerFacade(regCenter, liteJobConfig.getJobName(), elasticJobListenerList);
    jobFacade = new LiteJobFacade(regCenter, liteJobConfig.getJobName(), Arrays.asList(elasticJobListeners), jobEventBus);
}

首先使用作业注册表JobRegistry注册当前的作业信息，标注唯一作业的方式是，使用ip地址+虚拟机进程+作业名称，来唯一标识某台机器上运行的某个项目的某个作业实例；
其实是为监听器设置值，这个以后再讲；
最后就是两个门面类的初始化赋值；

1.2，启动调度器-init

启动调度器使用的是init方法，这个方法可以理解为启动一个定时任务，只不过这个定时任务功能比较强大，不仅仅是简单的定时执行；

首先来看init方法：

public void init() {
    LiteJobConfiguration liteJobConfigFromRegCenter = schedulerFacade.updateJobConfiguration(liteJobConfig);
    JobRegistry.getInstance().setCurrentShardingTotalCount(liteJobConfigFromRegCenter.getJobName(), liteJobConfigFromRegCenter.getTypeConfig().getCoreConfig().getShardingTotalCount());
    JobScheduleController jobScheduleController = new JobScheduleController(
            createScheduler(), createJobDetail(liteJobConfigFromRegCenter.getTypeConfig().getJobClass()), liteJobConfigFromRegCenter.getJobName());
    JobRegistry.getInstance().registerJob(liteJobConfigFromRegCenter.getJobName(), jobScheduleController, regCenter);
    schedulerFacade.registerStartUpInfo(!liteJobConfigFromRegCenter.isDisabled());
    jobScheduleController.scheduleJob(liteJobConfigFromRegCenter.getTypeConfig().getCoreConfig().getCron());
}

第一行首先更新该作业的配置信息到注册中心，更新的条件是注册中心中，名为jobName+"config"的节点不存在，或者LiteJobConfiguration的overWrite字段设置为true时，会强制更新；
第二行代码是将本次作业的分片总数注册到注册表JobRegistry中；
然后构建一个作业调度器的控制器JobScheduleController，这个控制器，可以实现调度，暂停，恢复，关闭等操作，使用的是quartz的Scheduler来实现的，所以构造是需要一个Scheduler对象，同时还需要一个JobDetail对象，这两个对象后面讲；
控制器构造完成后，将控制器和注册中心注册到作业注册表（JobRegistry）中，也就是说这个注册表中包含了所有作业的所有信息，当后期需要时，可以从注册表中获取；
再然后使用门面装饰类schedulerFacade，注册初始化信息到注册中心，这里使用了装饰器模式，将大量的逻辑分在在里面，需要另开一篇讲解，总之他的任务就是讲作业的各项信息写到注册中心；
最后，使用作业调度器的控制器，启动调度操作，也就是启动定时任务，使用quartz来实现的；

再来看看作业调度器的控制器需要的JobDetail是如何构造的：

private JobDetail createJobDetail(final String jobClass) {
    JobDetail result = JobBuilder.newJob(LiteJob.class).withIdentity(liteJobConfig.getJobName()).build();
    result.getJobDataMap().put(JOB_FACADE_DATA_MAP_KEY, jobFacade);
    Optional elasticJobInstance = createElasticJobInstance();
    if (elasticJobInstance.isPresent()) {
        result.getJobDataMap().put(ELASTIC_JOB_DATA_MAP_KEY, elasticJobInstance.get());
    } else if (!jobClass.equals(ScriptJob.class.getCanonicalName())) {
        try {
            result.getJobDataMap().put(ELASTIC_JOB_DATA_MAP_KEY, Class.forName(jobClass).newInstance());
        } catch (final ReflectiveOperationException ex) {
            throw new JobConfigurationException("Elastic-Job: Job class '%s' can not initialize.", jobClass);
        }
    }
    return result;
}

构造方式很简单，使用一个builder对象，然后将elasticJob对象和jobFacade对象放置进去；
但是这里面还有一点很有意思的东西，newJob的对象LiteJob，他是quartz的job接口的实现类，他内部拥有两个属性elasticJob和jobFacade，而后面的代码向jobDataModel中（ELASTIC_JOB_DATA_MAP_KEY->elasticJob；JOB_FACADE_DATA_MAP_KEY->jobFacade）放置的也是这两个属性，quartz框架会将jobDataModel中的键值对赋值给newJob对象中对应的属性；
还需要注意的是，当jobClass为ScriptJob时，elasticJob是没有放置到jobDataModel中的，但是没关系，在LiteJob中调用的JobExecutorFactory在调用时，如果elasticJob为null，那么就默认执行ScriptJobExecutor；

再来看看Scheduler对象是如何构建：

 private Scheduler createScheduler() {
    Scheduler result;
    try {
        StdSchedulerFactory factory = new StdSchedulerFactory();
        factory.initialize(getBaseQuartzProperties());
        result = factory.getScheduler();
        result.getListenerManager().addTriggerListener(schedulerFacade.newJobTriggerListener());
    } catch (final SchedulerException ex) {
        throw new JobSystemException(ex);
    }
    return result;
}

private Properties getBaseQuartzProperties() {
    Properties result = new Properties();
    result.put("org.quartz.threadPool.class", org.quartz.simpl.SimpleThreadPool.class.getName());
    result.put("org.quartz.threadPool.threadCount", "1");
    result.put("org.quartz.scheduler.instanceName", liteJobConfig.getJobName());
    result.put("org.quartz.jobStore.misfireThreshold", "1");
    result.put("org.quartz.plugin.shutdownhook.class", JobShutdownHookPlugin.class.getName());
    result.put("org.quartz.plugin.shutdownhook.cleanShutdown", Boolean.TRUE.toString());
    return result;
}

这里注册了一个JobTriggerListener，用来设置任务被错过执行的标记；
JobShutdownHookPlugin是用来在Scheduler关闭的时候做扫尾工作的；

总结：

调度器的启动逻辑较为复杂，大量逻辑包含在内部尚未解析，但是他主要做的事：
- 向注册中心写入各种节点信息；
- 向作业注册表（JobRegistry）中，写入作业的各种信息；
- 构建并启动quartz的调度器，也就是启动定时任务，执行本次作业；

2，作业的具体执行

从上面代码也可以看出，每次定时任务出发的时候，quratz会调用，实现了Job接口的LiteJob类的execute方法，那么我们就从这儿开始看起；

public final class LiteJob implements Job {
    
    @Setter
    private ElasticJob elasticJob;
    
    @Setter
    private JobFacade jobFacade;
    
    @Override
    public void execute(final JobExecutionContext context) throws JobExecutionException {
        JobExecutorFactory.getJobExecutor(elasticJob, jobFacade).execute();
    }
}

上面也分析到了，这个类的构造器只有空构造函数，有quartz框架new出来，并且会设置elasticJob和jobFacade的值，值的来源是，构建JobDetail对象时，设置到jobDataMap中的同名属性；
然后使用JobExecutorFactory根据elasticJob的类型的不同挑选对应的作业执行器，代码如下；

public static AbstractElasticJobExecutor getJobExecutor(final ElasticJob elasticJob, final JobFacade jobFacade) {
        if (null == elasticJob) {
            return new ScriptJobExecutor(jobFacade);
        }
        if (elasticJob instanceof SimpleJob) {
            return new SimpleJobExecutor((SimpleJob) elasticJob, jobFacade);
        }
        if (elasticJob instanceof DataflowJob) {
            return new DataflowJobExecutor((DataflowJob) elasticJob, jobFacade);
        }
        throw new JobConfigurationException("Cannot support job type '%s'", elasticJob.getClass().getCanonicalName());
    }

在构建JobDetail时说过，如果作业类型为ScriptJob，那么elasticJob是没有值的，在此处，如果没有值，就返回ScriptJobExecutor，与之前相对应；
其他的，根据作业类型，获取相应的执行器，如果没有，直接报错；

2.1，简单作业执行器-SimpleJobExecutor

public final class SimpleJobExecutor extends AbstractElasticJobExecutor {
    
    private final SimpleJob simpleJob;
    
    public SimpleJobExecutor(final SimpleJob simpleJob, final JobFacade jobFacade) {
        super(jobFacade);
        this.simpleJob = simpleJob;
    }
    
    @Override
    protected void process(final ShardingContext shardingContext) {
        simpleJob.execute(shardingContext);
    }
}

这个类没什么讲的，只是向父类传递了一个参数，然后重写了一个方法，但是这个方法调用的是我们实现SimpleJob时复写的方法，也就是我们自己写的业务逻辑在此处执行；主要还是看看他的父类中干了什么，先来看看父类的构造器；

2.1.1，执行器的构造器

protected AbstractElasticJobExecutor(final JobFacade jobFacade) {
    this.jobFacade = jobFacade;
    jobRootConfig = jobFacade.loadJobRootConfiguration(true);
    jobName = jobRootConfig.getTypeConfig().getCoreConfig().getJobName();
    executorService = ExecutorServiceHandlerRegistry.getExecutorServiceHandler(jobName, (ExecutorServiceHandler) getHandler(JobProperties.JobPropertiesEnum.EXECUTOR_SERVICE_HANDLER));
    jobExceptionHandler = (JobExceptionHandler) getHandler(JobProperties.JobPropertiesEnum.JOB_EXCEPTION_HANDLER);
    itemErrorMessages = new ConcurrentHashMap<>(jobRootConfig.getTypeConfig().getCoreConfig().getShardingTotalCount(), 1);
}

根据子类传过来的JobFacade对象，获取JobRootConfig，JobName；
以及执行作业的线程池ExecutorService，和作业的异常处理器jobExceptionHandler，这两个不同类型的字段是通过同一方法（getHandler）获取的，值得借鉴；

private Object getHandler(final JobProperties.JobPropertiesEnum jobPropertiesEnum) {
    String handlerClassName = jobRootConfig.getTypeConfig().getCoreConfig().getJobProperties().get(jobPropertiesEnum);
    try {
        Class handlerClass = Class.forName(handlerClassName);
        if (jobPropertiesEnum.getClassType().isAssignableFrom(handlerClass)) {
            return handlerClass.newInstance();
        }
        return getDefaultHandler(jobPropertiesEnum, handlerClassName);
    } catch (final ReflectiveOperationException ex) {
        return getDefaultHandler(jobPropertiesEnum, handlerClassName);
    }
}

实现逻辑是这样的:

方法参数给定一个 JobProperties.JobPropertiesEnum 类型的参数作为默认值；
如果能从核心配置类（JobCoreConfiguration）中获取，定义作业配置的值，那么就使用配置的值，如果没有，或者配置的不是方法参数中期望的类型，那么就使用参数中的默认值；
获取默认值的方法如下；

private Object getDefaultHandler(final JobProperties.JobPropertiesEnum jobPropertiesEnum, final String handlerClassName) {
    log.warn("Cannot instantiation class '{}', use default '{}' class.", handlerClassName, jobPropertiesEnum.getKey());
    try {
        return Class.forName(jobPropertiesEnum.getDefaultValue()).newInstance();
    } catch (final ClassNotFoundException | InstantiationException | IllegalAccessException e) {
        throw new JobSystemException(e);
    }
}

2.1.2，执行器的execute方法

该方法逻辑比较长，Elasticjob也分成了几段来实现，我们就一段一段的看；

第一段

public final void execute() {
    try {
        jobFacade.checkJobExecutionEnvironment();
    } catch (final JobExecutionEnvironmentException cause) {
        jobExceptionHandler.handleException(jobName, cause);
    }
    ShardingContexts shardingContexts = jobFacade.getShardingContexts();
    if (shardingContexts.isAllowSendJobEvent()) {
        jobFacade.postJobStatusTraceEvent(shardingContexts.getTaskId(), State.TASK_STAGING, String.format("Job '%s' execute begin.", jobName));
    }
    if (jobFacade.misfireIfRunning(shardingContexts.getShardingItemParameters().keySet())) {
        if (shardingContexts.isAllowSendJobEvent()) {
            jobFacade.postJobStatusTraceEvent(shardingContexts.getTaskId(), State.TASK_FINISHED, String.format(
                    "Previous job '%s' - shardingItems '%s' is still running, misfired job will start after previous job completed.", jobName, 
                    shardingContexts.getShardingItemParameters().keySet()));
        }
        return;
    }
    try {
        jobFacade.beforeJobExecuted(shardingContexts);
        //CHECKSTYLE:OFF
    } catch (final Throwable cause) {
        //CHECKSTYLE:ON
        jobExceptionHandler.handleException(jobName, cause);
    }
    execute(shardingContexts, JobExecutionEvent.ExecutionSource.NORMAL_TRIGGER);
    while (jobFacade.isExecuteMisfired(shardingContexts.getShardingItemParameters().keySet())) {
        jobFacade.clearMisfire(shardingContexts.getShardingItemParameters().keySet());
        execute(shardingContexts, JobExecutionEvent.ExecutionSource.MISFIRE);
    }
    jobFacade.failoverIfNecessary();
    try {
        jobFacade.afterJobExecuted(shardingContexts);
        //CHECKSTYLE:OFF
    } catch (final Throwable cause) {
        //CHECKSTYLE:ON
        jobExceptionHandler.handleException(jobName, cause);
    }
}

首先检查本机与注册中心的时间误差秒数是否在允许范围；
- 如果maxTimeDiffSeconds配置为-1，表示不检查；
- 需要注意一点，即使误差过大，抛出异常，如果使用的是默认的异常处理器，那么也只是会打印error日志，而并不会阻碍程序；
然后获取分片上下文；
- 这里的获取到的分片逻辑有点复杂，在2.2中在来具体解释一下，因为涉及到了失效转移的问题；
- 如果没有失效转移，那么获取的分片就是当前实例在执行分片时获取的分片，去除标记了disable的分片；
然后判断，如果当前分片项仍在运行，是否需要设置任务被错过执行的标记；
- 如果需要设置，那么当前任务将被跳过，并设置任务被错过执行的标记；
- 如果不需要设置，那么接着执行后面的逻辑；
- 需要注意的是分片项是否正在运行的判断逻辑；
  - 首先根据LiteJobConfiguration中的monitorExecution字段判断是否监控执行，默认为true，如果为false，根本就不会设置错过执行，即使上一次的定时任务还在执行，这一次的定时任务也将启动执行；
  - 其次，本项目实例拿到的分片中，有任意一个分片还在运行中，那么所持有的所有分片，都将错过本次定时任务的执行；
然后执行监听器（ElasticJobListener）的beforeJobExecuted方法；
然后执行第二段逻辑，下面再讲；
然后判断作业是否需要执行错过的任务，如果需要，那么还是执行第二段逻辑；
被错过执行有两种情况：
- 开启了monitorExecution，发现上一次的任务还在执行中，那么本实例拿到的所有分片的这一次的定时任务都将被错过；
- 如果定时任务时间间距过小，如10秒，而任务执行了12秒，那么quartz会触发监听器JobTriggerListener，监听器会设置本作业实例的所有分片为错过执行；
然后判断如果需要失效转移, 则执行作业失效转移；
最后执行监听器的afterJobExecuted方法；

第二段

private void execute(final ShardingContexts shardingContexts, final JobExecutionEvent.ExecutionSource executionSource) {
    if (shardingContexts.getShardingItemParameters().isEmpty()) {
        if (shardingContexts.isAllowSendJobEvent()) {
            jobFacade.postJobStatusTraceEvent(shardingContexts.getTaskId(), State.TASK_FINISHED, String.format("Sharding item for job '%s' is empty.", jobName));
        }
        return;
    }
    jobFacade.registerJobBegin(shardingContexts);
    String taskId = shardingContexts.getTaskId();
    if (shardingContexts.isAllowSendJobEvent()) {
        jobFacade.postJobStatusTraceEvent(taskId, State.TASK_RUNNING, "");
    }
    try {
        process(shardingContexts, executionSource);
    } finally {
        // TODO 考虑增加作业失败的状态，并且考虑如何处理作业失败的整体回路
        jobFacade.registerJobCompleted(shardingContexts);
        if (itemErrorMessages.isEmpty()) {
            if (shardingContexts.isAllowSendJobEvent()) {
                jobFacade.postJobStatusTraceEvent(taskId, State.TASK_FINISHED, "");
            }
        } else {
            if (shardingContexts.isAllowSendJobEvent()) {
                jobFacade.postJobStatusTraceEvent(taskId, State.TASK_ERROR, itemErrorMessages.toString());
            }
        }
    }
}

该段代码如果monitorExecution属性没有开启，将不会有什么意义；
- 首先需要在注册中心中增加running节点，表示任务正在运行；
- 当处理完后，在finally中再将running移除；

第三段

private void process(final ShardingContexts shardingContexts, final JobExecutionEvent.ExecutionSource executionSource) {
    Collection items = shardingContexts.getShardingItemParameters().keySet();
    if (1 == items.size()) {
        int item = shardingContexts.getShardingItemParameters().keySet().iterator().next();
        JobExecutionEvent jobExecutionEvent =  new JobExecutionEvent(shardingContexts.getTaskId(), jobName, executionSource, item);
        process(shardingContexts, item, jobExecutionEvent);
        return;
    }
    final CountDownLatch latch = new CountDownLatch(items.size());
    for (final int each : items) {
        final JobExecutionEvent jobExecutionEvent = new JobExecutionEvent(shardingContexts.getTaskId(), jobName, executionSource, each);
        if (executorService.isShutdown()) {
            return;
        }
        executorService.submit(new Runnable() {
            
            @Override
            public void run() {
                try {
                    process(shardingContexts, each, jobExecutionEvent);
                } finally {
                    latch.countDown();
                }
            }
        });
    }
    try {
        latch.await();
    } catch (final InterruptedException ex) {
        Thread.currentThread().interrupt();
    }
}

这里对ShardingContexts中是否只包含了一个分片做了区分处理
- 如果只包含一个分片，比较好处理，直接进入第三段的处理即可；
- 如果包含多个分片，那么因为第二段代码是夹在第一段代码的监听器的两个方法中间执行的，必须要处理完所有的分片任务，才能执行监听器的afterJobExecuted方法；
- 这里使用了CountDownLatch对象，该对象在初始化的时候需要设置一个数量值，每调用一次countDown方法，则数量会减少1，如果值不为0，那么线程会一直阻塞在await方法处，此处是为了实现线程等待而使用的，等待所有分片任务执行完，再接着向下执行；

第四段

private void process(final ShardingContexts shardingContexts, final int item, final JobExecutionEvent startEvent) {
    if (shardingContexts.isAllowSendJobEvent()) {
        jobFacade.postJobExecutionEvent(startEvent);
    }
    log.trace("Job '{}' executing, item is: '{}'.", jobName, item);
    JobExecutionEvent completeEvent;
    try {
        process(new ShardingContext(shardingContexts, item));
        completeEvent = startEvent.executionSuccess();
        log.trace("Job '{}' executed, item is: '{}'.", jobName, item);
        if (shardingContexts.isAllowSendJobEvent()) {
            jobFacade.postJobExecutionEvent(completeEvent);
        }
        // CHECKSTYLE:OFF
    } catch (final Throwable cause) {
        // CHECKSTYLE:ON
        completeEvent = startEvent.executionFailure(cause);
        jobFacade.postJobExecutionEvent(completeEvent);
        itemErrorMessages.put(item, ExceptionUtil.transform(cause));
        jobExceptionHandler.handleException(jobName, cause);
    }
}

protected abstract void process(ShardingContext shardingContext);

这一段没什么逻辑，除了调用真实的业务逻辑外，就是发布一些事件；
真正执行的业务代码，由子类提供；

2.2，失效转移

首先来解释一下失效转移的含义:

就是在某个定时任务，从这一次开始运行，到下一次开始运行之前，这之间的时间段内，某一个或多个作业实例出现了问题（或者作业实例的部分分片出了问题），那么这些出问题的作业实例，这一次的定时任务就相当于没有执行，那么失效转移功能就会将这些没有执行的分片，转移到其他正常机器，马上触发执行；
当下一次任务的时间点到来时，开始重新分片，然后继续正常执行；

再来看看代码层面的实现：

首先是JobCrashedJobListener监听到了需要失效转移的分片项；
然后逐一设置失效的分片项标记，具体位置在注册中心的：{jobName}/leader/failover/items/{item};
然后开始逐一执行作业失效转移，先执行主节点选举争抢当前分片，然后执行回调；

public void executeInLeader(final String latchNode, final LeaderExecutionCallback callback) {
    try (LeaderLatch latch = new LeaderLatch(getClient(), jobNodePath.getFullPath(latchNode))) {
        latch.start();
        latch.await();
        callback.execute();
    //CHECKSTYLE:OFF
    } catch (final Exception ex) {
    //CHECKSTYLE:ON
        handleException(ex);
    }
}

回调使用的是FailoverLeaderExecutionCallback：
- 首先向{jobName}/sharding/{item}/failover中填充临时数据；
- 然后移除先前的{jobName}/leader/failover/items/{item}中的数据；
- 最后构建一个jobScheduleController对象，调用triggerJob方法，马上进行一次任务启动操作；

再来看看AbstractElasticJobExecutor中获取分片的逻辑：

public ShardingContexts getShardingContexts() {
    boolean isFailover = configService.load(true).isFailover();
    if (isFailover) {
        List failoverShardingItems = failoverService.getLocalFailoverItems();
        if (!failoverShardingItems.isEmpty()) {
            return executionContextService.getJobShardingContext(failoverShardingItems);
        }
    }
    shardingService.shardingIfNecessary();
    List shardingItems = shardingService.getLocalShardingItems();
    if (isFailover) {
        shardingItems.removeAll(failoverService.getLocalTakeOffItems());
    }
    shardingItems.removeAll(executionService.getDisabledItems(shardingItems));
    return executionContextService.getJobShardingContext(shardingItems);
}

如果开启了失效转移，那么就去获取{jobName}/sharding下所有item中的failover节点，并筛选出当前作业实例的failover，将这些failover对应的item构造成ShardingContexts直接返回；这里的执行逻辑，对应的是上面jobScheduleController对象调用triggerJob方法；
失效转移执行完成后，下一次再来获取分片的时候，会执行shardingIfNecessary方法，重新进行分片；