「分布式任务调度java」分布式任务调度的应用场景

本篇文章给大家谈谈分布式任务调度java，以及分布式任务调度的应用场景对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、分布式调度系统（3）——任务分配
• 2、点我达分布式任务调度系统-DaJob
• 3、分布式定时任务调度框架实践
• 4、开源分布式任务调度工具，和你一起记住生命中每一个重要的时刻
• 5、分布式任务调度框架选型，如何选择一个合适的框架？
• 6、XXL-JOB - 分布式任务调度平台 WAR/JAR 包 部署

分布式调度系统（3）——任务分配

将任务分配到具体执行节点。

以上配置信息保存在 /config/job/{jobName} 节点。

任务分配的目标是：让当前工作尽可能均衡地在各执行节点上执行。

触发任务分配的事件，可能是：

任务分配单元 ： 将任务拆分为最小可执行的粒度，如：一个父任务、一个shard子任务，一个子任务，作为一个分配单元。每个分配单元包括：（父任务名称，子任务shardItem序号/childIndex流水号，load）。

待分配任务列表 ：按任务分类，每个任务形成一个待分配列表，按load倒叙、sharingItem/childIndex正序 排序。

节点下线 ：在节点下线的场景，需要将故障节点下的任务摘下，按任务放入多个待分配任务列表。

任务启动 ：对于任务启动的场景，任务下所有的任务分配单元均需要重新分配，都放入到待分配任务列表中。

节点上线 ：在节点上线的场景中，需读取 /config/node/{nodeName} 数据， 确定受影响的任务。读取 /runtime/job/{jobName}/availableNodes/{nodeName} 确认受影响的节点。 计算新节点上线后平均每节点load，从负载最多的节点摘下。摘取时，每次摘取不同任务，直至节点node在平均值以下。

构建节点列表，构建 MapString /*node name*/ , Long /*node load*/ 。

逐个任务分配，优先分配总load高的任务。

每个任务按load倒叙，每次分配分配到不同节点，优先分配总load低的node。

如果节点load已经高出平均值，则退出待分配node列表。

集群启动过程中， 节点不断加进来， 不断触发任务重新分配， 这是没有必要的。

冷冻时间 ：集群初始启动过程中，第1个启动的节点确认没有其他节点后，会创建 /runtime/frozonTime 节点，节点数据为解冻的时间点（一般为5分钟后）。

在解冻时间到达之前，不触发任务分配。

创建冷冻节点的同时，清理availableNodes，和 /runtime/node/{nodeName}/job 。

集群收到 shutdown 调用后，开始关闭集群，关闭顺序：

点我达分布式任务调度系统-DaJob

背景

随着互联网的发展，应用服务中的定时任务数量日益增加，常规的垂直应用架构已无法应对，分布式服务架构势在必行。同时，也迫切需要一个分布式任务调度系统来管理分布式服务中的定时任务。

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，在该应用中的定时任务如果不多还好，但是一旦比较多，则意味着每次更改一个定时任务的执行时间，就需要重新部署一遍整个应用，导致整个应用停滞一段时间。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分为互不相干的几个应用来提升效率。此时，相应的任务也会被垂直拆分，每次更改任务带来的影响相应减少。

分布式服务架构

当垂直应用越来越多，应用之间可能会出现不可避免的交互，此时，将核心业务抽取出来，形成单独的服务，各式各样的服务逐渐形成稳定的服务中心，使得前端应用能更快地响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架是关键，同时，由于服务独立，则一般能做到定时任务独立的情况，因此，任务的更改对于整体系统的影响小之又小。

分布式任务调度

在分布式服务架构的基础上，由于独立业务的数量可能很多，此时如果定时任务单独在该服务中实现，很可能会出现难以管理的情况，且避免不了定时任务更改导致的业务重启，因此，一个独立的分布式任务调度系统是很必要的，可以用来全局统筹管理所有的定时任务，同时，将任务的配置单独抽离出来作为该分布式任务调度系统的功能，就能做到定时任务的更改不影响任何业务，也不影响整个系统。

架构设计

设计思想

以Dubbo核心，将调度单独抽象出来，成为一个调度中心，调度中心本身不承担实现任何业务逻辑，只是单纯依据调度配置来发起调度请求

将任务抽象成为ExecutorService，由任务执行者来实现具体的任务，并且负责接收调度请求并执行，这样设计可以将任务与调度中心完全解耦，提高整个系统的扩展性，方便接入

将调度中心对任务执行者的一些调用操作提取出来，形成一个单独的管理控制台，可以用来查看任务执行情况，同时该管理控制台通过H5实现，并提供对外Restful API，方便扩展与接入

通过各种中间件，实现一些必须的操作，例如告警，监控，日志收集统计等操作，完全对整个系统安全性，稳定性的保障

调度中心集群通过Zookeeper存储每个Schedular的一致性HashCode，以此来分配Job与Schedular之间的关系：新增的Job将会通过每个Schedular的一致性HashCode获取其对应的Job数，依据Job数的大小以及Schedular的相关属性来计算每个Schedular的权重，根据权重的大小来确定当前新增的Job应该被分配到哪个Schedular上。

当新增Schedular之后，该新增的Schedular的Job正常为0，因此，正常状态下，该新增的Schedular的权重会比较大。

同时，调度中心通过Zookeeper对Schedular实现主备切换，确保系统稳定性

系统组成

Schedular

基于Quartz实现调度，提供对执行者操作的接口，用于操作任务调度配置，调度触发等操作;自身不参与任务逻辑的实现，不会受限于任务

执行者

负责接收调度中心发起的调度请求，实现相应业务逻辑，完成任务执行，同时会对任务逻辑进行切面处理，记录相应日志并在任务结束后发送给调度中心

管理控制台

管理控制台负责展示任务状态，执行情况，任务执行日志等报表数据，同时可以通过管理控制台配置新增任务，操作任务的状态，暂停/恢复等;另外，提供对外Restful API与H5的接入

Dubbo Monitor

实时监控调度中心接口调用情况，统计调度频次，成功失败，QPS等，能通过这些报表数据来优化任务调度，优化系统

ELK

通过ELK（ElasticSearch+Logstash+Kibana）来收集调度中心以及各执行机的执行日志，并加以分析统计，形成报表，可以方便提供观察

Alarm

报警系统，通过Chronograf控制台配置告警规则，在出现问题时第一时间通过Kapacitor进行邮件与短信报警，可以有效提高错误提示的及时性并且降低错误发生到错误解决过程中消耗的时间，降低生产环境造成的损失，告警数据通过业务仪表盘获取。例如：可以配置线上机器的cpu当前使用率，设置阀值50%，策略为超过设置阀值时短信告警，此时当线上某台机器cpu超过50%时，即会发送短信告警

业务仪表盘

通过打点的方式，来实时收集接口监控数据，通过logstash传输到kafka，通过kafka再分发到jstorm进行处理，处理完之后再存储到influxdb，形成业务仪表盘，最后通过Grafana控制台产生监控报表

配置中心

整个系统各服务，通过配置中心统一管理相应配置，形成分布式配置管理机制，方便系统内各服务的配置一致性以及准确性

在配置完之后，就可以实现自己的任务逻辑了

接入之后，可以通过日志管理控制台线上实时查看任务执行状态

另外，由于有告警系统，在任务执行异常时，会产生告警邮件与短信，实时发送，告知任务接入者与相应研发人员

配置中心属性配置

特性

支持动态暂停/恢复任务

任务状态停止时，任务将不再被触发，若任务在执行过程中被暂停，则正在执行的任务不会被阻塞（由于任务执行结果状态中存在超时失败状态，因此如果点击暂停按钮时阻塞了当前正在执行的任务，会使当前任务的执行状态变为超时，不符合超时状态真正的意义），会延迟停止，即等到当前任务执行完再真正停止任务

调度中心基于Quartz实现，通过Zookeeper实现主备隔离，保证调度中心HA

当活跃节点宕机，冷备节点就会载入所有活跃节点中正在调度状态的任务，成为新的活跃节点，保证任务调度的准确执行

执行机支持集群部署，任务分布式执行，通过调度中心统一调度

执行机负载均衡，默认根据任务在某个执行机上的执行次数计算执行机调度权重，按照权重来选择本次任务调度分发给哪台执行机，实现负载均衡，可手动更改执行机选择策略

执行机集群方式,

failover,failfast,failsafe,failback,forking，默认为failover(故障切换)，调用失败时，重试其他服务器;failfast(快速失败)，只会发起一次调用，不会重试，失败立即报错;failsafe(失败安全)，出现异常时，直接忽略;failback(失败恢复)，调用失败时，定时重发，直到成功，重启会丢失; forking，并行调用多个执行机，只要一个成功即返回

分片任务，支持任务分片，通过参数发送给任务执行机，执行机可以通过判断参数来进行分片作业的开发，同时支持动态分片，以分片参数和执行机为纬度进行分片，支持动态扩容执行机以及分片参数

例如，某张订单表按照订单ID来进行简单纬度分片，且以取模3来进行分片，则可以设置三个分片参数，(0，1，2)，执行机在通过context拿到其中的一个分片参数之后可以对该分片参数做判断，来做具体的数据操作，例如当拿到的分片参数为0时，则对于0相应的分片做数据查询操作，依次类推

再例如，某张订单表按照订单ID和Status来进行二维分片，ID取模以3来进行分片，状态以成功，失败两种状态来进行分片，此时就可以设置6个分片参数，({‘id’:0,’status’:0},{‘id’:1,’status’:0},{‘id’:2,’status’:0},{‘id’:0,’status’:1},{‘id’:1,’status’:1},{‘id’:2,’status’:1}),执行机在通过context拿到其中的一个分片参数之后，就可以对其json参数进行判断，来实现分片操作

任务执行一致性，每次任务只会被一个执行机所执行;对于分片任务，在执行机集群部署时，一次任务调度将会广播触发对应集群中相应数量的执行器执行一次任务，同时传递分片参数，可根据分片参数开发分片任务。

当分片参数大于执行器数量时，将会按照执行器路由策略，使得当前分片任务的某个或者某几个执行机执行多个分片的任务

例如：当前分片任务分片参数为(a,b,c),当前任务执行机有3台(A,B,C)时，则会均匀随机得将分片参数发送给某一台执行机，且三台执行机一次只接收一个分片参数，做一次任务处理，即(a-A,b-B,c-C)|(a-A,b-C,c-B)|(a-B,b-A,c-C)|(a-B,b-C,c-A)|(a-C,b-A,c-B) |(a-C,b-B,c-A)；

当任务执行机只有2台(A,B)时，每次任务调度时，某台执行机会收到两个分片参数，并分别处理这两个分片参数,即(a-A,b-B,c-A)|(a-A,b-B,c-B)|(a-B,b-A,c-A)|(a-B,b-A,c-B)；

而当任务执行机大于分片参数个数，为4台(A,B,C,D)时，(a-A,b-B,c-C)|(a-A,b-C,c-D)|(a-A,b-D,c-B)| (a-B,b-C,c-D)|(a-B,b-D,c-A)|(a-B,b-A,c-C)|(a-C,b-A,c-B)|(a-C,b-B,c-D)| (a-C,b-D,c-A)|(a-D,b-A,c-B)|(a-D,b-B,c-C)|(a-D,b-C,c-A)，而统计下来，不管是执行机数目大于或者等于或者小于分片参数数目，被分发给执行机的分片参数始终是保持一致的（每台执行机接收到的总的分片参数是均匀的）

告警系统，系统接入内部告警系统，任务失败时支持邮件，短信，钉钉，电话等告警

弹性扩容缩容，调度中心将会实时探测任务执行机，因此一旦有执行机上线或者下线，都将会被探测到，而如果未被调度中心探测到，则可以进行手动探测执行机，而在探测到执行机之后，下次调度将会重新分配任务

任务依赖，支持配置任务依赖关系，当父任务在执行完成之后会自动触发子任务的执行例如：有两个任务，分别为A和B，而B的执行条件为确认A任务执行完，B才能执行，否则，B任务不执行，此时的依赖关系就是B任务依赖A任务，此时在A任务配置完之后，设置B任务为依赖任务，而依赖关系则是A；又例如有6个任务，分别是A1,A2,A3,A4,A5,B，而B任务的执行需要确保A1-5这5个任务都执行完，B任务才执行，此时，B的依赖关系就是B任务依赖于A1-5，此时在配置完A1-5这5个任务之后再设置B为依赖任务，依赖关系则是A1-5

支持运行时查看任务执行情况，任务数量，调用次数，执行器数量等统计信息异常执行恢复机制，有时会遇到不可控情况，即执行机在执行后的执行结果因为网络断开等不可控因素导致不能发送给调度中心，此时能通过异常执行恢复机制临时记录，在下次执行机正常启动时重试发送给调度中心调度手动触发手动执行，特殊需求下，可能会要求调度可以手动执行，例如调度任务失败之后可能需要手动执行一次调度来补偿

并行/串行策略，当定时时间远大于任务执行时间时，可以使用并行策略，任务异步调用执行，提高任务调度精确度;当任务执行时间可能大于定时时间，却需要任务按照某个定时规则定时调度时，可以使用串行策略，调度中心调度的当前任务的上一次触发，如果没有执行完，则当前执行机的下一次定时时间点时不会被触发，当且仅当任务执行结束，以防止某些持续性定时任务的时间不确定性导致异步触发时的数据混乱的情况发生，例如：某一任务的定时时间为10秒钟，但是任务本身可能会出现执行超过10秒的情况，而超过时，如果出现两个时间点的任务并行执行时会出现数据混乱的情况，此时就可以使用串行策略，确保当前执行机上一个任务未执行完，不会触发新的执行

支持调度接口数据监控，产生监控报表，便于观测。

总结

对于互联网公司来说，时间就是金钱，效率决定一切。本系统在接入到8月初将近3个月的时间内，表现不凡，调度了约100万次，给公司内部各服务实现任务调度提供了便利。

原文

分布式定时任务调度框架实践

分布式任务调度框架几乎是每个大型应用必备的工具，本文介绍了任务调度框架使用的需求背景和痛点，对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践，并分析了这几种框架的优劣势和对自身业务的思考。

一、业务背景

1.1 为什么需要使用定时任务调度

（1）时间驱动处理场景： 整点发送优惠券，每天更新收益，每天刷新标签数据和人群数据。

（2）批量处理数据： 按月批量统计报表数据，批量更新短信状态，实时性要求不高。

（3）异步执行解耦： 活动状态刷新，异步执行离线查询，与内部逻辑解耦。

1.2 使用需求和痛点

（1）任务执行监控告警能力。

（2）任务可灵活动态配置，无需重启。

（3）业务透明，低耦合，配置精简，开发方便。

（4）易测试。

（5）高可用，无单点故障。

（6）任务不可重复执行，防止逻辑异常。

（7）大任务的分发并行处理能力。

二、开源框架实践与 探索

2.1 Java 原生 Timer 和

ScheduledExecutorService

2.1.1 Timer使用

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的基本使用

（2）业务使用要满足动态修改和重启不丢失， 一般需要使用数据库进行保存。

（3）组件化

（4）扩展

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使用：

@JobHandler(value="offlineTaskJobHandler") ，实现业务逻辑即可。（注：此次引入了dubbo，后文介绍）。

（滑动可查看）

示例2：分片广播任务。

（滑动可查看）

2.4.3.2 整合dubbo

（1）引入dubbo-spring-boot-starter和业务facade jar包依赖。

（滑动可查看）

（2）配置文件加入dubbo消费端配置（可根据环境定义多个配置文件，通过profile切换）。

（滑动可查看）

（3）代码中通过@Reference注入facade接口即可。

（滑动可查看）

（4）启动程序加入@EnableDubboConfiguration注解。

（滑动可查看）

2.4.4 任务可视化配置

内置了平台项目，方便了开发者对任务的管理和执行日志的监控，并提供了一些便于测试的功能。

2.4.5 扩展

（1）任务监控和报表的优化。

（2）任务报警方式的扩展，比如加入告警中心，提供内部消息，短信告警。

（3）对实际业务内部执行出现异常情况下的不同监控告警和重试策略。

2.5 高可用 Elastic-Job

2.5.1 基本介绍

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

Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。

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

可惜的是已经两年没有迭代更新记录。

2.5.2 原理解析

2.5.3 实践说明

2.5.3.1 demo使用

（1）安装zookeeper，配置注册中心config，配置文件加入注册中心zk的配置。

（滑动可查看）

（滑动可查看）

（2）配置数据源config，并配置文件中加入数据源配置。

（滑动可查看）

（滑动可查看）

（3）配置事件config。

（滑动可查看）

（4）为了便于灵活配置不同的任务触发事件，加入ElasticSimpleJob注解。

（滑动可查看）

（5）对配置进行初始化。

（滑动可查看）

（6）实现 SimpleJob接口，按上文中方法整合dubbo, 完成业务逻辑。

（滑动可查看）

2.6 其余开源框架

（1） Saturn ：Saturn是唯品会开源的一个分布式任务调度平台，在Elastic Job的基础上进行了改造。

（2） SIA-TASK ：是宜信开源的分布式任务调度平台。

三、优劣势对比和业务场景适配思考

业务思考：

四、结语

对于并发场景不是特别高的系统来说，xxl-job配置部署简单易用，不需要引入多余的组件，同时提供了可视化的控制台，使用起来非常友好，是一个比较好的选择。希望直接利用开源分布式框架能力的系统，建议根据自身的情况来进行合适的选型。

附：参考文献

高可用架构

改变互联网的构建方式

开源分布式任务调度工具，和你一起记住生命中每一个重要的时刻

⏳ SandGlass 是一款为 java 设计的分布式任务调度工具。

定时任务是业务需求中非常常见的

比如：

（1）每天给自己爱人发晚安

什么你还是单身？，那看完本篇文章就有了。

（2）每个月通知自己要还信用卡

可能还有其他的手机费、生活费之类的，反正又是一个没钱的一个月。

（3）每个月 14 日都是情人节

这个扯远了……

有了场景，那我们如何实现呢？

java 已有的实现任务调度的主流工具如下：

为什么需要重新实现一个任务调度框架呢？

老马的日常开发中，简单的调度任务会使用 jdk 中的 ScheduledExecutor 实现。

当涉及到 cron 表达式时，一般会使用 quartz，毕竟老牌调度框架，功能非常完善。

但是对比 spring schedule，quartz 的使用就显得有些麻烦，需要开发者指定较多的配置。

那直接使用 spring schedule 不就好了吗？

spring schedule 的缺点也很明显，不支持数据的持久化，不支持分布式调度。

那直接引入一个分布式任务调度系统呢？

有时候就显得杀鸡用牛刀，而且维护成本比较高。

读到这里，肯定会有聪明的小伙伴们发问了：“难道就不能写一个可以独立于 spring 使用，又可以整合 spring 使用，可以单机调度，又可以分布式调度的任务调度工具吗？”

是的， sandglass 就是一个渐进式，满足上面各种应用场景的任务调度工具 。

根据 cron 表达式，5s 执行一次任务。

通过 cron 表达式创建 trigger，可以通过方法：

通过指定时间间隔创建 trigger，使用方法：

SandGlass 也支持引导类自定义，默认配置等价于：

所有实现都是基于接口，用于可以根据实际业务进行调整。

可配置的属性列表如下：

类似于 spring 的任务调度，我们可以通过注解指定方法。

@PeriodSchedule 用于指定 period 执行的任务， @CronSchedule 用于指定 cron 表达式对应的任务。

用于指定基于 period 执行的任务方法。

可配置属性列表如下：

用于指定基于 cron 表达式 执行的任务方法。

可配置属性列表如下：

直接指定 @EnableSandGlass 注解即可，无需额外配置。

@EnableSandGlass 允许用户进行自定义。

可配置的属性列表如下：

默认的策略和 SandglassBs 引导类保持一致。

自定义方式：实现对应接口，在注解中对应对应的 bean 名称即可。

说明：下面 3 个属性和业务无关，只和执行的环境的配置有关，所以不支持注解指定。可以通过配置自定义。

其他什么都不需要，就可以类似 spring 整合一样使用定时任务了。

同 spring 整合

sandglass 共计 5 个子模块：

采用渐进式的 MVP 设计理念，基本可以满足日常开发中的常见场景。

当然，分布式的任务调度服务会复杂的多，将会以 sandglass 为基础进行拓展实现。

常言道，独木不成林。

sandglass 作为一个任务调度核心实现，只是分布式任务调度的基石。

若要实现一个完整的分布式调度系统，还需要如下的工具支撑。

目前经历几十个迭代和几十个不眠的夜晚，基本功能实现完成，后续考虑陆续开源。

为了便于大家共同学习，开源地址如下：

为了吃瓜通宵7天写了一个网站

开源分布式任务调度工具，和你一起记住生命中每一个重要的时刻

分布式任务调度框架选型，如何选择一个合适的框架？

首先，这种框架现在市面上是有的。强烈建议，不要重复造轮子。

先介绍几种比较主流的。

Elastic-Job,是当当网开源的分布式调度解决方案，支持任务分片功能，可以充分利用资源。Elastic-Job有两个独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。具体实现可以参考官方教程。其整体架构图如下。

Elastic-Job的特点：

1、分布式调度 2、作业高可用 3、任务分片执行。

另外，还有其他的一些框架，可以对比使用。比如TBSchedule是阿里巴巴开源的分布式调度框架，完全由java实现，目前被应用于淘宝，阿里巴巴，支付宝，京东， 汽车 之家等。大众点评开源的xxl-job，也是应用比较广泛的分布式调度任务。

目前我使用过的有 Elastic-Job和xxl-job。两者功能都很强大，后台管理也比较完善。很容易上手。都可以满足日常的工作需要。区别就是 Elastic-Job依赖zk，但是xxl-job不依赖zk，只依赖数据库。

目前市面上应该还有一些其他的框架，但是以上是比较主流的，可以根据自己的需要来选择。切记不要重复造轮子，造轮子需要大量的时间去验证。会让你在坑里爬不出来。

1.XXL-JOB

2.Elastic-Job

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

定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。

支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。

分布式调度解决方案，由两个相互独立的子项目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将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片

3.opencron

opencron是一个功能完善且通用的开源定时任务调度系统，拥有先进可靠的自动化任务管理调度功能，提供可操作的 web 图形化管理满足多种场景下各种复杂的定时任务调度，同时集成了 linux 实时监控、webssh 等功能特性

4.quartz

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

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

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

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

5.Saturn

Saturn

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

主要特性

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

支持秒级调度

支持作业分片并行执行

支持依赖作业串行执行

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

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

支持异地容灾

支持多个集群部署

支持跨机房区域部署

支持弹性动态扩容

支持优先级和权重设置

支持docker容器，容器化友好

支持cron时间表达式

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

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

支持灰度发布

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

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

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

最后一个是国内团队封装的

前端时间研究了两款分布式任务调度框架，一个是XXL-Job，现在非常主流，很多常见的一些公司都在使用，像滴滴美团这样的公司都在用，这也是一款开源产品，下载下来导入IDEA就可以使用，分调度器和执行器和管理UI，有很美观的UI界面，可以对任务做增删改查，以及支持自定义开发，有很详细的帮助文档，还提供有demo，傻瓜式的，很简单，亮点是提供了管理界面。

另一个是Quartz，这个组件单机和集群都支持，单机的话是RAMJobStore任务存储，而要支持集群的话，就要将配置改成数据库方式，Quartz提供的有十几张表，其分布式的原理是利用了数据库的行锁，Quartz很简单，也是一款轻量级的开源产品，我们公司一直用这款组件，很成熟无Bug，推荐使用！

springcloudtask，springclouddataflow，正在学习中

XXL-JOB - 分布式任务调度平台 WAR/JAR 包 部署

官方网址: 分布式任务调度平台

修改xxl-job-admin.application.properties

maven clean

maven install

启动成功之后：访问localhost:8080/xxl-job-admin

打包完成后

通过java -jar xxl-job-admin-2.3.1-SNAPSHOT 命令即可。

xxl-job-admin.pom.xml

xxl-job-admin.XxlJobAdminApplication

修改启动类

将war包放入Tomcat中，启动Tomcat

启动

关于分布式任务调度java和分布式任务调度的应用场景的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。