一、背景
本文档为解决分布式场景下定时任务重复执行的问题提供选型参考。其中大部分描述来自互联网资料整合，相关链接在文档底部。
主要需求如下：
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.主节点选举
动态分片
分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理。在进行大数量业务操作时可显著提升任务处理速度和能力
- 基于平均分配算法的分片策略
- 作业值的hash值奇偶数决定IP算法的分片策略
- 根据作业值的hash值对job实例列表进行轮转的分片策略
- 自定义分片策略
依赖
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