点击上面的码猴技术专栏简单关注，做成星星标志！
及时掌握有趣的技术
1
前言
首先，请考虑以下业务场景的解决方案：
支付系统每天凌晨1点进行批款，进行一天清算，每月1日进行上月清算
电子商务1点抢购，商品价格8点1点开始打折
12306购票系统在订单支付30分钟以上未成功时，进行回收处理
商品成功发货后，需要通过邮件提醒客户
类似的业务场景非常多，怎么解决？
在很多业务场景中，我们需要在某个特定的时间点进行任务。 定时任务要解决的就是这样的业务场景。 通常，系统可以使用消息收发来代替一些定时任务，两者有很多相似之处并且可以彼此替换场景。
例如，如果上述成功发货并通过邮件通知了客户的业务场景，我们可以在成功发货后，将MQ消息发送到队列中，然后消耗MQ消息发送邮件。
但是，有些场景无法更换。
时间驱动/事件驱动：内部系统通常可以按时间驱动，但如果涉及外部系统，则只能使用时间驱动。 害怕收取外部网站价格的情况下，每小时爬一次
批量处理/项目符号处理：批量处理堆积的数据更有效率，在不需要实时性的情况下比消息中间件更有优势。 而且，也有只能批量处理的商业逻辑。 例如，移动每月结算我们的电话费
实时/非实时：消息中间件可以实时处理数据，但可能不需要实时，如vip升级
系统内部/系统解耦：定时任务调度通常位于系统内部，消息中间件可在两个系统之间使用
2
时间任务框架
单机
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年推出的分布式任务调度平台，是轻量级分布式任务调度框架，其核心设计目标是开发快速、学习方便
3
分布式任务调度系统的比较
参与比较的可选系统方案： elastic——job (以下简称E-Job )和xxX-Job (以下简称x-job )
项目背景及社区力量
X-Job :大众点评公司员工tdhn，贡献者3人github有2470star，1015fork | QQ讨论组6个|在使用的40多家公司注册|文档齐全
E-Job：当当网开源，贡献者17人; github有2524star、1015fork | QQ讨论群１个、源码讨论群１个 | 有登记在使用的超过50家公司 | 文档齐全 ｜ 有明确的发展计划
支持集群部署
X-Job：集群部署唯一要求为：保证每个集群节点配置（db和登陆账号等）保持一致。调度中心通过db配置区分不同集群。
执行器支持集群部署，提升调度系统可用性，同时提升任务处理能力。集群部署唯一要求为：保证集群中每个执行器的配置项 xxl.job.admin.addresses/调度中心地址”保持一致，执行器根据该配置进行执行器自动注册等操作。另外关注公号码猿技术专栏，回复关键词“面试宝典”，送你一份阿里内部面试资料！
E-Job：重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心
作业注册中心：基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行。
多节点部署时任务不能重复执行
X-Job：使用Quartz基于数据库的分布式功能
E-Job：将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。
日志可追溯
X-Job：支持，有日志查询界面
E-Job：可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件。
监控告警
X-Job：调度失败时，将会触发失败报警，如发送报警邮件。
任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔
E-Job：通过事件订阅方式可自行实现
作业运行状态监控、监听作业服务器存活、监听近期数据处理成功、数据流类型作业（可通过监听近期数据处理成功数判断作业流量是否正常,如果小于作业正常处理的阀值，可选择报警。）、监听近期数据处理失败（可通过监听近期数据处理失败数判断作业处理结果，如果大于0，可选择报警。）
弹性扩容缩容
X-Job：使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力
E-Job：通过zk实现各服务的注册、控制及协调
支持并行调度
X-Job：调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞。
E-Job：采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。
高可用策略
X-Job：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；
E-Job：调度器的高可用是通过运行几个指向同一个ZooKeeper集群的Elastic-Job-Cloud-Scheduler实例来实现的。ZooKeeper用于在当前主Elastic-Job-Cloud-Scheduler实例失败的情况下执行领导者选举。通过至少两个调度器实例来构成集群，集群中只有一个调度器实例提供服务，其他实例处于”待命”状态。当该实例失败时，集群会选举剩余实例中的一个来继续提供服务。另外关注公号码猿技术专栏，回复关键词“面试宝典”，送你一份阿里内部面试资料！
失败处理策略
X-Job：调度失败时的处理策略，策略包括：失败告警（默认）、失败重试；
E-Job：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。
动态分片策略
X-Job：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务；
E-Job：支持多种分片策略，可自定义分片策略
默认包含三种分片策略：基于平均分配算法的分片策略、 作业名的哈希值奇偶数决定IP升降序算法的分片策略、根据作业名的哈希值对Job实例列表进行轮转的分片策略，支持自定义分片策略
elastic-job的分片是通过zookeeper来实现的。分片的分片由主节点分配，如下三种情况都会触发主节点上的分片算法执行：a、新的Job实例加入集群 b、现有的Job实例下线（如果下线的是leader节点，那么先选举然后触发分片算法的执行） c、主节点选举”
4
和quartz框架对比
调用API的的方式操作任务，不人性化；
需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。
调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务；
Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能。
5
综合对比
6
总结和结论
共同点：
E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。
不同点：
X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用。
E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用。另外关注公号码猿技术专栏，回复关键词“面试宝典”，送你一份阿里内部面试资料！
7
附定时任务的其他方案
发货后超过10天未收货时系统自动确认收货的多种实现方式：
每天定时半夜筛选第二天 可以自动确认收货的订单,然后第二天 每10分钟 执行一次确认收货 开销不会太大吧 时间也相对精确
自动确认收货这个状态如果仅仅是让客户端看的话，等用户下一次上线的时间，做一次运算就可以了。
延迟和定时消息投递
ActiveMQ提供了一种broker端消息定时调度机制。适用于：1、不希望消息马上被broker投递出去，而是想要消息60秒以后发给消费者，2、想让消息没隔一定时间投递一次，一共投递指定的次数
RabbitMQ可以针对Queue和Message设置 x-message-tt，来控制消息的生存时间，如果超时，则消息变为dead letter。利用DLX，当消息在一个队列中变成死信后，它能被重新publish到另一个Exchange。这时候消息就可以重新被消费。
好了，今天就分享到这里。
往期推荐
SpringBoot面试杀手锏——自动配置原理
阿里巴巴为什么不建议直接使用 @Async 注解？
一口气说出 Redis 16 个常见使用场景
IDEA那些既好用又好玩的30多款宝贝插件，你知道多少？