我们先思考下面几个业务场景的解决方案：
支付系统每天凌晨1点跑批，进行一天清算，每月1号进行上个月清算
电商整点抢购，商品价格8点整开始优惠
12306购票系统，超过30分钟没有成功支付订单的，进行回收处理
商品成功发货后，需要向客户发送短信提醒
类似的业务场景非常多，我们怎么解决？
为什么我们需要定时任务
很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。一般来说，系统可以使用消息传递代替部分定时任务，两者有很多相似之处，可以相互替换场景。如，上面发货成功发短信通知客户的业务场景，我们可以在发货成功后发送MQ消息到队列，然后去消费mq消息，发送短信。
但在某些场景下不能互换：
a)时间驱动/事件驱动：内部系统一般可以通过时间来驱动，但涉及到外部系统，则只能使用时间驱动。如怕取外部网站价格，每小时爬一次b)批量处理/逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理。如移动每个月结算我们的话费c)实时性/非实时性：消息中间件能够做到实时处理数据，但是有些情况下并不需要实时，比如：vip升级d)系统内部/系统解耦：定时任务调度一般是在系统内部，而消息中间件可用于两个系统间
java有哪些定时任务的框架
单机
timer：是一个定时器类，通过该类可以为指定的定时任务进行配置。TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程
ScheduledExecutorService：相对延迟或者周期作为定时任务调度，缺点没有的日期或者时间
spring定时框架：配置简单功能较多，如果系统使用单机的话可以优先考虑spring定时器
分布
Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发
Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。
分布式任务调度系统对比
1. 什么是分布式定时任务
把分散的，可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。
2. 常见开源方案
elastic-job , xxl-job ，quartz , saturn, opencron , antares
elastic-job
elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 ， 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。
Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。
Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理、应用分发以及进程隔离等服务
亮点：
基于quartz 定时任务框架为基础的，因此具备quartz的大部分功能使用zookeeper做协调，调度中心，更加轻量级 持任务的分片支持弹性扩容 ， 可以水平扩展 ， 当任务再次运行时，会检查当前的服务器数量，重新分片，分片结束之后才会继续执行任务失效转移，容错处理，当一台调度服务器宕机或者跟zookeeper断开连接之后，会立即停止作业，然后再去寻找其他空闲的调度服务器，来运行剩余的任务提供运维界面，可以管理作业和注册中心。
elastic-job结合了quartz非常的时间调度功能，并且利用ZooKeeper实现了灵活的分片策略。除此之外，还加入了大量实用的监控和管理功能，
以及其开源社区活跃、文档齐全、代码优雅等优点，是分布式任务调度框架的推荐选择。
由于elastic-job-lite 不支持动态添加作业，此处仅贴上elastic-job-Cloud架构图
xxl-job
由个人开源的一个轻量级分布式任务调度框架 ，主要分为 调度中心和执行器两部分 ， 调度中心在启动初始化的时候，会默认生成执行器的RPC代理
对象（http协议调用）， 执行器项目启动之后， 调度中心在触发定时器之后通过jobHandle 来调用执行器项目里面的代码，核心功能和elastic-job差不多，同时技术文档比较完善
系统架构图：
quartz
quartz 的常见集群方案如下，通过在数据库中配置定时器信息， 以数据库悲观锁的方式达到同一个任务始终只有一个节点在运行，
优点：
保证节点高可用 （HA）， 如果某一个几点挂了， 其他节点可以顶上
缺点：
同一个任务只能有一个节点运行，其他节点将不执行任务，性能低，资源浪费
当碰到大量短任务时，各个节点频繁的竞争数据库锁，节点越多这种情况越严重。性能会很低下
quartz 的分布式仅解决了集群高可用的问题，并没有解决任务分片的问题，不能实现水平扩展
Saturn
Saturn是唯品会在github开源的一款分布式任务调度产品。它是基于当当elastic-job 1.0版本来开发的，其上完善了一些功能和添加了一些新的feature。
亮点：
支持多语言开发 python、Go、Shell、Java、Php。
管理控制台和数据统计分析更加完善
缺点：
技术文档较少 ， 该框架是2016年由唯品会的研发团队基于elastic-job开发而来
opencron
一个功能完善真正通用的linux定时任务调度定系统,满足多种场景下各种复杂的定时任务调度,同时集成了linux实时监控,webssh,提供一个方便管理定时任务的平台
缺点：仅支持 kill任务， 现场执行，查询任务运行状态 等， 主要功能是着重于任务的修改和查询上。不能动态的添加任务以及任务分片。
antares
优点：
一个任务仅会被服务器集群中的某个节点调度，调度机制基于成熟的 quartz
并行执行 ， 用户可通过对任务预分片，有效提升任务执行效率
失效转移
弹性扩容，在任务运行时，可以动态的加机器
友好的管理控制台
缺点：
不能动态的添加任务，仅能在控制台对任务进行触发，暂停，删除等操作
文档不多，开源社区不够活跃
系统架构图如下：
4. 比较
此处列出了几个代表性的开源产品
附 定时任务的其他方案
发货后超过10天未收货时系统自动确认收货的多种实现方式
每天定时半夜筛选第二天 可以自动确认收货的订单,然后第二天 每10分钟 执行一次确认收货 开销不会太大吧 时间也相对自动确认收货这个状态如果仅仅是让客户端看的话，等用户下一次上线的时间，做一次运算就可以了。延迟和定时消息投递ActiveMQ提供了一种broker端消息定时调度机制。适用于：1、不希望消息马上被broker投递出去，而是想要消息60秒以后发给消费者，2、想让消息没隔一定时间投递一次，一共投递指定的次数RabbitMQ可以针对Queue和Message设置 x-message-tt，来控制消息的生存时间，如果超时，则消息变为dead letter。利用DLX，当消息在一个队列中变成死信后，它能被重新publish到另一个Exchange。这时候消息就可以重新被消费。
