ElasticJob 社区在经过之前几年的停滞状况之后并入到apache，并且作为 Apache ShardingSphere 的子项目继续发光发热，终于迎来了它的3.0时代，作为一个老码农我也赶紧跟着时代的脚本，进行了一次深入学习和研究，这里记录下学习笔记。
首先elasticjob底层还是基于quartz实现的，熟悉quartz的朋友都知道quartz有三个非常重要的概念：
1、scheduler是一个计划调度器容器，容器里面可以有众多的JobDetail和trigger，当容器启动后，里面的每个JobDetail都会根据trigger按部就班自动去执行。
2、JobDetail是一个可执行的工作，它本身可能是有状态的。
3、Trigger代表一个调度参数的配置，什么时候去调。
当JobDetail和Trigger在scheduler容器上注册后，形成了装配好的作业（JobDetail和Trigger所组成的一对儿），就可以伴随容器启动而调度执行了。
scheduler是个容器，容器中有一个线程池，用来并行调度执行每个作业，这样可以提高容器效率。
elasticjob3.0.0相较之前不同之处
1、通过阅读官网发现elasticjob3.0.0新增了http类型的作业，可以直接调用http请求，并在请求头中将分片上下文以json串的形式传递，同时也增加了HttpJobExecutor来支撑HttpJob的执行
我们看看官网上的一段代码
文档关于这部分的介绍就寥寥数笔，没有写得很细致。
不过通过自己写个demo来体验再加上结合之前用ElasitcJob的经验仔细想想，个人总结了一下这样做的好处：之前都是将job任务处理的核心逻辑集中在job服务本身，job不仅要负责调度还需要处理核心业务逻辑，这样做之后job服务本身只需关注任务的调度和管理，核心逻辑可以分离到其他服务中去，有助于缕清微服务盛行的当下业务边界问题同时减少job服务本身的压力。
2、job监听器采用SPI的方式由ElasticJobServiceLoader来进行加载和管理
再来看官网上的一段代码
上面就调用了ScheduleJobBootstrap类的schedule()方法，job的启动就是从这里开始的，我们看看这个方法
继续跟进去发现是调用了JobScheduleController的scheduleJob(String corn)方法
发现调用了scheduler的start方法，而scheduler是quartz的任务调度器，到这里就接上了quartz的任务调度过程，有没有瞬间就懂了？
接下来我们关注下job的线程池，查看了下demo在执行job的调用栈
关注一下SimpleThreadpool，QuartzSchedulerThread，JobRunShell，LiteJob这4个类
其中QuartzSchedulerThread是一个线程类，负责查询并触发Triggers，该线程类的主要工作分为以下几个步骤：
1、等待QuartzScheduler启动
2、查询待触发的Trigger
3、等待Trigger触发时间到来
4、触发Trigger
5、循环上述步骤
具体的源码我将在单独的文章中进行解析，这里不再展开。
在底部发现由quartz的SimpleThreadpool拉起的，而这个线程池是由StdSchedulerFactory完成初始化的
看下StdSchedulerFactory的instantiate()方法，SimpleThreadpool和QuartzSchedulerThread都是这个方法中初始化的
可以看到QuartzScheduler构造方法中初始化了QuartzSchedulerThread并在线程池中启动
我们看下QuartzSchedulerThread的run方法
这里getThreadPool获取的线程池就是前面所述的 SimpleThreadPool，调用runInThread方法传入JobRunShell线程对象，并将JobRunShell赋值给SimpleThreadPool内部类定义的工作线程 ，进入runInThread方法之后启动了SimpleThreadPool内部类定义的工作线程
在WorkThread的run方法中调用了JobRunShell的run方法，
这里的job就是LiteJob
这里实际上调用的是ElasticJobExecutor的execute方法，进入到方法里面
1、检查job执行环境
2、job执行前的处理
3、正常执行job
4、如果发生misfire则执行job
5、job执行后的处理
这里2和5就是调用ElasticJobListener进行处理的，经过轮询监听器然后调用对应的方法跟进execute方法最后发现调用的是JobItemExecutor.process方法 ，那前面我们知道有 SimpleJob、DataFlowJob、ScriptJob、HttpJob四种不同类型的作业，这个方法是怎么处理这四种不同的作业的呢？然后JobItemExecutor也是elasitcJob提供的一个接口，也是采用SPI的方式进行扩展的 ，根据不同的job类型加载不同的作业处理器进行对应作业的处理，我们来看看它的类结构
有兴趣的同学可以看看对应的job处理器是怎么处理作业的，这里就不再展开了。
