1. 概要:
单机
- timer： 是一个定时器类，通过该类可以为指定的定时任务进行配置。TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程
- ScheduledExecutorService：相对延迟或者周期作为定时任务调度，缺点没有绝对的日期或者时间
- spring定时框架： 配置简单功能较多，如果系统使用单机的话可以优先考虑spring定时器
分布式
- Quartz： Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
- TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
- elastic-job： 当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发，这个我写了系列教程了，在Java技术栈公从号可以搜索阅读。
- Saturn： 是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
- xxl-job： 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。
2. 分布式任务调度系统对比
elastic-job和xxl-job的区别与对比:
elastic-job设计的初衷就是面对高并发复杂业务的，其核心功能在于分片和弹性扩容。在服务器数量多，业务量大的时候也能非常好的调度，压榨服务器的性能，使用zookeeper使他具有高可用和一致性的同时有很好的可扩展性。
elastic-job本身没有中心的概念，通过zookeeper的选举机制选举出主服务器，任何一台服务器都可以作为主服务器，即使主服务器挂了也可以重新选举。因此elastic-job的优势在于它具有更好的可扩展性和可用性，但是这也使得他的使用和配置上比起xxl-job更复杂一些。
xxl-job通过一个中心式集群"调度中心”来调度多个执行器执行任务的，调度中心集群可以通过增加机器来实现高可用（HA）实际会造成一定程度上的资源浪费，调度中心通过DB锁保证集群分布式调度的一致性，这样扩展执行器会增大DB的压力，但是如果实际上这里数据库只是负责任务的调度执行。在没有那么多数量的执行器和任务的情况下是完全没问题的。执行器可以支持分布式部署，这实际上就足以满足大多数场景了。关键是原理简单实现也非常简洁，用起来也很轻便，与springboot也非常好集成。而且他的监控界面直接集成到调度中心里面，可以在监控界面直接新增任务。
Elastic-Job
这个框架大概在2年前很火，当时使用的公司很多，想必很多人也听过了，但是很可惜现在已经不在维护了，代码已经有2年没有更新了，这里违反了更新频率的原则，如果出现问题可能都没什么人帮助你，所以并不是很推荐使用。
更倾向于选择XXL-JOB：
- 轻量级，支持通过Web页面对任务进行动态CRUD操作，操作简单
- 只依赖数据库作为集群注册中心，接入开发简单，不需要ZK
- 高可用、解耦、高性能、监控报警、分片、重试、故障转移
- 团队持续开发，社区活跃
- 支持后台直接查看每个任务执行实时日志，ELASTIC-JOB中应该是没有这个功能
总结
共同点
E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。
不同点
X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用。
E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用。
对于并发场景不是特别高的系统来说，xxl-job配置部署简单易用，不需要引入多余的组件，同时提供了可视化的控制台，使用起来非常友好，是一个比较好的选择。
在业务量没那么大的时候, xxl-job是一个更好的选择。
即: 非必须，则优先选择 xxl-job.
备注： 本篇文章，旨在进行技术框架选型，与技术框架实现优缺点对比，具体的框架实现，请参考其他文章。