#Elastic Job

昨天,有群友反应根据之前这篇《使用Elastic Job实现定时任务》文章编写测试定时任务的时候,报了类似下面的这个错误: Caused by: org.apache.shardingsphere.elasticjob.infra.exception.JobConfigurationException: Job conflict with register center. The job 'my-simple-job' in register center's class is 'com.didispace.chapter72.MySimpleJob', your job class is 'com.didispace.chapter74.MySimpleJob' at org.apache.shardingsph...

上一篇,我们介绍了如何使用Elastic Job实现定时任务。解决了使用@Scheduled来实现时候存在的竞争问题,同时也实现了定时任务的高可用执行。 然而,还有一类问题是我们在做定时任务时候容易出现的,就是任务执行速度时间过长;同时,为了实现定时任务的高可用,还启动了很多任务实例,但每个任务执行时候就一个实例在跑,资源利用率不高。 所以,接下来我们就来继续介绍,使用Elastic Job的分片配置,来为任务执行加加速,资源利用抬抬高的目标! 动手试试建议直接下载文末仓库中的chapter7-2工程,然后在这个基础上进行修改。当然,如果你对如何使用Elastic Job还不输入,那么先前往上一篇做个知识铺垫,再继续下面的内容! 第一步:创建一个分片执行的任务 @Slf4j@Servicepublic class MyShardingJob implements SimpleJob ...

上一篇,我们介绍了如何使用Spring Boot自带的@Scheduled注解实现定时任务。文末也提及了这种方式的局限性。当在集群环境下的时候,如果任务的执行或操作依赖一些共享资源的话,就会存在竞争关系。如果不引入分布式锁等机制来做调度的话,就可能出现预料之外的执行结果。所以,@Scheduled注解更偏向于使用在单实例自身维护相关的一些定时任务上会更为合理一些,比如:定时清理服务实例某个目录下的文件、定时上传本实例的一些统计数据等。 那么,在实际实现业务逻辑的时候,没有更好的定时任务方案呢?今天我们就来介绍一个老牌的分布式定时任务框架,在Spring Boot下的使用案例。 Elastic JobElastic Job的前生是当当开源的一款分布式任务调度框架,而目前已经加入到了Apache基金会。 该项目下有两个分支:ElasticJob-Lite和ElasticJob-Cloud...