分布式任务调度框架⼏乎是每个⼤型应⽤必备的⼯具，本⽂介绍了任务调度框架使⽤的需求背景和痛点，对业界普遍使⽤的开源分布式任务调度框架的使⽤进⾏了探究实践，并分析了这⼏种框架的优劣势和对⾃⾝业务的思考。 ⼀、业务背景
1.1 为什么需要使⽤定时任务调度
（1）时间驱动处理场景：整点发送优惠券，每天更新收益，每天刷新标签数据和⼈数据。 （2）批量处理数据：按⽉批量统计报表数据，批量更新短信状态，实时性要求不⾼。
（3）异步执⾏解耦：活动状态刷新，异步执⾏离线查询，与内部逻辑解耦。
1.2 使⽤需求和痛点
（1）任务执⾏监控告警能⼒。
（3）业务透明，低耦合，配置精简，开发⽅便。
（4）易测试。
（5）⾼可⽤，⽆单点故障。
（6）任务不可重复执⾏，防⽌逻辑异常。
（7）⼤任务的分发并⾏处理能⼒。
⼆、开源框架实践与探索
2.1 Java 原⽣ Timer 和
ScheduledExecutorService
2.1.1 Timer使⽤
Timer缺陷：
1. Timer底层是使⽤单线程来处理多个Timer任务，这意味着所有任务实际上都是串⾏执⾏，前⼀个任务的延迟会影响到之后的任务的执
⾏。
法制与经济2. 由于单线程的缘故，⼀旦某个定时任务在运⾏时，产⽣未处理的异常，那么不仅当前这个线程会停⽌，所有的定时任务都会停⽌。
3. Timer任务执⾏是依赖于系统绝对时间，系统时间变化会导致执⾏计划的变更。
由于上述缺陷，尽量不要使⽤Timer， idea中也会明确提⽰，使⽤ScheduledThreadPoolExecutor替代Timer 。
2.1.2 ScheduledExecutorService使⽤
ScheduledExecutorService对于Timer的缺陷进⾏了修补，⾸先ScheduledExecutorService内部实现是ScheduledThreadPool线程池，可以⽀持多个任务并发执⾏。
对于某⼀个线程执⾏的任务出现异常，也会处理，不会影响其他线程任务的执⾏，另外ScheduledExecutorService是基于时间间隔的延迟，执⾏不会由于系统时间的改变发⽣变化。
当然，ScheduledExecutorService也有⾃⼰的局限性：只能根据任务的延迟来进⾏调度，⽆法满⾜基于绝对时间和⽇历调度的需求。
2.2 Spring Task
2.2.1 Spring Task 使⽤
spring task 是spring⾃主开发的轻量级定时任务框架，不需要依赖其他额外的包，配置较为简单。
此处使⽤注解配置
2.2.2 Spring Task缺陷
Spring Task 本⾝不⽀持持久化，也没有推出官⽅的分布式集模式，只能靠开发者在业务应⽤中⾃⼰⼿动扩展实现，⽆法满⾜可视化，易配置的需求。
2.3 永远经典的 Quartz
2.3.1 基本介绍
Quartz框架是Java领域最著名的开源任务调度⼯具，也是⽬前事实上的定时任务标准，⼏乎全部的开源定时任务框架都是基于Quartz核⼼调度构建⽽成。
2.3.2 原理解析
核⼼组件和架构
关键概念
（1）Scheduler：任务调度器，是执⾏任务调度的控制器。本质上是⼀个计划调度容器，注册了全部Trigger和对应的JobDetail， 使⽤线程池作为任务运⾏的基础组件，提⾼任务执⾏效率。
（2）Trigger：触发器，⽤于定义任务调度的时间规则，告诉任务调度器什么时候触发任务，其中CronTrigger是基于cron表达式构建的功能强⼤的触发器。
（3）Calendar：⽇历特定时间点的集合。⼀个trigger可以包含多个Calendar，可⽤于排除或包含某些时间点。
（4）JobDetail：是⼀个可执⾏的⼯作，⽤来描述Job实现类及其它相关的静态信息，如Job的名称、等相关信息。
（5）Job：任务执⾏接⼝，只有⼀个execute⽅法，⽤于执⾏真正的业务逻辑。
（6）JobStore：任务存储⽅式，主要有RAMJobStore和JDBCJobStore，RAMJobStore是存储在JVM的内存中，有丢失和数量受限的风险，JDBCJobStore是将任务信息持久化到数据库中，⽀持集。
2.3.3 实践说明
芮成钢专访领导者（1）关于Quartz的基本使⽤
可参考Quartz官⽅⽂档和⽹上博客实践教程。
（2）业务使⽤要满⾜动态修改和重启不丢失， ⼀般需要使⽤数据库进⾏保存。
Quartz本⾝⽀持JDBCJobStore，但是其配置的数据表⽐较多，官⽅推荐配置可参照官⽅⽂档，超过10张表，业务使⽤⽐较重。
在使⽤的时候只需要存在基本trigger配置和对应任务以及相关执⾏⽇志的表即可满⾜绝⼤部分需求。
（3）组件化
将quartz动态任务配置信息持久化到数据库，将数据操作包装成基本jar包，供项⽬之间使⽤，引⽤项⽬只需要引⼊jar包依赖和配置对应的数据表，使⽤时就可以对Quartz配置透明。
（4）扩展
集模式
通过故障转移和负载均衡实现了任务的⾼可⽤性，通过数据库的锁机制来确保任务执⾏的唯⼀性，但
是集特性仅仅只是⽤来HA，节点数量的增加并不会提升单个任务的执⾏效率，不能实现⽔平扩展。
Quartz插件
可以对特定需要进⾏扩展，⽐如增加触发器和任务执⾏⽇志，任务依赖串⾏处理场景，可参考：quartz插件——实现任务之间的串⾏调度
2.3.4 缺陷和不⾜
（1）需要把任务信息持久化到业务数据表，和业务有耦合。
（2）调度逻辑和执⾏逻辑并存于同⼀个项⽬中，在机器性能固定的情况下，业务和调度之间不可避免地会相互影响。
（3）quartz集模式下，是通过数据库独占锁来唯⼀获取任务，任务执⾏并没有实现完善的负载均衡机制。
2.4 轻量级神器 XXL-JOB
2.4.1 基本介绍
XXL-JOB是⼀个轻量级分布式任务调度平台，主打特点是平台化，易部署，开发迅速、学习简单、轻量级、易扩展，代码仍在持续更新中。
“调度中⼼”是任务调度控制台，平台⾃⾝并不承担业务逻辑，只是负责任务的统⼀管理和调度执⾏，并且提供任务管理平台， “执⾏器” 负责接收“调度中⼼”的调度并执⾏，可直接部署执⾏器，也可以将执⾏器集成到现有业务项⽬中。 通过将任务的调度控制和任务的执⾏解耦，业务使⽤只需要关注业务逻辑的开发。
神经质症
主要提供了任务的动态配置管理、任务监控和统计报表以及调度⽇志⼏⼤功能模块，⽀持多种运⾏模式和路由策略，可基于对应执⾏器机器集数量进⾏简单分⽚数据处理。
2.4.2 原理解析
2.1.0版本前核⼼调度模块都是基于quartz框架，2.1.0版本开始⾃研调度组件，移除quartz依赖 ，使⽤时间轮调度。
2.4.3 实践说明
详细配置和介绍参考官⽅⽂档。
2.4.
3.1 demo使⽤：
⽰例1：实现简单任务配置，只需要继承IJobHandler 抽象类，并声明注解
@JobHandler(value="offlineTaskJobHandler") ，实现业务逻辑即可。（注：此次引⼊了dubbo，后⽂介绍）。
@JobHandler(value="offlineTaskJobHandler")
@Component
public class OfflineTaskJobHandler extends IJobHandler {
@Reference(check = false,version = "cms-dev",group="cms-service")
private OfflineTaskExecutorFacade offlineTaskExecutorFacade;
@Override
public ReturnT<String> execute(String param) throws Exception {
XxlJobLogger.log(" offlineTaskJobHandler start.");
try {
} catch (Exception e) {
XxlJobLogger.log("offlineTaskJobHandler-->exception." , e);
可燃气
return FAIL;
}
XxlJobLogger.log("XXL-JOB, offlineTaskJobHandler end.");
return SUCCESS;
花儿为什么这样香}
}
摩擦起电
⽰例2：分⽚⼴播任务。
@JobHandler(value="shardingJobHandler")
@Service
public class ShardingJobHandler extends IJobHandler {
@Override
public ReturnT<String> execute(String param) throws Exception {
// 分⽚参数
ShardingUtil.ShardingVO shardingVO = ShardingVo();
XxlJobLogger.log("分⽚参数：当前分⽚序号 = {}, 总分⽚数 = {}", Index(), Total());
// 业务逻辑
for (int i = 0; i < Total(); i++) {
if (i == Index()) {
XxlJobLogger.log("第 {} ⽚, 命中分⽚开始处理", i);
} else {
XxlJobLogger.log("第 {} ⽚, 忽略", i);
}
}
return SUCCESS;
}
}
2.4.
3.2 整合dubbo
（1）引⼊dubbo-spring-boot-starter和业务facade jar包依赖。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议