乐趣区

关于java:使用Elastic-Job的分片配置加速任务执行和提高资源利用率

上一篇,咱们介绍了如何应用 Elastic Job 实现定时工作。解决了应用 @Scheduled 来实现时候存在的竞争问题,同时也实现了定时工作的高可用执行。

然而,还有一类问题是咱们在做定时工作时候容易呈现的,就是工作执行速度工夫过长;同时,为了实现定时工作的高可用,还启动了很多工作实例,但每个工作执行时候就一个实例在跑,资源利用率不高。

所以,接下来咱们就来持续介绍,应用 Elastic Job 的分片配置,来为工作执行加减速,资源利用抬贬低的指标!

入手试试

倡议间接下载文末仓库中的 chapter7-2 工程,而后在这个根底上进行批改。当然,如果你对如何应用 Elastic Job 还不输出,那么先返回上一篇做个常识铺垫,再持续上面的内容!

第一步:创立一个分片执行的工作

@Slf4j
@Service
public class MyShardingJob implements SimpleJob {

    @Override
    public void execute(ShardingContext context) {switch (context.getShardingItem()) {
            case 0:
                log.info("分片 1:执行工作");
                break;
            case 1:
                log.info("分片 2:执行工作");
                break;
            case 2:
                log.info("分片 3:执行工作");
                break;
        }
    }

}

这里通过 switch 来判断当前任务上下文的 sharding-item 值来执行不同的分片工作。sharding-item 的值取决于前面将要配置的分片总数,但留神是从 0 开始计数的。这里仅采纳了日志打印的形式,来展现分片成果,真正实现业务逻辑的时候,肯定记得依据分片数量对执行工作也要做分片操作的设计。比方:你能够依据批量工作的 id 求摩的形式来辨别不同分片解决不同的数据,以防止反复执行而呈现问题。

第二步:在配置文件中,设置配置工作的实现类、执行表达式、以及将要重要测试的分片总数参数

elasticjob.jobs.my-sharding-job.elastic-job-class=com.didispace.chapter73.MyShardingJob
elasticjob.jobs.my-sharding-job.cron=0/5 * * * * ?
elasticjob.jobs.my-sharding-job.sharding-total-count=3

这里设置为 3,所以工作会被分为 3 个分片,每个分片对应第一步中一个 switch 的分支。

运行与测试

单实例运行

在实现了下面的代码之后,尝试启动下面实现的第一个实例。

此时,咱们能够看到,每距离 5 秒,这个实例会打印这样的日志:

2021-07-21 17:42:00.122  INFO 63478 --- [main] .s.b.j.ScheduleJobBootstrapStartupRunner : Starting ElasticJob Bootstrap.
2021-07-21 17:42:00.126  INFO 63478 --- [main] org.quartz.core.QuartzScheduler          : Scheduler my-sharding-job_$_NON_CLUSTERED started.
2021-07-21 17:42:00.126  INFO 63478 --- [main] .s.b.j.ScheduleJobBootstrapStartupRunner : ElasticJob Bootstrap started.
2021-07-21 17:42:05.254  INFO 63478 --- [-sharding-job-1] com.didispace.chapter73.MyShardingJob    : 分片 1:执行工作
2021-07-21 17:42:05.254  INFO 63478 --- [-sharding-job-3] com.didispace.chapter73.MyShardingJob    : 分片 3:执行工作
2021-07-21 17:42:05.254  INFO 63478 --- [-sharding-job-2] com.didispace.chapter73.MyShardingJob    : 分片 2:执行工作
2021-07-21 17:42:10.011  INFO 63478 --- [-sharding-job-4] com.didispace.chapter73.MyShardingJob    : 分片 1:执行工作
2021-07-21 17:42:10.011  INFO 63478 --- [-sharding-job-5] com.didispace.chapter73.MyShardingJob    : 分片 2:执行工作
2021-07-21 17:42:10.011  INFO 63478 --- [-sharding-job-6] com.didispace.chapter73.MyShardingJob    : 分片 3:执行工作

每次工作都被拆分成了 3 个分片工作,就如我上文中所说的,每个分片对应一个 switch 的分支。因为当前情况下,咱们只启动了一个实例,所以 3 个分片工作都被调配到了这个惟一的实例上。

双实例运行

接下来,咱们再启动一个实例(留神应用 -Dserver.port 来扭转不同的端口,不然本地会启动不胜利)。此时,两个实例的日志呈现了变动:

实例 1 的日志:

2021-07-21 17:44:50.190  INFO 63478 --- [ng-job_Worker-1] com.didispace.chapter73.MyShardingJob    : 分片 2:执行工作
2021-07-21 17:44:55.007  INFO 63478 --- [ng-job_Worker-1] com.didispace.chapter73.MyShardingJob    : 分片 2:执行工作
2021-07-21 17:45:00.010  INFO 63478 --- [ng-job_Worker-1] com.didispace.chapter73.MyShardingJob    : 分片 2:执行工作

实例 2 的日志:

2021-07-21 17:44:50.272  INFO 63484 --- [-sharding-job-1] com.didispace.chapter73.MyShardingJob    : 分片 1:执行工作
2021-07-21 17:44:50.273  INFO 63484 --- [-sharding-job-2] com.didispace.chapter73.MyShardingJob    : 分片 3:执行工作
2021-07-21 17:44:55.009  INFO 63484 --- [-sharding-job-3] com.didispace.chapter73.MyShardingJob    : 分片 1:执行工作
2021-07-21 17:44:55.009  INFO 63484 --- [-sharding-job-4] com.didispace.chapter73.MyShardingJob    : 分片 3:执行工作

随着实例数量的减少,能够看到分片的调配产生了变动。这也就意味着,当一个工作开始执行的时候,两个工作执行实例都被利用了起来,这样咱们的工作执行和资源利用的效率就能够失去优化。

你也能够尝试再持续启动实例和敞开实例来察看工作的动态分配,怎么样?这样写定时工作是不是不便多了?肯定记得本人入手写一写,这样领会更深哦!如果碰到问题,能够拉取文末的代码示例比照一下是否有中央配置不一样。下一篇,咱们还将持续介绍对于定时工作的一些高级内容。

本系列教程《Spring Boot 2.x 基础教程》点击中转!,欢送珍藏与转发!如果学习过程中如遇艰难?能够退出咱们 Spring 技术交换群,参加交换与探讨,更好的学习与提高!

代码示例

本文的残缺工程能够查看上面仓库中的 chapter7-3 目录:

  • Github:https://github.com/dyc87112/SpringBoot-Learning/
  • Gitee:https://gitee.com/didispace/SpringBoot-Learning/

如果您感觉本文不错,欢送 Star 反对,您的关注是我保持的能源!

欢送关注我的公众号:程序猿 DD,分享其余中央看不到的常识与思考

退出移动版