为什么要使用分布式调度器
分布式调度器主要应用于系统中一些任务定时调度处理。通常我们设计一个定时任务，最简单的就是直接使用@scheduled注解配置好定时任务，这样开发工作也简单。但是也许会有一种情况，如果发生在生产环境上，需要不重启就去变更定时任务时间，或者可能由于某些原因我们需要关闭某个定时任务，那么这时候就无法做到动态化。分布式调度器就能很好的解决这些疑难杂症。
有的人可能会问：现在开源的调度器也有一些很流行的，比如xxl-job，为什么还要自己设计一套。其实我们也不能说开源的设计不好，原因是它的功能太完善，如果要用好还要有人专门运维处理，功能过于强大，大部分功能都是鸡肋，所以自研一套简单的调度服务有些时候还是很有必要的。
分布式调度流程
首先分布式调度器需要依赖数据库配置，主要配置调度服务接口和调度时间。通过调度服务集群获取数据库配置，解析完需要进行调度的任务，由于是job服务的一个集群（也可以单机部署）所以也要考虑到加锁，防止多个job服务同时对一个任务多次调度。最终job服务将解析完的服务接口，检测到触发时间点就对应用服务接口发起任务调度。
分布式调度细节设计分析
数据库设计
job_info表设计：主要记录一些job任务的配置，下面分析一下主要字段：
- job_cron：定时任务触发时间配置
- config_id：关联调度任务服务接口配置主键
- execute_timeout：任务调度超时时间配置，防止调度时间过长无结果
- execute_fail_retry_count：如果任务调度失败重试次数
- job_status：调度任务状态开关配置
- trigger_last_time：最后一次调度时间
- trigger_next_time：下一次执行时间
job_config表设计：主要配置一些任务对应需要调度的服务接口信息。
- execute_servier：所需调度的应用服务
- execute_method：调度应用服务接口
- execute_param：调度参数配置
service_type：服务类型（GET/POST）
job服务调度流程设计
- 读取配置：首先
job服务需要不断的读取数据库配置，从而得知有哪一些任务需要进行调度。可以通过一个while循环加上休眠一段时间不断读取配置，下面就用简短的伪代码做个思路分析：
while(true) {
// PRE_READ_TIME每次刷新时间间隔
TimeUnit.MILLISECONDS.sleep(PRE_READ_TIME - System.currentTimeMillis() % 1000);
// 读取配置，给定一个时间，获取这段时间内要执行调度的任务以及初次配置的任务trigger_next_time=0
List<JobInfo> jobInfos = jobInfoMapper.select(time);
// 循环对任务一一进行解析
// 1.job应用对获取到的任务进行加锁，防止job集群其他服务同时调用，如果确定只会有单机部署可不加锁
int resultCount = jobInfoMapper.updateByOptimisticLock(jobInfo);
// 2.加锁成功继续执行下一步，对首次配置的任务(trigger_next_time=0)需要获取job_cron进行解析，计算出真实的下次执行时间trigger_next_time
refreshNextValidTime(jobInfo, new Date(nowTime));
// 3.即将要执行的任务加入队列
checkHighFrequency(jobInfo, nowTime);
}
private void checkHighFrequency(JobInfo jobInfo, Long nowTime) throws ParseException {
// PRE_READ_TIME = 5000，即提前预留5秒，将任务加入队列
if (jobInfo.getTriggerNextTime() < (nowTime + PRE_READ_TIME)) {
// 将任务放入待执行队列
triggerPoolHelper.triggerJob(jobInfo, jobInfo.getTriggerNextTime() - nowTime);
// 任务加入队列后，再次更新计算下次调度job的时间
refreshNextValidTime(jobInfo, new Date(jobInfo.getTriggerNextTime()));
// 判断是否是超高频繁任务，即调度周期小于5s一次
checkHighFrequency(jobInfo, nowTime);
}
}
// 计算下次执行时间
private void refreshNextValidTime(JobInfo jobInfo, Date fromTime) throws ParseException {
// 时间表达式转换计算下次触发时间
Date nextValidTime = new CronExpression(jobInfo.getJobCron()).getNextValidTimeAfter(fromTime);
if (nextValidTime != null) {
jobInfo.setTriggerLastTime(jobInfo.getTriggerNextTime());
jobInfo.setTriggerNextTime(nextValidTime.getTime());
}
}
- 线程池队列执行任务调度
public void triggerJob(JobInfo jobInfo, long delay) {
JobInfo copyOf = new JobInfo();
BeanUtils.copyProperties(jobInfo, copyOf);
JobTriggerThread triggerThread = new JobTriggerThread(copyOf, tinyJobExecutor.get(jobInfo.getJobType()));
// 小于0说明是延期的任务，立即执行
if (delay <= 0) {
// 加入线程池
triggerPool.execute(triggerThread);
}
// 大于0说明还未到调度时间,延迟调度
else {
triggerPool.schedule(triggerThread, delay, TimeUnit.MILLISECONDS);
}
}
- 任务调度流程：
SpringCloud服务使用DiscoveryClient，根据job_config表配置的服务名获取集群服务列表，再根据随机（或自定义算法）计算获取一个服务实例，用该实例创建请求并发起服务接口调用，最终再根据调用结果进行日志记录，以及失败后续是否进行重试处理。
List<ServiceInstance> serviceInstanceList = discoveryClient.getInstances(jobConfig.getExecuteService());
// 随机获取服务列表（可自定义算法）
ServiceInstance serviceInstance = getRandomInstrance(serviceInstanceList);
CloseableHttpClient httpClient = HttpClients.createDefault();
// 创建请求
HttpPost httpPost = new HttpPost(serviceInstance.getUri() + "/" + jobConfig.getExecuteMethod() + "?" + jobConfig.getExecuteParam());
// http发起调用
CloseableHttpResponse response = httpClient.execute(httpPost);
案例配置说明
-
添加两个定时任务配置，此配置如有需要也可开发个简单的页面方便配置添加与更改。
-
定时任务对应的调度服务接口配置
根据以上的配置，定时刷新获取任务列表，任务首次配置trigger_next_time=0，需解析成具体执行时间点，任务调度判断该时间点是否达到可执行时间，在达到指定时间点job服务将对该接口发起调用并记录调度日志。
总结
使用分布式调度器能够很好的管理我们的定时任务接口，开发人员也只需专注开发业务接口，让业务与配置完全分离。定时配置还可以根据业务场景统一进行时间协调管理，以免在有些时间点多任务同时处理，可以将时间配置的分散点以减轻CPU的压力。如果系统业务量少，定时任务也不多的情况也没必要多浪费时间开发一个调度系统。
