常见任务调度框架

quartz

支持集群和分布式，但是没有友好的管理界面，功能单一，对于管理调用的任务比较困难。

quartz使用数据库锁。在quartz的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放。

quartz的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性。同时多个节点的异步运行保证了服务的可靠。但这种策略有自己的局限性：集群特性对于高CPU使用率的任务效果很好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。

缺点：quartz的分布式只是解决了高可用的问题，并没有解决任务分片的问题，还是会有单机处理的极限。

xxl-job

轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。目前拥有大量的it企业使用该框架，文档齐全，教程很多，遇到问题也比较容易找到解决方案。

主要特性

简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；

调度中心HA(中心式)：调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群部署，可保证调度中心HA；

执行器HA(分布式)：任务分布式执行，任务"执行器"支持集群部署，可保证任务执行HA；

弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；

分片广播任务：执行器集群部署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；

动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。

动态：支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，即时生效；

注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；

一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；

其他特性

路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；

故障转移：任务路由策略选择"故障转移"情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。

阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行(默认)、丢弃后续调度、覆盖之前调度；

任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；

任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；

任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方面的扩展短信、钉钉等告警方式；

事件触发：除了"Cron方式"和"任务依赖方式"触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。

任务进度监控：支持实时监控任务进度；

脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本;

调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；

数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；

邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；

运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；

全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；

功能齐全，文档也很齐全，有使用教程，但是上手门槛稍微高了；

Elastic-Job

分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。

Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。选择该项目可以满足大多数it企业的需求。

Elastic-Job-Cloud使用Mesos + Docker的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。

轻量级无中心化：Elastic-Job-Lite并无作业调度中心节点，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。

灵活的增删改查作业，集中式管理调度作业

支持高可用：一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。

支持分片：作业分片一致性，保证同一分片在分布式环境中仅一个执行实例

任务监控：通过监听Elastic-Job-Lite的zookeeper注册中心的几个关键节点即可完成作业运行状态监控功能

一致性：使用zookeeper作为注册中心，为了保证作业的在分布式场景下的一致性，一旦作业与注册中心无法通信，运行中的作业会立刻停止执行，但作业的进程不会退出，这样做的目的是为了防止作业重分片时，将与注册中心失去联系的节点执行的分片分配给另外节点，导致同一分片在两个节点中同时执行。

同时支持动态扩容，将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片

Saturn

基于当当Elastic Job代码基础上自主研发的任务调度系统，是唯品会开源的分布式作业调度平台，取代传统的Linux Cron/Spring Batch Job的方式，做到统一配置，统一监控，任务高可用以及分片并发处理。主要是去中心化，高可用，可分片，动态扩容，有认证和授权功能。

主要特性

支持多种语言作业，语言无关(Java/Go/C++/PHP/Python/Ruby/shell)

支持秒级调度

支持作业分片并行执行

支持依赖作业串行执行

支持作业高可用和智能负载均衡

支持异常检测和自动失败转移

支持异地容灾

支持多个集群部署

支持跨机房区域部署

支持弹性动态扩容

支持优先级和权重设置

支持docker容器，容器化友好

支持cron时间表达式

支持多个时间段暂停执行控制

支持超时告警和超时强杀控制

支持灰度发布

支持异常、超时和无法高可用作业监控告警和简易的故障排除

支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计

优点：源码清晰，学习入手容易。应用部署简单，提供运维控制台，集中管理作业，运维控制台功能强大，提供作业统计报表 ，告警，增删改查作业，作业统一配置。

（一）Quartz

1，Java语言编写，可以集成到大部分Java程序中去，Spring集成性好，他集中解决任务的执行问题。基于数据库来实现分布式环境下的任务调度。

2，quartz开源早，博客使用示例多，出现问题易于解决

弊端：

1，缺乏数据统计，quartz架构中使用数据库锁保障多节点任务执行时的唯一性，解决了单点故障的问题。但数据库锁的集中性也产生了严重的性能问题，比如大批量任务场景下，数据库成为了业务整体调度的性能瓶颈，同时在应用侧还会造成部分资源的等待闲置，缺少分布式并行调度的功能

2，需要把任务信息持久化到业务数据库、和业务有耦合、并且表比较多。

3，调度逻辑和执行逻辑存在同一个项目中、在机器性能固定的情况下、业务和调度之间不可避免会相互影响。

4，不适合大量的短任务 & 不适合过多节点部署

评价：性能较低

（二）xxl-job

1，大众点评2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、上手简单、轻量级、易扩展

2，轻量级，支持通过Web页面对任务进行动态CRUD操作，操作简单 3，只依赖数据库作为集群注册中心，接入开发简单，不需要ZK 4，高可用、解耦、高性能、监控报警、分片、重试、故障转移 5，团队持续开发，社区活跃 6，支持后台直接查看每个任务执行实时日志，ELASTIC-JOB中没有这个功能

弊端：日志问题

（三）Elastic-job

1，是一个分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成；定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复，额外提供资源治理、应用分发以及进程隔离等功能

弊端：依赖Zookeeper；

（四）Saturn

1，是唯品会自主研发的分布式的定时任务的调度平台，基于当当网的elastic-job 版本1.0开发，并且可以很好的部署到docker容器上，管理控制台和数据统计分析也更加完善

2，一个任务仅会被服务器集群中的某个节点调度，调度机制基于成熟的 quartz

3，并行执行 ， 用户可通过对任务预分片，有效提升任务执行效率

4，失效转移

5，弹性扩容，在任务运行时，可以动态的加机器

6，友好的管理控制台

弊端：

1，不能动态的添加任务，仅能在控制台对任务进行触发，暂停，删除等操作

2，技术文档较少，没有更新

（五）TBSchedule

1，阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式

弊端：依赖Zookeeper，代码太久没更新

（六）Antares

1，是一款基于 Quartz 机制的分布式任务调度管理平台，内部重写执行逻辑，一个任务仅会被服务器集群中的某个节点调度。用户可通过对任务预分片，有效提升任务执行效率；也可通过控制台 antares-tower 对任务进行基本操作，如触发，暂停，监控等

弊端：Antares 是基于 Quartz 的分布式调度，支持分片，支持树形任务依赖，但是无法跨平台

（七）SIA-TASK

1，SIA-TASK借鉴微服务设计思想，获取分布在每个执行器节点上的任务（Task）元数据，进行汇报，上传注册中心。利用在线可编辑方式支持任务在线编排、动态修改任务时钟；使用 Http 协议作为交互传输协议。数据交互格式统一使用Json。用户通过编排器(下文会做介绍)进行操作，触发事件，调度器接收事件，由调度中心进行时钟解析，执行任务流程，进行任务通知

弊端：

（八）powerjob

1，支持基于MapReduce的分布式计算、动态热加载Spring容器等

2，调度中心，统一部署，负责任务调度和管理

3，执行器，提供单机执行、广播执行和分布式计算

4，可选组件，OpenAPI客户端

弊端：诞生于2020年4月，产品的性能、易用性和稳定性验证不足，出现问题解决方式不足