一、背景
本文档为解决分布式场景下定时任务重复执行的问题提供选型参考。其中大部分描述来自互联网资料整合，相关链接在文档底部。
主要需求如下：
1.避免重复执行
2.动态CRUD，如动态启停、业务中允许更新执行时间。
3.失效转移、负载均衡等分布式作业管理
4.定时任务管理，如查看当前任务列表、手动启停等。
5.日志回溯、异常报警等。
二、概览
经过检索找到如下几种用户群较多的候选框架。
quartz是最经典最著名的任务调度框架，其他候选至少初期都是基于它开发，进而改进了quartz的问题。
Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能。同时它通过独占锁来保证只有一个节点执行，没有负载均衡，并且需要持久化任务信息到业务数据表，有10张以上，对业务有侵入性。最后，调度和执行并存于同一个项目，相互影响性能。
结论：由于以上原因，实际场景不会直接选择quartz作为调度框架。
三、详细对比
对比内容 | xxl-job | elastic-job |
项目背景 | 大众点评开源项目 | 当当网开源项目 |
社区力量 | 18人/fork3289/公司180 | 17人/fork2252/公司50 |
文档 | 非常详细 | 详细 |
可视化 | 支持通过web页面对任务进行CRUD操作，支持报表及日志查看 | 支持通过web页面对任务进行CRUD操作，用户权限管理等 |
规则触发 | 时间触发和事件触发 | 时间触发 |
调度器集群部署 | 支持 | 支持 |
作业集群部署 | 支持 | 支持 |
日志追溯 | 支持，日志查询页面 | 通过事件订阅的方式处理调度过程的重要事件 |
报警 | 默认提供邮件失败告警，可扩展短信、钉钉等方式 | 实现报警接口 |
弹性扩容 | 使用quartz使用数据库的分布式供能，一旦有新执行器机器上线或下线，下次调度时将重新分配任务 | 通过zk实现各服务的注册、控制及协调，运行中的作业服务器崩溃，或新增n台作业服务器，将在下次作业前重新分片，不影响当前作业执行 |
阻塞策略 | 单机串行，丢弃后续调度，覆盖之前的调度 | Zk的session timeout超时。临时节点会被清除，作业才会重新分片 |
失败处理策略 | 失败告警、失败重试、故障转移 | 失败转移、被错过的任务重新触发 |
Spring整合 | Springboot启动，和spring整合简单 | |
支持并行调度 | 调度系统多线程触发调度运行，确保调度精确执行，不被阻塞 | 将一个任务分为多个小任务在多台服务器上执行 |
高可用 | 通过DB锁来保证集群分布式调度的一致性，一次任务调度只会触发一次，如果执行器集群中某一台机器故障，将会自动failover切换到正常机器 | 通过zk来保证集群分布式调度，调度器的高可用是通过运行几个指向同一个zk集群的Elastic-job-cloud-scheduler实例来实现的，zk用于当前主实例失败的情况下leader选举 |
自定义任务参数 | 支持在线配置调度任务入参，即时生效 | 在修改任务时，可以自定义参数 |
任务进度监控 | 支持实时监控任务进度 | 监控作业运行时状态，统计最近一段时间处理的数据成功和失败数量，记录作业上次运行begin Time，endTime，nextTime |
灰度发布 | 支持灰度发布 | |
容器部署 | 支持docker部署 | |
支持语言 | 任务开发语言不受限制 | 任务开发语言不受限制 |
生产支持 | 节点350+ 任务调度4000w/天 | |
分片广播任务 | 执行器集群部署时，任务路由策略选择“分片广播”情况下，一次任务调度将会触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务 | 通过zk实现分片，主节点进行分片，以下三种情况会触发执行分片： 1.新的job加入集群 2.现有job下线，如果下线的是leader节点，那么先选举然后触发分片算法执行 3.主节点选举 |
动态分片 | 分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理。在进行大数量业务操作时可显著提升任务处理速度和能力 |
|
依赖 | ZooKeeper，mesos（仅elasticjob-cloud） | |
易用性 | 一般 | 较复杂 |
使用场景 | 数据量较小、服务器较少的快速开发场景，主打轻量级。 | 注重数据设计，适合数据量大、服务器多的场景。 |
特有属性 | 资源分配，应用分发，进程级调度，瞬时任务，进程隔离。（Mesos自研框架实现） | |
共有属性 | 1.作业治理（失效转移，错过重新执行，自诊断修复，负载均衡） 2.弹性扩容，数据分片。 3.可视化管理，任务统计，日志，报警。 4.动态CRUD 5.与Spring、Dubbo配合良好。 | 1.作业治理（失效转移，错过重新执行，自诊断修复，负载均衡） 2.弹性扩容，数据分片。 3.可视化管理，任务统计，日志，报警。 4.动态CRUD 5.与Spring、Dubbo配合良好。 |
四、结论
XXL-Job 侧重于业务实现的简单和管理的方便，学习成本低，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用
Elastic-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用
对于并发场景不是特别高的系统来说，xxl-job配置部署简单易用，不需要引入多余的组件，同时提供了可视化的控制台，使用起来非常友好，是一个比较好的选择。
更倾向于选择XXL-JOB：
1.轻量级，支持通过Web页面对任务进行动态CRUD操作，操作简单
2.只依赖数据库作为集群注册中心，接入开发简单，不需要ZK
3.高可用、解耦、高性能、监控报警、分片、重试、故障转移
4.团队持续开发，社区活跃
5.支持后台直接查看每个任务执行实时日志，ELASTIC-JOB中应该是没有这个功能
五、参考资料
Quartz：
https://www.w3cschool.cn/quartz_doc/
ElasticJob官方：
https://shardingsphere.apache.org/elasticjob/current/cn/overview/
https://github.com/apache/shardingsphere-elasticjob
XXL-Job官方：
https://www.xuxueli.com/xxl-job/
https://github.com/xuxueli/xxl-job