Elastic-Job项目源码分析4--核心执行器AbstractElasticJobExecutor

今天我们研究的话题是：eljob中提供了三种不同类型的job，它们是如何执行的？看官请跟我来

如果让你设计Job或JobExecutor，你怎么做？

~！@#￥%……&*（）——+
是不是还没有头绪？或许来参考Quartz的设计方案如Job、StatefulJob、QuartzScheduler，从结构上看，十分扁平，让程序员定制的程度很高，就导致了需要程序员关系的业务实体就变得复杂。
在我看来，不是需要一个框架有多强大，而需要的是能满足业务系统支撑，说得更奢华些就是适合中国国情的才行，所以我们走的是有中国特色的社会主义道路。

三种不同的执行器

在讲三种不同的执行器前，我们先来看看，我们的上游是什么？还记得我们第一次分析的LiteJob吗？

这里用了一个Factory来最终确定使用哪种类型的执行器来执行，因为不同的流程需要不同的执行器

再来看看三种Job类型

• 三种不同的Job分别对应的执行器

扁平的结构，一看重点在抽象类中，子类中一般只包含简单的特定方法，如这里的公共方法execute以及子类要实现的抽象方法 process，如下图A

总体流程

我们再来细细看看源码，在图A中阅读时，作者也从人性化的角度将代码的位置做了很好的调整。

前两个execute比较简单，我们来看下第一个process (主要看下分片处理，见我的注释)

再来看下第二个process

主要是在调用子类的process前后做了一些事件处理，加上execute中的监听器，整理如下图

SimpleJobExecutor

SimpleJobExecutor 是最具有代表性的执行器，覆盖了80%场景。
其内部直接调用了simpleJob.execute(shardingContext);

DataflowJobExecutor

数据流式执行器支持两种模式，一种是一次性的数据流，一种是连续的数据流处理；其实一次性的数据流处理是一种特殊的连续性数据流处理。我想因为是比较特殊，所以单独了出来

ScriptJobExecutor

script这个还是比较简单的，内部使用了apache的common-exec 包来执行的