上一篇，我们介绍了如何使用Elastic Job实现定时任务。解决了使用@Scheduled来实现时候存在的竞争问题，同时也实现了定时任务的高可用执行。
然而，还有一类问题是我们在做定时任务时候容易出现的，就是任务执行速度时间过长；同时，为了实现定时任务的高可用，还启动了很多任务实例，但每个任务执行时候就一个实例在跑，资源利用率不高。
所以，接下来我们就来继续介绍，使用Elastic Job的分片配置，来为任务执行加加速，资源利用抬抬高的目标！

动手试试

第一步：创建一个分片执行的任务

  1. @Slf4j
  2. @Service
  3. public class MyShardingJob implements SimpleJob {
  5.     @Override
  6.     public void execute(ShardingContext context) {
  7.         switch (context.getShardingItem()) {
  8.             case 0:
  9.                 log.info("分片1：执行任务");
  10.                 break;
  11.             case 1:
  12.                 log.info("分片2：执行任务");
  13.                 break;
  14.             case 2:
  15.                 log.info("分片3：执行任务");
  16.                 break;
  17.         }
  18.     }
  20. }

这里通过switch来判断当前任务上下文的sharding-item值来执行不同的分片任务。sharding-item的值取决于后面将要配置的分片总数，但注意是从0开始计数的。 这里仅采用了日志打印的方式，来展示分片效果，真正实现业务逻辑的时候，一定记得根据分片数量对执行任务也要做分片操作的设计。比如：你可以根据批量任务的id求摩的方式来区分不同分片处理不同的数据，以避免重复执行而出现问题。
第二步：在配置文件中，设置配置任务的实现类、执行表达式、以及将要重要测试的分片总数参数

  1. # zookeeper地址
  2. elasticjob.reg-center.server-lists=localhost:2181
  3. # zookeeper命名空间
  4. elasticjob.reg-center.namespace=snow-1
  5. # 指定配置任务的实现类
  6. elasticjob.jobs.my-simple-job.elastic-job-class=com.snow.task.MyShardingJob
  7. # 执行调度表达式
  8. elasticjob.jobs.my-simple-job.cron=0/5 * * * * ?
  9. # 分片数量
  10. elasticjob.jobs.my-simple-job.sharding-total-count=3

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

运行与测试

单实例运行
在完成了上面的代码之后，尝试启动上面实现的第一个实例。
此时，我们可以看到，每间隔5秒，这个实例会打印这样的日志：
image.png
每次任务都被拆分成了3个分片任务，就如我上文中所说的，每个分片对应一个switch的分支。由于当前情况下，我们只启动了一个实例，所以3个分片任务都被分配到了这个唯一的实例上。
双实例运行
接下来，我们再启动一个实例（注意使用-Dserver.port来改变不同的端口，不然本地会启动不成功）。此时，两个实例的日志出现了变化：
实例1的日志：
image.png
实例2的日志：
image.png
随着实例数量的增加，可以看到分片的分配发生了变化。这也就意味着，当一个任务开始执行的时候，两个任务执行实例都被利用了起来，这样我们的任务执行和资源利用的效率就可以得到优化。
启动实例3：
image.png
可以发现其他实例也发生了变化
image.png
你也可以尝试再继续启动实例和关闭实例来观察任务的动态分配

Elastic Job的namespace属性

类似错误消息Job conflict with register center. The job ‘my-simple-job’ in register center’s，初步判断是ZooKeeper中存储的任务配置出现冲突：任务名一样，但实现类不同。 实际上，如果我们在一个大一些的团队做开发的时候，只要存在多系统的话，那么定时任务的重名其实是很有可能发生。

方法一：任务创建的统一管理

最原始的处理方法，就是集中的管理任务创建流程，比如：可以开一个Wiki页面，所有任务在这个页面上登记，每个人登记的时候，可以查一下想起的名字是否已经存在。如果存在了就再想一个名字，并做好登记。
这种方法很简单，也很好理解。但存在的问题是，当任务非常非常多的时候，这个页面内容就很大，维护起来也是非常麻烦的。

方法二：巧用Elastic Job的namespace属性来隔离任务名称

  1. spring.application.name=SpringBootApplication
  3. elasticjob.reg-center.server-lists=localhost:2181
  4. elasticjob.reg-center.namespace=${spring.application.name}

即：将定时任务服务的elasticjob.reg-center.namespace设置为当前Spring Boot应用的名称一致spring.application.name。
通常，我们在规划各个Spring Boot应用的时候，都会做好唯一性的规划，这样未来注册到Eureka、Nacos等注册中心的时候，也可以保证唯一。
利用好这个唯一参数，也可以方便的帮我们把各个应用的定时任务也都隔离出来