定时任务框架选型
1.quartz
quartz 的常见集群方案如下，通过在数据库中配置定时器信息， 以数据库悲观锁的方式达到同一个任务始终只有一个节点在运行
优点
· 保证节点高可用 （HA）， 如果某一个几点挂了， 其他节e 点可以顶上
缺点
- 同一个任务只能有一个节点运行，其他节点将不执行任务，性能低，资源浪费
- 当碰到大量短任务时，各个节点频繁的竞争数据库锁，节点越多这种情况越严重。性能会很低下
- quartz 的分布式仅解决了集群高可用的问题，并没有解决任务分片的问题，不能实现水平扩展
结论：quartz作为开源作业调度中的佼佼者，是作业调度的首选，但是因为存在一些问题，其他的定时任务框架有好多是基于quartz做的拓展式的开发，能够体现quartz作为作业调度的作用，同事也弥补了其缺陷，所以，暂时不考虑
2.light-task-scheduler
框架概况
LTS(light-task-scheduler)主要用于解决分布式任务调度问题，支持实时任务，定时任务和Cron任务。有较好的伸缩性，扩展性，健壮稳定性而被多家公司使用。
LTS 有主要有以下四种节点：
- JobClient：主要负责提交任务, 并接收任务执行反馈结果。
- JobTracker：负责接收并分配任务，任务调度。
- TaskTracker：负责执行任务，执行完反馈给JobTracker。
- LTS-Admin：（管理后台）主要负责节点管理，任务队列管理，监控管理等。
其中JobClient，JobTracker，TaskTracker节点都是无状态的。 可以部署多个并动态的进行删减，来实现负载均衡，实现更大的负载量, 并且框架采用FailStore策略使LTS具有很好的容错能力。
LTS注册中心提供多种实现（Zookeeper，redis等），注册中心进行节点信息暴露，master选举。(Mongo or Mysql)存储任务队列和任务执行日志, netty or mina做底层通信, 并提供多种序列化方式fastjson, hessian2, java等。
LTS支持任务类型：
- 实时任务：提交了之后立即就要执行的任务。
- 定时任务：在指定时间点执行的任务，譬如 今天3点执行（单次）。
- Cron任务：CronExpression，和quartz类似（但是不是使用quartz实现的）譬如 0 0/1 * * * ?
支持动态修改任务参数,任务执行时间等设置,支持后台动态添加任务,支持Cron任务暂停,支持手动停止正在执行的任务(有条件),支持任务的监控统计,支持各个节点的任务执行监控,JVM监控等等.
架构图
流程图
结论：集群部署，支持分片，git上有较完善的文档，有可视化界面，由阿里提供，具有比较完善的拓展方式，功能也较完善，但是已经三年没有维护，原则上要选择社区活跃的架构，所以不考虑
3.antares
Antares特性
基于Quartz的分布式调度
- 一个任务仅会被服务器集群中的某个节点调度，调度机制基于成熟的Quartz，antares内部会重写执行逻辑；
并行执行
- 用户可通过对任务预分片，有效提升任务执行效率；
失效转移
- 客户端实效转移：当某个客户端实例在执行任务中宕机时，其正在执行的分片将重新由其他客户端实例执行；
- 服务器失效转移：当服务器集群中某个节点宕机时，其正在调度的任务将转移到其他节点去调度；
弹性扩容
- 客户端扩容：客户端可通过增加应用实例，提升任务执行的效率；
- 服务器扩容：服务器集群可通过增加节点，提升集群任务调度的服务能力；
进程级的应用实例
- antares通过ip+进程号标识客户端应用实例，因此支持单机多应用实例部署；
任务依赖
- antares支持树形任务依赖，当某任务执行完成后，会通知其后置任务执行；
任务报警
- antares支持基本的任务超时报警，失败报警等；
管理控制台
- 用户可通过控制台antares-tower对任务进行基本操作，如触发，暂停，监控等。
Antares架构
结论：集群部署，以zk为注册中心，支持分片，git上有较完善的文档，有可视化见面，可弹性扩容，用redis来做持久化，基本功能也完备，但是已经三年没有维护，原则上要选择社区活跃的架构，所以不考虑
4.opencron
一个功能完善真正通用的linux定时任务调度定系统,满足多种场景下各种复杂的定时任务调度,同时集成了linux实时监控,webssh,提供一个方便管理定时任务的平台.
缺点
- 仅支持 kill任务， 现场执行，查询任务运行状态 等， 主要功能是着重于任务的修改和查询上。
- 不能动态的添加任务以及任务分片。
结论：功能较简单，集群部署，文档较少，已经三年没有更新，不做考虑
5.Saturn
Saturn (任务调度系统)是唯品会开源的一个分布式任务调度平台，取代传统的Linux Cron/Spring Batch Job的方式，做到全域统一配置，统一监控，任务高可用以及分片并发处理。
Saturn是在当当开源的Elastic Job基础上，结合各方需求和我们的实践见解改良而成。
重要特性
- 支持多种语言作业，语言无关(Java/Go/C++/PHP/Python/Ruby/shell)
- 支持秒级调度
- 支持作业分片并行执行
- 支持依赖作业串行执行
- 支持作业高可用和智能负载均衡
- 支持异常检测和自动失败转移
- 支持异地容灾
- 支持多个集群部署
- 支持跨机房区域部署
- 支持弹性动态扩容
- 支持优先级和权重设置
- 支持docker容器，容器化友好
- 支持cron时间表达式
- 支持多个时间段暂停执行控制
- 支持超时告警和超时强杀控制
- 支持灰度发布
- 支持异常、超时和无法高可用作业监控告警和简易的故障排除
- 支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计
- 经受住唯品会生产800多个节点，每日10亿级别的调度考验
结论：该框架具有非常完善的功能点，基于elastic-job进行开发，拥有quartz的强大功能，基本包含初版elastic-job的基本功能点，当前更新的活跃程度一般，有非常丰富的开发文档以及部署文档，可以作为参考框架之一。
6.xxl-job
XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。
特性
1.中心制
调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；
执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；
2.高可用
调度中心：支持多节点部署，基于数据库行锁，在触发器的名称和执行时间相同前提下，确保仅有一个调度中心节点会执行任务下发工作。
执行器：支持多节点部署，通过调度中心选择其中的执行器，下发任务来执行。
3.策略路由
忙碌转移、故障转移、最先节点、最后节点、节点轮询、节点随机、一致性HASH、最少使用节点、最久未用节点、分片广播。
4.阻塞处理
单机串行、丢弃后续调度、覆盖之前调度。
5.故障处理
故障转移、失败重试、任务超时中断。
以上是项目的一些主要特性，还包括告警、GLUE、各种语言支持、国际化、容器化等等的特性，内容丰富，功能强大
而且相对来说简单易用，部署简单，配置简单
缺点
中心化部署，数据库行锁，性能会存在一定的瓶颈，但是对于公司比较小的流量来说，足够使用
7.elastic-job
ElasticJob 是面向互联网生态和海量任务的分布式调度解决方案，由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。 它通过弹性调度、资源管控、以及作业治理的功能，打造一个适用于互联网场景的分布式调度解决方案，并通过开放的架构设计，提供多元化的作业生态。 它的各个产品使用统一的作业 API，开发者仅需一次开发，即可随意部署。
特性
1.分布式调度
无作业调度中心节点，基于部署作业节点到达设定时间点时各自触发调度；注册中心仅用于作业注册和监控信息存储，而主作业节点仅用于处理分片和清理等功能。
2.作业高可用
提供安全的方式执行作业。将分片总数设置为1，并使用多于1台的服务器执行作业，作业将会以1主n从的方式执行。
一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。
3.资源利用率
提供最灵活的方式，最大限度的提高执行作业的吞吐量。将分片项设置为大于服务器的数量，最好是大于服务器倍数的数量，作业将会合理的利用分布式资源，动态的分配分片项。
4.分片与业务解耦
不直接提供数据处理的功能，框架只会将分片项分配至各个运行中的作业服务器，开发者需要自行处理分片项与真实数据的对应关系。
同时可个性化参数（shardingItemParameter），分片项匹配对应关系，用于将分片项的数字转换为更加可读的业务代码。
5.丰富的策略与扩展
提供了很多默认的策略机制，并且提供了SPI的扩展点，便于高级用户进行扩展。
缺点
由于框架比较大，而且接入zookeeper，相对而言比较复杂，需要理解，而且提供的配置项比较多，需要合理使用，正确使用。
比较分析
通过以上几个框架的描述来看，首先从社区活跃度来说，前四个已经有多年未更新，不再考虑范围内，然后从高可用、一致性、故障转移、任务分片、日志追溯、异常告警等来说，后面三种框架基本支持，由于Saturn是基于elasticjob进行二次开发，而且最近的更新时间在三个月，不做考虑，只在elastic-job和xxl-job之间进行考虑。
elastic-job和xxl-job
两个从功能来说基于相同，不同的是中心化和分布式，xxl-job目前也在往分布式发展，从性能来说，达到一定的两级来说，分布式的优势会更大，但是目前公司的流量来说，两者都已经满足，此处没有进行性能分析，从github上作者的回复来看，xxl-job支持5000个并发，已经足够满足业务需求。
从社区来说，xxl-job是个人维护的项目，虽然大众点评已经对其二次开发Ferrari，但是xxl-job基本属于个人维护，而elastic-job属于apache shardingsphere子项目，属于apache旗下，未来肯定会有更多的人参与进开发，社区活跃度优于xxl-job
从框架技术来说，elastic-job引入了很多中间件和技术，相对于xxl-job来说，对于初级业务开发人员来说，理解上会相对难一点。
从文档丰富程度来说，elastic-job只提供了部分比较关键的技术点，对于很多细节需要从源码着手，xxl-job提供了完备的技术文档，而且架构相对简单，便于入手。
综上考虑，为了后续业务发展万一达到一定量级，xxl-job难以支持或者错误率过高的情况下，而且elasticjob足够活跃的社区，同时，对于初级业务开发而言，不需要完全理解，所以，目前选择elasticjob来作为未来java定时任务框架
