很多业务场景须要我们某一特定的时候去做某件任务，定时任务办理的便是这种业务场景。一样平常来说，系统可以利用通报代替部分定时任务，两者有很多相似之处，可以相互更换场景。如，上面发货成功发短信关照客户的业务场景，我们可以在发货成功后发送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。这时候就可以重新被消费。
