阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 rrd.me/e5k4Y 「null」欢迎转载，保留摘要，谢谢！

• 我们先思考下面几个业务场景的解决方案：
• 为什么我们需要定时任务
• java有哪些定时任务的框架
  • 单机
  • 分布
• 分布式任务调度系统对比
  • 1. 什么是分布式定时任务
  • 2. 常见开源方案
  • 4. 比较
• 附 定时任务的其他方案

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

我们先思考下面几个业务场景的解决方案：

• 支付系统每天凌晨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

优点：

1. 一个任务仅会被服务器集群中的某个节点调度，调度机制基于成熟的 quartz
2. 并行执行 ， 用户可通过对任务预分片，有效提升任务执行效率
3. 失效转移
4. 弹性扩容，在任务运行时，可以动态的加机器
5. 友好的管理控制台

缺点：

1. 不能动态的添加任务，仅能在控制台对任务进行触发，暂停，删除等操作
2. 文档不多，开源社区不够活跃

系统架构图如下：

4. 比较

此处列出了几个代表性的开源产品

附 定时任务的其他方案

发货后超过10天未收货时系统自动确认收货的多种实现方式

每天定时半夜筛选第二天 可以自动确认收货的订单,然后第二天 每10分钟 执行一次确认收货 开销不会太大吧 时间也相对精确

自动确认收货这个状态如果仅仅是让客户端看的话，等用户下一次上线的时间，做一次运算就可以了。

延迟和定时消息投递

• ActiveMQ提供了一种broker端消息定时调度机制。适用于：1、不希望消息马上被broker投递出去，而是想要消息60秒以后发给消费者，2、想让消息没隔一定时间投递一次，一共投递指定的次数
• RabbitMQ可以针对Queue和Message设置 x-message-tt，来控制消息的生存时间，如果超时，则消息变为dead letter。利用DLX，当消息在一个队列中变成死信后，它能被重新publish到另一个Exchange。这时候消息就可以重新被消费。