共计 3380 个字符，预计需要花费 9 分钟才能阅读完成。
上一篇，咱们介绍了如何应用 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，分享其余中央看不到的常识与思考
