Java定时任务技术趋势

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: 定时任务是每个业务常见的需求,本文详细介绍Java定时任务的技术趋势

背景

定时任务是每个业务常见的需求,比如每分钟扫描超时支付的订单,每小时清理一次数据库历史数据,每天统计前一天的数据并生成报表等等。

1. Java中自带的解决方案

1.1 使用Timer

创建java.util.TimerTask任务,在run方法中实现业务逻辑。通过java.util.Timer进行调度,支持按照固定频率执行。所有的TimerTask是在同一个线程中串行执行,相互影响。也就是说,对于同一个Timer里的多个TimerTask任务,如果一个TimerTask任务在执行中,其它TimerTask即使到达执行的时间,也只能排队等待。如果有异常产生,线程将退出,整个定时任务就失败。

importjava.util.Timer;
importjava.util.TimerTask;
publicclassTestTimerTask {   
publicstaticvoidmain(String[] args) {
TimerTasktimerTask=newTimerTask() {
@Overridepublicvoidrun() {
System.out.println("hell world");
            }
        };
Timertimer=newTimer();
timer.schedule(timerTask, 10, 3000);
    }  
}

1.2 使用ScheduledExecutorService

基于线程池设计的定时任务解决方案,每个调度任务都会分配到线程池中的一个线程去执行,解决Timer定时器无法并发执行的问题,支持fixedRate和fixedDelay。

importjava.util.concurrent.Executors;
importjava.util.concurrent.ScheduledExecutorService;
importjava.util.concurrent.TimeUnit;
publicclassTestTimerTask {
publicstaticvoidmain(String[] args) {
ScheduledExecutorServiceses=Executors.newScheduledThreadPool(5);
//按照固定频率执行,每隔5秒跑一次ses.scheduleAtFixedRate(newRunnable() {
@Overridepublicvoidrun() {
System.out.println("hello fixedRate");
            }
        }, 0, 5, TimeUnit.SECONDS);
//按照固定延时执行,上次执行完后隔3秒再跑ses.scheduleWithFixedDelay(newRunnable() {
@Overridepublicvoidrun() {
System.out.println("hello fixedDelay");
            }
        }, 0, 3, TimeUnit.SECONDS);
    }
}

2. Spring中自带的解决方案

Springboot中提供了一套轻量级的定时任务工具Spring Task,通过注解可以很方便的配置,支持cron表达式、fixedRate、fixedDelay。

importorg.springframework.scheduling.annotation.EnableScheduling;
importorg.springframework.scheduling.annotation.Scheduled;
importorg.springframework.stereotype.Component;
@Component@EnableSchedulingpublicclassMyTask {
/*** 每分钟的第30秒跑一次*/@Scheduled(cron="30 * * * * ?")
publicvoidtask1() throwsInterruptedException {
System.out.println("hello cron");
    }
/*** 每隔5秒跑一次*/@Scheduled(fixedRate=5000)
publicvoidtask2() throwsInterruptedException {
System.out.println("hello fixedRate");
    }
/*** 上次跑完隔3秒再跑*/@Scheduled(fixedDelay=3000)
publicvoidtask3() throwsInterruptedException {
System.out.println("hello fixedDelay");
    }
}

Spring Task相对于上面提到的两种解决方案,最大的优势就是支持cron表达式,可以处理按照标准时间固定周期执行的业务,比如每天几点几分执行。

3. 业务幂等解决方案

现在的应用基本都是分布式部署,所有机器的代码都是一样的,前面介绍的Java和Spring自带的解决方案,都是进程级别的,每台机器在同一时间点都会执行定时任务。这样会导致需要业务幂等的定时任务业务有问题,比如每月定时给用户推送消息,就会推送多次。

于是,很多应用很自然的就想到了使用分布式锁的解决方案。即每次定时任务执行之前,先去抢锁,抢到锁的执行任务,抢不到锁的不执行。怎么抢锁,又是五花八门,比如使用DB、zookeeper、redis。

3.1 使用DB或者Zookeeper抢锁

使用DB或者Zookeeper抢锁的架构差不多,原理如下:

  1. 定时时间到了,在回调方法里,先去抢锁。
  2. 抢到锁,则继续执行方法,没抢到锁直接返回。
  3. 执行完方法后,释放锁。


示例代码如下

importorg.springframework.scheduling.annotation.EnableScheduling;
importorg.springframework.scheduling.annotation.Scheduled;
importorg.springframework.stereotype.Component;
@Component@EnableSchedulingpublicclassMyTask {
/*** 每分钟的第30秒跑一次*/@Scheduled(cron="30 * * * * ?")
publicvoidtask1() throwsException {
StringlockName="task1";
if (tryLock(lockName)) {
System.out.println("hello cron");
releaseLock(lockName);
        } else {
return;
        }
    }
privatebooleantryLock(StringlockName) {
//TODOreturntrue;
    }
privatevoidreleaseLock(StringlockName) {
//TODO    }
}

当前的这个设计,仔细一点的同学可以发现,其实还是有可能导致任务重复执行的。比如任务执行的非常快,A这台机器抢到锁,执行完任务后很快就释放锁了。B这台机器后抢锁,还是会抢到锁,再执行一遍任务。

3.2 使用redis抢锁

使用redis抢锁,其实架构上和DB/zookeeper差不多,不过redis抢锁支持过期时间,不用主动去释放锁,并且可以充分利用这个过期时间,解决任务执行过快释放锁导致任务重复执行的问题,架构如下:

示例代码如下:

@Component@EnableSchedulingpublicclassMyTask {
/*** 每分钟的第30秒跑一次*/@Scheduled(cron="30 * * * * ?")
publicvoidtask1() throwsInterruptedException {
StringlockName="task1";
if (tryLock(lockName, 30)) {
System.out.println("hello cron");
releaseLock(lockName);
        } else {
return;
        }
    }
privatebooleantryLock(StringlockName, longexpiredTime) {
//TODOreturntrue;
    }
privatevoidreleaseLock(StringlockName) {
//TODO    }
}

看到这里,可能又会有同学有问题,加一个过期时间是不是还是不够严谨,还是有可能任务重复执行?

——的确是的,如果有一台机器突然长时间的fullgc,或者之前的任务还没处理完(Spring Task和ScheduledExecutorService本质还是通过线程池处理任务),还是有可能隔了30秒再去调度任务的。

3.3 使用Quartz

Quartz是一套轻量级的任务调度框架,只需要定义了 Job(任务),Trigger(触发器)和Scheduler(调度器),即可实现一个定时调度能力。支持基于数据库的集群模式,可以做到任务幂等执行

Quartz支持任务幂等执行,其实理论上还是抢DB锁,我们看下quartz的表结构:

Table Name

Description

QRTZ_CALENDARS

存储Quartz的Calendar信息

QRTZ_CRON_TRIGGERS

存储CronTrigger,包括Cron表达式和时区信息

QRTZ_FIRED_TRIGGERS

存储与已触发的Trigger相关的状态信息,以及相联Job的执行信息

QRTZ_PAUSED_TRIGGER_GRPS

存储已暂停的Trigger组的信息

QRTZ_SCHEDULER_STATE

存储少量的有关Scheduler的状态信息,和别的Scheduler实例

QRTZ_LOCKS

存储程序的悲观锁的信息

QRTZ_JOB_DETAILS

存储每一个已配置的Job的详细信息

QRTZ_JOB_LISTENERS

存储有关已配置的JobListener的信息

QRTZ_SIMPLE_TRIGGERS

存储简单的Trigger,包括重复次数、间隔、以及已触的次数

QRTZ_BLOG_TRIGGERS

Trigger作为Blob类型存储

QRTZ_TRIGGER_LISTENERS

存储已配置的TriggerListener的信息

QRTZ_TRIGGERS

存储已配置的Trigger的信息

其中,QRTZ_LOCKS就是Quartz集群实现同步机制的行锁表,其表结构如下:

--QRTZ_LOCKS表结构
CREATE TABLE `QRTZ_LOCKS` (
  `LOCK_NAME` varchar(40) NOT NULL,
  PRIMARY KEY (`LOCK_NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
--QRTZ_LOCKS记录
+-----------------+ 
| LOCK_NAME       |
+-----------------+ 
| CALENDAR_ACCESS |
| JOB_ACCESS      |
| MISFIRE_ACCESS  |
| STATE_ACCESS    |
| TRIGGER_ACCESS  |
+-----------------+

可以看出QRTZ_LOCKS中有5条记录,代表5把锁,分别用于实现多个Quartz Node对Job、Trigger、Calendar访问的同步控制。

4. 开源任务调度中间件

上面提到的解决方案,在架构上都有一个问题,那就是每次调度都需要抢锁,特别是使用DB和Zookeeper抢锁,性能会比较差,一旦任务量增加到一定的量,就会有比较明显的调度延时。还有一个痛点,就是业务想要修改调度配置,或者增加一个任务,得修改代码重新发布应用。

于是开源社区涌现了一堆任务调度中间件,通过任务调度系统进行定,任务的创建、修改和调度,这其中国内最火的就是XXL-JOB和ElasticJob。

4.1 ElasticJob

ElasticJob是一款基于Quartz开发,依赖Zookeeper作为注册中心、轻量级、无中心化的分布式任务调度框架,目前已经通过Apache开源。

ElasticJob相对于Quartz来说,从功能上最大的区别就是支持分片,可以将一个任务分片参数分发给不同的机器执行。架构上最大的区别就是使用Zookeeper作为注册中心,不同的任务分配给不同的节点调度,不需要抢锁触发,性能上比Quartz上强大很多,架构图如下:

开发上也比较简单,和springboot结合比较好,可以在配置文件定义任务如下:

elasticjob:  regCenter:    serverLists: localhost:2181    namespace: elasticjob-lite-springboot
  jobs:    simpleJob:      elasticJobClass: org.apache.shardingsphere.elasticjob.lite.example.job.SpringBootSimpleJob
      cron: 0/5 * * * * ?
      timeZone: GMT+08:00      shardingTotalCount: 3      shardingItemParameters: 0=Beijing,1=Shanghai,2=Guangzhou
    scriptJob:      elasticJobType: SCRIPT
      cron: 0/10 * * * * ?
      shardingTotalCount: 3      props:        script.command.line: "echo SCRIPT Job: "    manualScriptJob:      elasticJobType: SCRIPT
      jobBootstrapBeanName: manualScriptJobBean
      shardingTotalCount: 9      props:        script.command.line: "echo Manual SCRIPT Job: "

实现任务接口如下:

@ComponentpublicclassSpringBootShardingJobimplementsSimpleJob {
@Overridepublicvoidexecute(ShardingContextcontext) {
System.out.println("分片总数="+context.getShardingTotalCount() +", 分片号="+context.getShardingItem()
+", 分片参数="+context.getShardingParameter());
    }
}

运行结果如下:

分片总数=3, 分片号=0, 分片参数=Beijing
分片总数=3, 分片号=1, 分片参数=Shanghai
分片总数=3, 分片号=2, 分片参数=Guangzhou

同时,ElasticJob还提供了一个简单的UI,可以查看任务的列表,同时支持修改、触发、停止、生效、失效操作

遗憾的是,ElasticJob暂不支持动态创建任务。

4.2 XXL-JOB

XXL-JOB是一个开箱即用的轻量级分布式任务调度系统,其核心设计目标是开发迅速、学习简单、轻量级、易扩展,在开源社区广泛流行。

XXL-JOB是Master-Slave架构,Master负责任务的调度,Slave负责任务的执行,架构图如下:

XXL-JOB接入也很方便,不同于ElasticJob定义任务实现类,是通过@XxlJob 注解定义JobHandler

@ComponentpublicclassSampleXxlJob {
privatestaticLoggerlogger=LoggerFactory.getLogger(SampleXxlJob.class);
/*** 1、简单任务示例(Bean模式)*/@XxlJob("demoJobHandler")
publicReturnT<String>demoJobHandler(Stringparam) throwsException {
XxlJobLogger.log("XXL-JOB, Hello World.");
for (inti=0; i<5; i++) {
XxlJobLogger.log("beat at:"+i);
TimeUnit.SECONDS.sleep(2);
        }
returnReturnT.SUCCESS;
    }
/*** 2、分片广播任务*/@XxlJob("shardingJobHandler")
publicReturnT<String>shardingJobHandler(Stringparam) throwsException {
// 分片参数ShardingUtil.ShardingVOshardingVO=ShardingUtil.getShardingVo();
XxlJobLogger.log("分片参数:当前分片序号 = {}, 总分片数 = {}", shardingVO.getIndex(), shardingVO.getTotal());
// 业务逻辑for (inti=0; i<shardingVO.getTotal(); i++) {
if (i==shardingVO.getIndex()) {
XxlJobLogger.log("第 {} 片, 命中分片开始处理", i);
            } else {
XxlJobLogger.log("第 {} 片, 忽略", i);
            }
        }
returnReturnT.SUCCESS;
    }
}

XXL-JOB相较于ElasticJob,最大的特点就是功能比较丰富,可运维能力比较强,不但支持控制台动态创建任务,还有调度日志、运行报表等功能。

XXL-JOB的历史记录、运行报表和调度日志,都是基于数据库实现的

由此可以看出,XXL-JOB所有功能都依赖数据库,且调度中心不支持分布式架构,在任务量和调度量比较大的情况下,会有性能瓶颈。不过如果对任务量级、高可用、监控报警、可视化等没有过高要求的话,XXL-JOB基本可以满足定时任务的需求。

5. 企业级解决方案

开源软件只能提供基础的调度能力,在监管控上的能力一般都比较弱。比如日志服务,业界往往使用ELK解决方案;短信报警,需要有短信平台;监控大盘,现在主流的解决方案是Prometheus;等等。企业想要有这些能力,不但需要额外的开发成本,还需要昂贵的资源成本。

另外使用开源软件也伴随着稳定性的风险,就是出了问题没人能处理,想要反馈到社区等社区处理,这个链路太长了,早就产生故障了。

阿里云任务调度SchedulerX是阿里巴巴自研的基于Akka架构的一站式任务调度平台,兼容开源XXL-JOB、ElasticJob、Quartz(规划中),支持Cron定时、一次性任务、任务编排、分布式跑批,具有高可用、可视化、可运维、低延时等能力,自带企业级监控大盘、日志服务、短信报警等服务。

5.1 优势

安全防护

  • 多层次安全防护:支持 HTTPS 和 VPC 访问,同时还有阿里云的多层安全防护,防止恶意攻击。
  • 多租户隔离机制:支持多地域、命名空间和应用级别的隔离。
  • 权限管控:支持控制台读写的权限管理,客户端接入的鉴权。

企业级高可用

SchedulerX2.0采用高可用架构,任务多备份机制,经历阿里集团多年双十一、容灾演练,可以做到任意一个机房挂了,任务调度都不会收到影响。

商业级报警运维

  • 报警:支持邮件、钉钉、短信、电话,(其他报警方式在规划中)。支持任务失败、超时、无可用机器报警。报警内容可以直接看出任务失败的原因,以钉钉机器人为例

  • 运维操作:原地重跑、重刷数据、标记成功、查看堆栈、停止任务、指定机器等

丰富的可视化

schedulerx拥有丰富的可视化能力,比如

  • 用户大盘

  • 查看任务历史执行记录

  • 查看任务运行日志

  • 查看任务运行堆栈

  • 查看任务操作记录

兼容开源

Schedulerx兼容开源XXL-JOB、ElasticJob、Quartz(规划中),业务不需要改一行代码,即可以将任务托管在SchedulerX调度平台,享有企业级可视化和报警的能力。

Spring原生

SchedulerX支持通过控制台和API动态创建任务,也支持Spring声明式任务定义,一份任务配置可以拿到任何环境一键启动,配置如下:

spring:   schedulerx2:      endpoint: acm.aliyun.com   #请填写不同regin的endpoint      namespace: 433d8b23-06e9-xxxx-xxxx-90d4d1b9a4af #region内全局唯一,建议使用UUID生成      namespaceName: 学仁测试
      appName: myTest
      groupId: myTest.group      #同一个命名空间下需要唯一      appKey: myTest123@alibaba  #应用的key,不要太简单,注意保管好      regionId: public           #填写对应的regionId      aliyunAccessKey: xxxxxxx   #阿里云账号的ak      aliyunSecretKey: xxxxxxx   #阿里云账号的sk      alarmChannel: sms,ding     #报警通道:短信和钉钉      jobs:          simpleJob:             jobModel: standalone
            className: com.aliyun.schedulerx.example.processor.SimpleJob
            cron: 0/30 * * * * ?   # cron表达式            jobParameter: hello
            overwrite: true 
         shardingJob:             jobModel: sharding
            className: ccom.aliyun.schedulerx.example.processor.ShardingJob
            oneTime: 2022-06-02 12:00:00   # 一次性任务表达式            jobParameter: 0=Beijing,1=Shanghai,2=Guangzhou
            overwrite: true         broadcastJob:   # 不填写cron和oneTime,表示api任务            jobModel: broadcast
            className: com.aliyun.schedulerx.example.processor.BroadcastJob
            jobParameter: hello
            overwrite: true         mapReduceJob:             jobModel: mapreduce
            className: com.aliyun.schedulerx.example.processor.MapReduceJob
            cron: 0 * * * * ?
            jobParameter: 100            overwrite: true      alarmUsers:     #报警联系人         user1:            userName: 张三
            userPhone: 12345678900         user2:            userName: 李四
            ding: https://oapi.dingtalk.com/robot/send?access_token=xxxxx

分布式跑批

SchedulerX提供了丰富的分布式模型,可以处理各种各样的分布式业务场景。包括单机、广播、分片、MapReduce等,架构如下:

SchedulerX的MapReduce模型,简单几行代码,就可以将海量任务分布式到多台机器跑批,相对于大数据跑批来说,具有速度快、数据安全、成本低、简单易学等特点。

任务编排

SchedulerX通过工作流进行任务编排,并且提供了一个可视化的界面,操作简单,拖拖拽拽即可配置一个工作流。详细的任务状态图能一目了然看到下游任务为什么没跑,方便定位问题

可抢占的任务优先级队列

常见场景是夜间离线报表业务,比如很多报表任务是晚上1、2点开始跑,要控制应用最大并发的任务数量(否则业务扛不住),达到并发上限的任务会在队列中等待。同时要求早上9点前必须把KPI报表跑出来,可以设置KPI任务高优先级,会抢占低优先级任务优先调度。

SchedulerX支持可抢占的任务优先级队列,可以在控制台动态配置:

5.2 QA

  1. k8s应用可以接入SchedulerX吗?

——可以的,无论是物理机、容器、还是k8s pod,都可以接入SchedulerX。


  1. 我的应用不在阿里云上,可否使用SchedulerX?

——可以的,任何云平台或者本地机器,只要能访问公网,都可以接入SchedulerX。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
27天前
|
Java 调度
Java实现定时启动,且只执行一次,如何实现?
【10月更文挑战第18天】Java实现定时启动,且只执行一次,如何实现?
163 3
|
13天前
|
JSON 前端开发 JavaScript
java-ajax技术详解!!!
本文介绍了Ajax技术及其工作原理,包括其核心XMLHttpRequest对象的属性和方法。Ajax通过异步通信技术,实现在不重新加载整个页面的情况下更新部分网页内容。文章还详细描述了使用原生JavaScript实现Ajax的基本步骤,以及利用jQuery简化Ajax操作的方法。最后,介绍了JSON作为轻量级数据交换格式在Ajax应用中的使用,包括Java中JSON与对象的相互转换。
29 1
|
21天前
|
SQL 监控 Java
技术前沿:Java连接池技术的最新发展与应用
本文探讨了Java连接池技术的最新发展与应用,包括高性能与低延迟、智能化管理和监控、扩展性与兼容性等方面。同时,结合最佳实践,介绍了如何选择合适的连接池库、合理配置参数、使用监控工具及优化数据库操作,为开发者提供了一份详尽的技术指南。
29 7
|
23天前
|
移动开发 前端开发 Java
过时的Java技术盘点:避免在这些领域浪费时间
【10月更文挑战第14天】 在快速发展的Java生态系统中,新技术层出不穷,而一些旧技术则逐渐被淘汰。对于Java开发者来说,了解哪些技术已经过时是至关重要的,这可以帮助他们避免在这些领域浪费时间,并将精力集中在更有前景的技术上。本文将盘点一些已经或即将被淘汰的Java技术,为开发者提供指导。
50 7
|
19天前
|
SQL Java 数据库连接
在Java应用中,数据库访问常成为性能瓶颈。连接池技术通过预建立并复用数据库连接,有效减少连接开销,提升访问效率
在Java应用中,数据库访问常成为性能瓶颈。连接池技术通过预建立并复用数据库连接,有效减少连接开销,提升访问效率。本文介绍了连接池的工作原理、优势及实现方法,并提供了HikariCP的示例代码。
32 3
|
19天前
|
SQL 监控 Java
Java连接池技术的最新发展,包括高性能与低延迟、智能化管理与监控、扩展性与兼容性等方面
本文探讨了Java连接池技术的最新发展,包括高性能与低延迟、智能化管理与监控、扩展性与兼容性等方面。同时,结合最佳实践,介绍了如何选择合适的连接池库、合理配置参数、使用监控工具及优化数据库操作,以实现高效稳定的数据库访问。示例代码展示了如何使用HikariCP连接池。
12 2
|
21天前
|
Java 数据库连接 数据库
优化之路:Java连接池技术助力数据库性能飞跃
在Java应用开发中,数据库操作常成为性能瓶颈。频繁的数据库连接建立和断开增加了系统开销,导致性能下降。本文通过问题解答形式,深入探讨Java连接池技术如何通过复用数据库连接,显著减少连接开销,提升系统性能。文章详细介绍了连接池的优势、选择标准、使用方法及优化策略,帮助开发者实现数据库性能的飞跃。
25 4
|
19天前
|
Java 数据库连接 数据库
深入探讨Java连接池技术如何通过复用数据库连接、减少连接建立和断开的开销,从而显著提升系统性能
在Java应用开发中,数据库操作常成为性能瓶颈。本文通过问题解答形式,深入探讨Java连接池技术如何通过复用数据库连接、减少连接建立和断开的开销,从而显著提升系统性能。文章介绍了连接池的优势、选择和使用方法,以及优化配置的技巧。
17 1
|
19天前
|
算法 Java 数据库连接
Java连接池技术,从基础概念出发,解析了连接池的工作原理及其重要性
本文详细介绍了Java连接池技术,从基础概念出发,解析了连接池的工作原理及其重要性。连接池通过复用数据库连接,显著提升了应用的性能和稳定性。文章还展示了使用HikariCP连接池的示例代码,帮助读者更好地理解和应用这一技术。
31 1
|
21天前
|
SQL Java 数据库连接
打破瓶颈:利用Java连接池技术提升数据库访问效率
在Java应用中,数据库访问常成为性能瓶颈。连接池技术通过预建立并复用数据库连接,避免了频繁的连接建立和断开,显著提升了数据库访问效率。常见的连接池库包括HikariCP、C3P0和DBCP,它们提供了丰富的配置选项和强大的功能,帮助优化应用性能。
39 2