可能很多胖友不了解 Elastic-Job 这个中间件。我们看一段其官方文档的介绍：
Elastic-Job 是一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。
Elastic-Job-Lite 定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。
Elastic-Job 基本是国内开源最好的调度任务中间件的几个中间件，可能没有之一，嘿嘿。目前处于有点“断更”的状态，具体可见 https://github.com/elasticjob/elastic-job-lite/issues/616 。
所以关于这块的示例，暂时先不提供。如果对 Elastic-Job 源码感兴趣的胖友，可以看看写的如下两个系列：
《芋道 Elastic-Job-Lite 源码分析系列》
《芋道 Elastic-Job-Cloud 源码分析系列》
① 如何选择？
了解下不同调度中间件的对比。表格如下：
也推荐看看如下文章：
《分布式定时任务调度系统技术选型》
《Azkaban、Xxl-Job 与 Airflow 对比分析》
目前的状况，如果真的不知道怎么选择，可以先尝试下 XXL-JOB 。
② 中心化 V.S 去中心化
下面，让我们一起来简单聊聊分布式调度中间件的实现方式的分类。一个分布式的调度中间件，会存在两种角色：
调度器：负责调度任务，下发给执行器。
执行器：负责接收任务，执行具体任务。
那么，如果从调度系统的角度来看，可以分成两类：
中心化： 调度中心和执行器分离，调度中心统一调度，通知某个执行器处理任务。
去中心化：调度中心和执行器一体化，自己调度自己执行处理任务。
如此可知 XXL-Job 属于中心化的任务调度平台。目前采用这种方案的还有：
链家的 kob
美团的 Crane（暂未开源）
去中心化的任务调度平台，目前有：
Elastic Job
唯品会的 Saturn
Quartz 基于数据库的集群方案
淘宝的 TBSchedule（暂停更新，只能使用阿里云 SchedulerX 服务）
如果胖友想要更加的理解，可以看看《中心化 V.S 去中心化调度设计》
③ 任务竞争 V.S 任务预分配
那么，如果从任务分配的角度来看，可以分成两类：
任务竞争：调度器会通过竞争任务，下发任务给执行器。
任务预分配：调度器预先分配任务给不同的执行器，无需进行竞争。
如此可知 XXL-Job 属于任务竞争的任务调度平台。目前采用这种方案的还有：
链家的 kob
美团的 Crane（暂未开源）
Quartz 基于数据库的集群方案
任务预分配的任务调度平台，目前有：
Elastic Job
唯品会的 Saturn
淘宝的 TBSchedule（暂停更新，只能使用阿里云 SchedulerX 服务）
一般来说，基于任务预分配的任务调度平台，都会选择使用 Zookeeper 来协调分配任务到不同的节点上。同时，任务调度平台必须是去中心化的方案，每个节点即是调度器又是执行器。这样，任务在预分配在每个节点之后，后续就自己调度给自己执行。
相比较而言，随着节点越来越多，基于任务竞争的方案会因为任务竞争，导致存在性能下滑的问题。而基于任务预分配的方案，则不会存在这个问题。并且，基于任务预分配的方案，性能会优于基于任务竞争的方案。
这里在推荐一篇 Elastic Job 开发者张亮的文章 《详解当当网的分布式作业框架 elastic-job》 ，灰常给力！
④ Quartz 是个优秀的调度内核
绝大多数情况下，我们不会直接使用 Quartz 作为我们的调度中间件的选择。但是，基本所有的分布式调度中间件，都将 Quartz 作为调度内核，因为 Quartz 在单纯任务调度本身提供了很强的功能。
不过呢，随着一个分布式调度中间件的逐步完善，又会逐步考虑抛弃 Quartz 作为调度内核，转而自研。例如说 XXL-JOB 在 2.1.0 RELEASE 的版本中，就已经更换成自研的调度模块。其替换的理由如下：
XXL-JOB 最终选择自研调度组件（早期调度组件基于 Quartz）；
一方面，是为了精简系统降低冗余依赖。
另一方面，是为了提供系统的可控度与稳定性。
在 Elastic-Job 3.X 的开发计划中，也有一项计划，就是自研调度组件，替换掉 Quartz 。
