在上一篇博客中介绍了ElasticJob的作业分片策略：
- ElasticJob‐Lite：作业分片策略介绍与源码分析
其中提到了ElasticJob是通过Java提供的SPI机制（ServiceLoader类）加载所有作业分片策略。
ServiceLoader类就是Java提供的SPI，SPI（Service Provider Interface）是JDK内置的一种服务提供发现机制，可以用来启用框架扩展和替换组件，主要是被框架的开发人员使用，不同厂商可以针对同一接口做出不同的实现，比如java.sql.Driver接口，MySQL和PostgreSQL都提供了对应的实现给用户使用，而Java的SPI机制可以为某个接口寻找服务实现。Java中SPI机制主要思想是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是解耦。
ServiceLoader类正常工作的唯一要求是服务提供类必须具有无参构造函数，以便它们可以在加载期间实例化。通过在资源目录的meta-INF/services中放置服务提供者配置文件来标识服务提供者，文件名是服务类型的完全限定名（比如ElasticJobListener类的完全限定名），该文件包含具体的服务提供者类的完全限定名列表（ElasticJobListener实现类的完全限定名列表），每行一个，每个名称周围的空格和制表符以及空行都将被忽略，该文件必须以UTF-8编码。
自定义作业分片策略所有可用的作业分片策略在JobShardingStrategyFactory类的静态块中被加载（通过ElasticJobServiceLoader类，该类是ElasticJob基于Java SPI机制实现的特定于作业的服务加载器）。
static {
ElasticJobServiceLoader.registerTypedService(JobShardingStrategy.class);
}
加载的类型是JobShardingStrategy.class，因此自定义的作业分片策略需要实现该接口。
自定义作业分片策略ShuffleJobShardingStrategy类：
package com.kaven.job.my;
import org.apache.shardingsphere.elasticjob.infra.handler.sharding.JobInstance;
import org.apache.shardingsphere.elasticjob.infra.handler.sharding.JobShardingStrategy;
import java.util.*;
public class ShuffleJobShardingStrategy implements JobShardingStrategy {
@Override
public Map> sharding(final List jobInstances, final String jobName, final int shardingTotalCount) {
if (jobInstances.isEmpty()) {
return Collections.emptyMap();
}
// 先将作业分片项装入容器
List shuffleShardingList = new ArrayList<>(shardingTotalCount);
for (int i = 0; i < shardingTotalCount; i++) {
shuffleShardingList.add(i);
}
// 将容器中的作业分片项顺序打乱（使用容器的shuffle方法）
Collections.shuffle(shuffleShardingList);
// 模仿AverageAllocationJobShardingStrategy作业分片策略进行分配
Map> result = shardingShuffle(jobInstances, shardingTotalCount, shuffleShardingList);
addShuffle(jobInstances, shardingTotalCount, result, shuffleShardingList);
return result;
}
private Map> shardingShuffle(final List shardingUnits,
final int shardingTotalCount,
final List shuffleShardingList) {
Map> result = new linkedHashMap<>(shardingUnits.size(), 1);
// 每个作业服务器最少应该分配的作业分片项数
int itemCountPerSharding = shardingTotalCount / shardingUnits.size();
int count = 0;
for (JobInstance each : shardingUnits) {
// 每个作业服务器申请的作业分片项列表（容量为itemCountPerSharding + 1）
// itemCountPerSharding + 1为每个作业服务器最多应该分配的作业分片项数
List shardingItems = new ArrayList<>(itemCountPerSharding + 1);
for (int i = count * itemCountPerSharding; i < (count + 1) * itemCountPerSharding; i++) {
// 给作业分片项列表添加容器中的第i个作业分片项
shardingItems.add(shuffleShardingList.get(i));
}
// 将作业服务器与它执行的作业分片项列表进行关联
result.put(each, shardingItems);
count++;
}
return result;
}
private void addShuffle(final List shardingUnits, final int shardingTotalCount,
final Map> shardingResults,
final List shuffleShardingList) {
// 无法平均分配的分片项数
int aliquant = shardingTotalCount % shardingUnits.size();
// 已分配的无法平均分配的分片项数
int count = 0;
for (Map.Entry> entry : shardingResults.entrySet()) {
// 是否还有无法平均分配的分片项
if (count < aliquant) {
// 分配给序号较小的作业服务器
entry.getValue().add(
shuffleShardingList.get(shardingTotalCount / shardingUnits.size() * shardingUnits.size() + count)
);
}
// 已分配数更新
count++;
}
}
// 作业分片策略的标识符
@Override
public String getType() {
return "Shuffle";
}
}
博主自定义的ShuffleJobShardingStrategy作业分片策略是模仿AverageAllocationJobShardingStrategy作业分片策略（默认的作业分片策略），只是先将作业分片项装入容器，然后将容器中的作业分片项顺序打乱（使用容器的shuffle方法），之后再基于该作业分片项容器使用AverageAllocationJobShardingStrategy作业分片策略给作业服务器分配该容器中的作业分片项，如果不了解AverageAllocationJobShardingStrategy作业分片策略，可以去看看最上面列出的博客。
添加服务实现在resources的meta-INF/services中放置服务提供者配置文件来标识服务提供者，如下图所示：
作业定义（Simple作业）：
package com.kaven.job;
import org.apache.shardingsphere.elasticjob.api.ShardingContext;
import org.apache.shardingsphere.elasticjob.simple.job.SimpleJob;
import java.text.SimpleDateFormat;
import java.util.Date;
public class MySimpleJob implements SimpleJob {
private static final SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
@Override
public void execute(ShardingContext shardingContext) {
String job = shardingContext.getShardingParameter();
if(job == null || job.trim().equals("")) {
System.out.println("请指定帮[Kaven]执行的任务名称！");
throw new RuntimeException();
}
System.out.printf("%s 执行任务%d - [%s]！n", formatter.format(new Date()),
shardingContext.getShardingItem(), job);
}
}
启动类：
package com.kaven.job;
import org.apache.shardingsphere.elasticjob.api.JobConfiguration;
import org.apache.shardingsphere.elasticjob.lite.api.bootstrap.impl.ScheduleJobBootstrap;
import org.apache.shardingsphere.elasticjob.reg.base.CoordinatorRegistryCenter;
import org.apache.shardingsphere.elasticjob.reg.zookeeper.ZookeeperConfiguration;
import org.apache.shardingsphere.elasticjob.reg.zookeeper.ZookeeperRegistryCenter;
public class Application {
public static void main(String[] args) {
new ScheduleJobBootstrap(createRegistryCenter(), new MySimpleJob(), createJobConfiguration())
.schedule();
}
// 注册中心
private static CoordinatorRegistryCenter createRegistryCenter() {
ZookeeperConfiguration zc = new ZookeeperConfiguration("192.168.1.200:9000", "my-job");
zc.setConnectionTimeoutMilliseconds(40000);
zc.setMaxRetries(5);
CoordinatorRegistryCenter regCenter = new ZookeeperRegistryCenter(zc);
regCenter.init();
return regCenter;
}
// 作业配置
private static JobConfiguration createJobConfiguration() {
String jobs = "0=看论文,1=做实验,2=打比赛,3=开组会,4=看书,5=写博客,6=看源码";
return JobConfiguration.newBuilder("MySimpleJob", 7)
.cron("30 0/2 * * * ?")
.shardingItemParameters(jobs)
// 使用自定义的作业分片策略
.jobShardingStrategyType("Shuffle")
.overwrite(true)
.build();
}
}
启动三个作业服务器，输出如下图所示：
输出符合预期，因为自定义作业分片策略是模仿AverageAllocationJobShardingStrategy作业分片策略，但自定义作业分片策略中将作业的分片项顺序打乱了，因此给每个作业服务器分配的作业分片项可能不是连续的。
修改作业配置（使用默认的作业分片策略）：
private static JobConfiguration createJobConfiguration() {
String jobs = "0=看论文,1=做实验,2=打比赛,3=开组会,4=看书,5=写博客,6=看源码";
return JobConfiguration.newBuilder("MySimpleJob", 7)
.cron("30 0/2 * * * ?")
.shardingItemParameters(jobs)
// .jobShardingStrategyType("Shuffle")
.overwrite(true)
.build();
}
启动三个作业服务器，输出如下图所示：
输出符合AverageAllocationJobShardingStrategy作业分片策略，[0,1,6]、[2,3]、[4,5]很显然是有序的，而博主自定义的作业分片策略是乱序的。
ElasticJob如何自定义作业分片策略就介绍到这里，如果博主有说错的地方或者大家有不同的见解，欢迎大家评论补充。
