Java定时任务框架对比

汇总情况

Quzrzt
LTS
Elastic-Job
xxl-Job
saturn
opencorn
antares

1. 什么是集群，分布式定时任务

把分散的，可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。

2. 常见开源方案

elastic-job , xxl-job ，quartz , saturn, opencron , antares, lts

2.1 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断开连接之后，会立即停止作业，然后再去寻找其他空闲的调度服务器，来运行剩余的任务
• 提供运维界面，可以管理作业和注册中心。

官方亮点说明：

• 分布式
  重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心。
• 并行调度
  采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。
• 弹性扩容缩容
  将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任 务重分片。
• 集中管理
  采用基于Zookeeper的注册中心，集中管理和协调分布式作业的状态，分配和监听。外部系统可直接根据Zookeeper的数据管理和- 监控elastic-job。
• 定制化流程型任务
  作业可分为简单和数据流处理两种模式，数据流又分为高吞吐处理模式和顺序性处理模式，其中高吞吐处理模式可以开启足够多的线程快速的处理数据，而顺序性处理模式将每个分片项分配到一个 独立线程，用于保证同一分片的顺序性。
• 失效转移
  弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样 失效转移功能也会牺牲部分性能。
• 运行时状态收集
  监控作业运行时状态，统计最近一段时间处理的数据成功和失败数量，记录作业上次运行开始时间，结束时间和下次运行时间。
• 作业停止，恢复和禁用
  用于操作作业启停，并可以禁止某作业运行（上线时常用）。
• Spring命名空间支持
  elastic-job可以不依赖于spring直接运行，但是也提供了自定义的命名空间方便与spring集成。
• 运维平台
  提供web控制台用于管理作业和注册中心。
• 稳定性
  在服务器无波动的情况下，并不会重新分片；即使服务器有波动，下次分片的结果也会根据服务器IP和作业名称哈希值算出稳定的分片顺序，尽量不做大的变动。
• 高性能
  同一服务器的批量数据处理采用自动切割并多线程并行处理。
• 灵活性
  所有在功能和性能之间的权衡，都可通过配置开启/关闭。如：elastic-job会将作业运行状态的必要信息更新到注册中心。如果作业执行频度很高，会造成大量Zookeeper写操作，而分布式 Zookeeper同步数据可能引起网络风暴。因此为了考虑性能问题，可以牺牲一些功能，而换取性能的提升。
• 幂等性
  elastic-job可牺牲部分性能用以保证同一分片项不会同时在两个服务器上运行。
• 容错性
  作业服务器与Zookeeper服务器通信失败则立即停止作业运行，防止作业注册中心将失效的分片分项配给其他作业服务器，而当前作业服务器仍在执行任务，导致重复执行。

不足：

• 异构语言不支持
• 目前采用的无中心设计，难于支持多语言，后面需要考虑调度中心的可行性。
• 监控体系有待提高，目前只能通过注册中心做简单的存活和数据积压监控，未来需要做的监控部分有：
  增加可监控维度，如作业运行时间等。
  基于JMX的内部状态监控。
  基于历史的全量数据监控，将所有监控数据通过flume等形式发到外部监控中心，提供实时分析功能。
• 不能支持多种注册中心。
• 需要增加任务工作流，如任务依赖，初始化任务，清理任务等。
• 失效转移功能的实时性有待提升。
• 缺少更多作业类型支持，如文件，MQ等类型作业的支持。
• 缺少更多分片策略支持。

elastic-job结合了quartz非常优秀的时间调度功能，并且利用ZooKeeper实现了灵活的分片策略。除此之外，还加入了大量实用的监控和管理功能，以及其开源社区活跃、文档齐全、代码优雅等优 点，是分布式任务调度框架的推荐选择。
elastic-job学习（网易乐得技术团队，具体说明）

系统架构

控制台界面

2.2 xxl-job :

这个框架的搭建确实非常简单，只需要修改配置基本就可以运行了
由个人开源的一个轻量级分布式任务调度框架 ，主要分为 调度中心和执行器两部分 ， 调度中心在启动初始化的时候，会默认生成执行器的RPC代理
对象（http协议调用）， 执行器项目启动之后， 调度中心在触发定时器之后通过jobHandle 来调用执行器项目里面的代码，核心功能和elastic-job差不多，同时技术文档比较完善。

优点：

• 1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；
• 2、动态：支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，即时生效；
• 3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群部署，可保证调度中心HA；
• 4、执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；
• 5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
• 6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
• 7、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；
• 8、故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
• 9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；
• 10、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；
• 11、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；
• 12、失败处理策略；调度失败时的处理策略，默认提供失败告警、失败重试等策略；
• 13、分片广播任务：执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；
• 14、动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
• 15、事件触发：除了”Cron方式”和”任务依赖方式”触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。
• 16、任务进度监控：支持实时监控任务进度；
• 17、Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志；
• 18、GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。
• 19、脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS等类型脚本;
• 20、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；
• 21、一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；
• 22、自定义任务参数：支持在线配置调度任务入参，即时生效；
• 23、调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；
• 24、数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；
• 25、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
• 26、推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用;
• 27、运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；
• 28、全异步：系统底层实现全部异步化，针对密集调度进行流量削峰，理论上支持任意时长任务的运行；
• 29、国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文；

其他粗略认为：

• 1. 可以手动在线通过GLUE编写Java代码，然后添加定时任务。
• 1. 可以自定义控制corn表达式。
• 1. 通过控制台可以直接执行，暂停，编辑定时任务，查看任务日志等等。

系统控制界面
系统架构图：

2.3 LTS
LTS，light-task-scheduler，是一款分布式任务调度框架, 支持实时任务、定时任务和 Cron 任务。有较好的伸缩性和扩展性，提供对 Spring 的支持（包括 Xml 和注解），提供业务日志记录器。支持节点监控、任务执行监、JVM 监控，支持动态提交、更改、停止任务。

依赖环境：

jdk 1.6 +
maven 3.0.5 +
zookeeper/redis
MySQL 5.6 + / mongoDB

管理界面
架构图
流程图

2.4 quartz

quartz 的常见集群方案如下，通过在数据库中配置定时器信息， 以数据库悲观锁的方式达到同一个任务始终只有一个节点在运行，

优点：

• 保证节点高可用 （HA）， 如果某一个几点挂了， 其他节e 点可以顶上

缺点：

• 同一个任务只能有一个节点运行，其他节点将不执行任务，性能低，资源浪费
• 当碰到大量短任务时，各个节点频繁的竞争数据库锁，节点越多这种情况越严重。性能会很低下
• quartz 的分布式仅解决了集群高可用的问题，并没有解决任务分片的问题，不能实现水平扩展

Quartz作为开源作业调度中的佼佼者，是作业调度的首选。但是集群环境中Quartz采用API的方式对任务进行管理，从而可以避免上述问题，但是同样存在以下问题：

• 问题一：调用API的的方式操作任务，不人性化；
• 问题二：需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。
• 问题三：调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务；
• 问题四：quartz底层以“抢占式”获取DB锁并由抢占成功节点负责运行任务，会导致节点负载悬殊非常大；而XXL-JOB通过执行器实现“协同分配式”运行任务，充分发挥集群优势，负载各节点均衡。

服务架构

2.5 Saturn :

Saturn是唯品会在github开源的一款分布式任务调度产品。它是基于当当elastic-job 1.0版本来开发的，其上完善了一些功能和添加了一些新的feature。

运行环境： Linux(shell作业仅支持linux，java/msg作业支持linux和windows)

Java 1.7 +

Maven 3.0.4 +

特性：

• 支持基于事件和时间触发
• 人工指定资源分配策略+自动平均策略结合
• 任务开发语言不受限制。支持Shell(PHP, Bash, python…)作业以及Java作业
• 支持1机1分片的本地化模式任务调度
• 任务按分片并行执行
• 框架和业务代码隔离，零依赖
• 分片的调度按负荷均衡分布
• 可视化管理
• 支持秒级任务触发
• 可视化监控和报警
• 支持容器化(Docker)部署

亮点：

• 支持多语言开发 python、Go、Shell、Java、Php。
• 管理控制台和数据统计分析更加完善

缺点：

• 文档较少，使用的公司比较少

2.6 opencron

一个功能完善真正通用的linux定时任务调度定系统,满足多种场景下各种复杂的定时任务调度,同时集成了linux实时监控,webssh,提供一个方便管理定时任务的平台

缺点：

• 仅支持 kill任务， 现场执行，查询任务运行状态 等， 主要功能是着重于任务的修改和查询上。
• 不能动态的添加任务以及任务分片。

2.7 antares

优点：

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

缺点：

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

系统架构图如下

4. 比较

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

• Previous
  MySQL学习笔记-优化
• Next
  Elastic Job学习笔记-搭建分布式定时任务