基于XXL-JOB二次开发：为kill job引入安全检查点机制

转载

mb5fe18f5282239 2021-06-06 11:02:27

文章标签 java 文章分类 Java 后端开发

关于XXL-JOB-ONION

XXL-JOB-ONION是基于XXL-JOB的二次开发，我们基于XXL-JOB二次开发做了扩展，如添加ONION_BEAN运行模式、完善告警功能。

基于XXL-JOB二次开发：为kill job引入安全检查点机制_java

关于ONION_BEAN模式：

对于不需要分片的定时任务：通过继承OnionJobHandler接口实现，而不是使用XXL-JOB提供的注解；
对于需要分片的定时任务：通过继承OnionShardingJobHandler接口实现，而不是使用XXL-JOB提供的注解；

本篇内容：

背景
概要设计
关于安全检查点的设计
两种使用方式

背景

根据我们目前项目中的定时任务考察，发现定时任务大多都有一个共同点：每个定时任务都是从数据库查询一批数据出来处理，并且将每条数据转为一个Runable放入业务隔离的线程池中执行，例如:

@Component
public class OnionXxlJob implements OnionJobHandler<JobParam> {
    @Override
    public void doExecute(JobParam param) throws Exception {
        // 实际从数据库查询
        List<Integer> orderIds = Arrays.asList(10000, 11111);
        // 这里使用并行流模拟将每个订单放入线程池处理
        orderIds.parallelStream().forEach(orderService::handlerOrder);
    }
}

由于定时任务每次执行需要处理大批量数据，可能执行一次需要一个半小时，为解决每次版本更新或者应对突发数据量需要修改配置重启时都需要等待定时任务执行完成、想kill不敢kill的尴尬，我们为xxl-job引入安全检查点机制，灵感来源于jvm垃圾回收的安全检查点机制。

为什么说想kill不敢kill？

虽然需要涉及到数据库的操作都放在事务中，但并不是所有操作都能回滚，例如修改redis缓存数据、ES数据的操作都无法回滚（一般能放到事务提交之后的都放到后面执行），如果处理数据的过程中需要调用第三方接口，那么会更复杂（这点我们已经通过回放机制实现）。

假设几百个线程同时在处理，突然kill掉执行中的任务，意味着可能几百条数据处理出现问题，我们不得不找出这些数据，将未完成的步骤完成。

概要设计

我们先分析下XXL-JOB的kill job流程：xxl-job-admin前端发起kill请求，admin接收后向执行器发起kill请求并携带jobId，执行器根据jobId判断当前任务是否再执行，如果是则取消。

是否有一种方案，当定时任务管理员从后台发起kill job操作时，先等待任务进入一个安全点再kill任务呢？

我们来看下面这张图：

流程说明：

1、管理员在admin操作向执行器发起kill请求、或执行器自身为实现阻塞策略向自己发起kill请求；
2、执行器接收到命令后，先获取JobHandler，通知JobHandler的安全检查点管理员，不让新的Runable进入检查点；
3、询问JobHandler的安全检查点计数器，可实现阻塞等待计数器的值为0再kill，或者异步等待计数器为0再kill；
4、XXL-JOB会为每个Job分配一个ID，通过每个JobId持有一个计数器可以隔离同Job不同时间段触发的任务，当然，XXL-JOB也不允许同时执行多个相同的Job；