定时任务的框架为什么需要定时任务定时任务扫表的方案有什么缺点Quartzxxl-jobxxl-job详解

elastic-job

在定时任务中操作系统或应用程序会利用计时器或定时器来定期检查当前时间是否达到了预定的执行时间如果当前时间已经达到了预定的时间系统会自动执行相应的任务。

在操作系统中常见的定时任务管理工具有crontabLinux系统、Windows

Task

定时任务是计算机程序中常用的一种任务调度方式。

它允许程序在指定的时间间隔或特定时间点自动执行某些操作或任务。

定时任务广泛应用于各种领域如系统管理、数据处理、日志记录等。

定时任务的原理

定时触发器定时任务的实现依赖于定时触发器。

定时触发器可以根据设定的时间规则在特定的时间点或间隔触发执行任务。

常见的定时触发器有系统级定时器、Cron表达式等。

任务调度器任务调度器负责管理和调度定时任务。

它可以根据任务的触发规则决定任务的执行时间将任务安排到适当的时间点执行。

任务调度器通常会维护一个任务队列按照设定的优先级、时间规则等对任务进行排队和调度。

任务执行器任务执行器负责执行定时任务的具体操作。

根据任务类型的不同任务执行器可以是一个单线程或多线程的执行器。

它会从任务队列中取出待执行的任务并按照设定的规则执行相应的操作如发送邮件、生成报表等。

错误处理机制定时任务的错误处理机制可以保证任务的可靠性和容错性。

当任务执行器在执行任务过程中出现错误或异常时错误处理机制可以进行相应的处理如重新执行任务、记录日志、发送警报等。

定时任务的实现方式

JDK自带

Timerjava.util.Timer类允许你调度一个java.util.TimerTask任务。

但这种方式一般用的较少因为它不能让程序在指定时间运行。

ScheduledExecutorService基于线程池设计的定时任务类任务是并发执行互不影响。

Spring

TaskSpring3.0以后自带的task通过Scheduled注解可以实现定时任务控制。

第三方任务调度框架

Scheduler功能强大且灵活的任务调度库支持基于cron表达式的任务调度、集群支持、作业持久化等。

xxl-job分布式任务调度平台提供可视化的任务管理界面和多种任务调度方式。

Elastic

PowerJob由阿里巴巴集团开发并开源的分布式任务调度框架支持多种任务类型。

注意事项

合理设置任务调度器的优先级和调度规则以确保任务能够按照预期的顺序和时间执行。

对于重要的定时任务建议设置错误处理机制以便在任务执行过程中出现问题时能够及时处理。

定期检查和监控定时任务的执行情况以确保任务能够正常运行并达到预期的效果。

timer是一个定时器类通过该类可以为指定的定时任务进行配置。

这是java自带的java.util.Timer类这个类允许你调度一个

TimerTask类是一个定时任务类该类实现了Runnable接口缺点异常未检查会中止线程

java.util.TimerTask任务。

使用这种方式可以让你的程序按照某一个频度执行但不能在指定时间运行。

一般用的较少。

ScheduledExecutorService也jdk自带的一个类是基于线程池设计的定时任务类,每个调度任务都会分配到线程池中的一个线程去执行,也就是说,任务是并发执行,互不影响。

分布式

QuartzJava事实上的定时任务标准。

但Quartz关注点在于定时任务而非数据并无一套根据数据处理而定制化的流程。

虽然Quartz可以基于数据库实现作业的高可用但缺少分布式并行调度的功能

TBSchedule阿里早期开源的分布式任务调度系统。

代码略陈旧使用timer而非线程池执行任务调度。

众所周知timer在处理异常状况时是有缺陷的。

而且TBSchedule作业类型较为单一只能是获取/处理数据一种模式。

还有就是文档缺失比较严重

elastic-job当当开发的弹性分布式任务调度系统功能丰富强大采用zookeeper实现分布式协调实现任务高可用以及分片目前是版本2.15并且可以支持云开发

Saturn是唯品会自主研发的分布式的定时任务的调度平台基于当当的elastic-job

xxl-job:

是大众点评员工徐雪里于2015年发布的分布式任务调度平台是一个轻量级分布式任务调度框架其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

为什么需要定时任务

很多业务场景需要我们某一特定的时刻去做某件任务定时任务解决的就是这种业务场景。

一般来说系统可以使用消息传递代替部分定时任务两者有很多相似之处可以相互替换场景。

如上面发货成功发短信通知客户的业务场景我们可以在发货成功后发送MQ消息到队列然后去消费mq消息发送短信。

但在某些场景下不能互换

a)时间驱动/事件驱动内部系统一般可以通过时间来驱动但涉及到外部系统则只能使用时间驱动。

如怕取外部网站价格每小时爬一次

b)批量处理/逐条处理批量处理堆积的数据更加高效在不需要实时性的情况下比消息中间件更有优势。

而且有的业务逻辑只能批量处理。

如移动每个月结算我们的话费

c)实时性/非实时性消息中间件能够做到实时处理数据但是有些情况下并不需要实时比如vip升级

d)系统内部/系统解耦定时任务调度一般是在系统内部而消息中间件可用于两个系统间

定时任务扫表是一种常见的定时任务调度方案但它也存在一些缺点包括

实时性差定时任务扫表是基于轮询的方式需要定期轮询数据库或其他数据源来获取需要执行的任务。

这种方式无法做到实时性可能存在一定的延迟。

资源消耗较大如果任务的执行频率较高比如每秒钟都有大量任务需要执行那么频繁的数据库查询或轮询会消耗大量的系统资源包括CPU和内存等。

扩展性差当任务数量增多或者任务执行时间变长时定时任务扫表可能面临性能瓶颈。

随着任务的增加数据库查询或轮询的开销也会增加可能导致系统的响应时间变慢。

数据库依赖定时任务扫表通常需要依赖数据库或其他外部存储来存储任务信息这增加了系统的复杂性和对数据库的依赖性。

数据库故障或性能问题可能会影响到任务的执行。

时间同步问题定时任务的执行时间依赖于系统时间。

如果系统时间出现偏差或不同步可能导致任务执行的不准确或混乱。

分布式环境下的同步问题在分布式环境中多个节点同时进行任务扫表可能会导致重复执行或者执行冲突的问题。

需要额外的同步机制来保证任务的一致性。

任务冲突如果多个定时任务在处理相同的数据或资源时发生冲突可能会导致数据不一致或其他问题。

错误处理如果定时任务在执行过程中出现错误可能需要人工介入进行错误处理。

这可能增加管理员的工作负担。

难以调试和优化对于复杂的定时任务调试和优化可能比较困难。

综上所述定时任务扫表虽然简单易用但在实时性、资源消耗、扩展性和分布式环境下的同步等方面存在一些缺点。

在一些对实时性要求较高、任务量大或分布式环境下的场景中可能需要考虑其他更为高效和可靠的任务调度方案。

为了克服这些缺点可以考虑以下策略优化任务尽量减少任务的复杂性避免不必要的资源消耗。

精确时间控制使用精确的时间同步机制来确保任务按计划执行。

冲突管理设计机制来避免或处理任务冲突例如使用锁或队列来确保任务的顺序执行。

错误处理和日志记录为任务添加错误处理机制并记录详细的日志以便于问题追踪和解决。

使用专门的调度工具考虑使用专门的调度工具或框架来简化定时任务的管理和配置。

监控和警报建立监控机制来检测任务的性能和状态并在出现问题时及时发出警报。

会有时间差程序不严谨

10:39下单11:00检查不足1小时12:00检查超过1小时多余39分钟不支持集群

单机没毛病使用集群后就会有多个定时任务

解决方案只使用一台计算机节点单独用来运行所有的定时任务会对数据库全表搜索及其影响数据库性能select

from

10:12分下单的未付款10状态11:12分检查如果当前状态还是10则直接关闭订单即可

Quartz

Quartz是一个任务调度框架,在项目中主要是用来做为定时处理,如商品限时抢购等.

Quartz

支持job间通过listener实现依赖调度可以方便的进行调度组合

用Quartz做定时任务调度

需求是这样的以整点时间戳为文件名每隔一小时创建一个文件在这一小时内不断的写文件达到下一小时关闭当前文件句柄和流并以当前整点小时创建新文件!

写一个单例服务类服务类两个成员变量一个是文件句柄一个是流可get可set。

把它作为spring的一个bean在quartz和你的读写线程都注入这个bean。

quartz里面用set来改句柄(百度上有很好的解释)和流读写线程用get来读

目前我能想到的解决办法是通过往表新建一个操作日志表里插入日志的形式

暂停中调用scheduler.pauseTrigger()方法时更改表中job信息

等待中新添加的job默认给其等待中的状态也是更改表中的job信息

xxl-job

官方文档https://www.xuxueli.com/xxl-job/

XXL-JOB

是一个功能强大且易于使用的分布式任务调度平台通过其高可用性设计、灵活的调度策略和丰富的功能特性可以满足各种复杂任务调度需求。

在实际使用中通过合理配置和使用其提供的API可以实现高效稳定的任务调度和管理。

XXL-JOB是一个轻量级分布式任务调度框架其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

现已开放源代码并接入多家公司线上产品线开箱即用。

时间驱动的场景某个时间点发送优惠券发送短信等等。

批量处理数据批量统计上个月的账单统计上个月销售数据等等。

固定频率的场景每隔5分钟需要执行一次。

所以定时任务在平时开发中并不少见而且对于现在快速消费的时代每天都需要发送各种推送消息都需要依赖定时任务去完成应用非常广泛。

XXL-JOB

是一个开源的分布式任务调度平台广泛应用于各种定时任务的调度和管理。

它提供了一套完整的分布式任务调度解决方案适用于Java生态系统。

以下是

XXL-JOB

可以部署为集群模式通过分布式锁或Leader选举机制保证高可用性。

执行器Executor

提供灵活的任务执行策略如单次执行、周期执行、CRON表达式等。

多语言支持

支持任务执行结果的通知和报警功能如任务失败通知、任务超时报警等。

实现原理

调度中心定期扫描数据库中的任务根据任务的调度策略生成调度事件。

HTTP

执行器通过心跳机制定期向调度中心报告状态调度中心根据执行器的状态分配任务保证任务的高可用性。

使用方法

dependencygroupIdcom.xuxueli/groupIdartifactIdxxl-job-core/artifactIdversion2.3.0/version

/dependency配置执行器

{Value(${xxl.job.admin.addresses})private

String

adminAddresses;Value(${xxl.job.executor.appname})private

String

appName;Value(${xxl.job.executor.ip})private

String

ip;Value(${xxl.job.executor.port})private

int

port;Value(${xxl.job.accessToken})private

String

accessToken;Value(${xxl.job.executor.logpath})private

String

logPath;Value(${xxl.job.executor.logretentiondays})private

int

XxlJobSpringExecutor();xxlJobSpringExecutor.setAdminAddresses(adminAddresses);xxlJobSpringExecutor.setAppName(appName);xxlJobSpringExecutor.setIp(ip);xxlJobSpringExecutor.setPort(port);xxlJobSpringExecutor.setAccessToken(accessToken);xxlJobSpringExecutor.setLogPath(logPath);xxlJobSpringExecutor.setLogRetentionDays(logRetentionDays);return

定义任务

{XxlJob(sampleJobHandler)public

ReturnTString

https://github.com/xuxueli/xxl-job/

相对来说xxl-job中心式的调度平台轻量级开箱即用操作简易上手快与SpringBoot有非常好的集成而且监控界面就集成在调度中心界面又简洁对于企业维护起来成本不高还有失败的邮件告警等等。

这就使很多企业选择xxl-job做调度平台。

实际上更多公司选择xxl-job目前xxl-job的github上有15.7k个star登记公司有348个。

毫无疑问elasticjob和xxl-job都是非常优秀的技术框架接下来我们进一步对比讨论探索一下为什么更多公司会选择xxl-job。

首先先介绍一下xxl-job这是出自大众点评许雪里(xxl就是作者名字的拼音首字母)的开源项目官网上介绍这是一个轻量级分布式任务调度框架其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

跟elasticjob不同xxl-job环境依赖于mysql不用ZooKeeper这也是最大的不同。

elasticjob的初衷是为了面对高并发复杂的业务即使是在业务量大服务器多的时候也能做好任务调度尽可能的利用服务器的资源。

使用ZooKeeper使其具有高可用、一致性的而且还具有良好的扩展性。

官网上写

elasticjob是无中心化的通过ZooKeeper的选举机制选举出主服务器如果主服务器挂了会重新选举新的主服务器。

因此elasticjob具有良好的扩展性和可用性但是使用和运维有一定的复杂

xl-job则相反是通过一个中心式的调度平台调度多个执行器执行任务调度中心通过DB锁保证集群分布式调度的一致性这样扩展执行器会增大DB的压力但是如果实际上这里数据库只是负责任务的调度执行。

但是如果没有大量的执行器的话和任务的情况是不会造成数据库压力的。

实际上大部分公司任务数执行器并不多(虽然面试经常会问一些高并发的问题)。

分别有调度中心和执行器两大组成部分

调度中心。

负责管理调度信息按照调度配置发出调度请求自身不承担业务代码。

支持可视化界面可以在调度中心对任务进行新增更新删除会实时生效。

支持监控调度结果查看执行日志查看调度任务统计报表任务失败告警等等。

执行器。

负责接收调度请求执行调度任务的业务逻辑。

执行器启动后需要注册到调度中心。

接收调度中心的发出的执行请求终止请求日志请求等等。

接下来我们看一下xxl-job的工作原理。

任务执行器根据配置的调度中心的地址自动注册到调度中心。

达到任务触发条件调度中心下发任务。

执行器基于线程池执行任务并把执行结果放入内存队列中、把执行日志写入日志文件中。

执行器的回调线程消费内存队列中的执行结果主动上报给调度中心。

当用户在调度中心查看任务日志调度中心请求任务执行器任务执行器读取任务日志文件并返回日志详情

为什么需要任务调度平台

在Java中传统的定时任务实现方案比如TimerQuartz等都或多或少存在一些问题

不支持集群、不支持统计、没有管理平台、没有失败报警、没有监控等等而且在现在分布式的架构中有一些场景需要分布式任务调度同一个服务多个实例的任务存在互斥时需要统一的调度。

任务调度需要支持高可用、监控、故障告警。

需要统一管理和追踪各个服务节点任务调度的结果需要记录保存任务属性信息等。

显然传统的定时任务已经不满足现在的分布式架构所以需要一个分布式任务调度平台目前比较主流的是elasticjob和xxl-job。

elasticjob由当当网开源目前github有6.5k的Star使用的公司在官网登记有76家。

跟xxl-job不同的是elasticjob是采用zookeeper实现分布式协调实现任务高可用以及分片。

XXL-Job分片

中分片是指将一个大任务拆分成多个小任务进行执行的机制。

下面是对

XXL-Job

将一个大的任务分解成多个小任务每个小任务称为一个任务分片。

每个任务分片可以独立执行相互之间不会产生影响。

分片数量任务分片的数量由用户指定可以根据实际需求进行调整。

通常情况下分片数量取决于任务的处理逻辑和数据量大小。

分片策略XXL-Job

提供了多种分片策略用户可以根据实际情况选择合适的策略。

常见的分片策略包括固定分片和动态分片两种

动态分片根据数据量大小或者其他条件动态地确定分片数量使得每个分片的数据量尽可能均匀。

分片执行XXL-Job

会将任务分片分发给执行器节点执行。

每个执行器节点负责执行其中的一个或多个分片执行结果会汇总到调度中心进行统计和监控。

分片参数传递对于每个任务分片XXL-Job

允许用户传递参数以便在执行任务时使用。

这些参数可以包括任务的起始位置、结束位置、分片序号等信息。

分片失败处理如果某个任务分片执行失败XXL-Job

允许用户设置失败处理策略。

常见的失败处理策略包括重试、忽略、记录异常信息等。

监控和报警XXL-Job

提供了丰富的监控和报警功能用户可以实时监控任务的执行情况和任务分片的运行状态及时发现和处理异常情况。

的分片机制能够有效地提高任务的并发执行能力和处理效率同时也能够保证任务的可靠性和稳定性。

通过合理地设置分片参数和选择适当的分片策略可以充分发挥任务调度平台的性能和效果。

elastic-job

是由当当网开源的一款分布式调度解决方案主要用于大数据环境下的作业调度。

它支持多种类型的作业调度和任务执行策略具有高可用性和扩展性适合处理大规模、高并发的任务调度需求。

以下是对

Elastic-Job

是一个功能强大且灵活的分布式任务调度框架通过其高可用性设计、分片机制和丰富的作业治理功能可以满足各种复杂任务调度需求。

在实际使用中通过合理配置和使用其提供的API可以实现高效稳定的任务调度和管理。

架构设计

维护作业的元数据、分片信息和执行状态保证任务的统一调度和高可用性。

执行器Executor

执行器是实际执行任务的节点注册到调度中心并从调度中心获取任务。

Zookeeper

用于协调和管理调度中心和执行器之间的交互提供分布式锁和节点状态管理功能。

核心功能

支持将一个任务拆分为多个子任务通过分片机制实现任务的并行处理。

弹性扩展

支持简单作业、数据流作业和脚本作业适用于不同类型的任务调度需求。

作业治理

提供丰富的作业治理功能如作业状态监控、执行日志管理和作业分片策略调整。

任务依赖

执行器注册到调度中心并定期上报状态调度中心根据执行器的状态分配任务。

Zookeeper

调度中心和执行器会记录详细的作业执行日志和状态提供丰富的监控和管理功能。

使用方法

org.apache.shardingsphere.elasticjob

elasticjob-lite-core

elasticjob:regCenter:serverLists:

elasticjob-demojob:simple:name:

mySimpleJobcron:

{System.out.println(String.format(Item:

Time:

%s,shardingContext.getShardingItem(),

LocalDateTime.now(),Thread.currentThread().getId(),

shardingContext.getJobParameter()));}

}启动作业

与XXL-JOB相比Elastic-Job采用无中心化解决方案而XXL-JOB则采用中心集权方式。

Elastic-Job更注重于分布式环境下的任务调度和协调而XXL-JOB则更注重于任务的灵活性和易扩展性。

官方文档与资源

官方文档提供了Elastic-Job的详细使用教程、API文档和最佳实践案例。

官方网站https://shardingsphere.apache.org/elasticjob/

源码地址https://gitee.com/ityml/elastic-job-zgc