定时任务优雅下线概述
在实际业务中,应用进程内的定时任务会持续按固定频率执行。当应用发布重启时,运行中的定时任务将被强制中断,可能导致数据不完整和调度成功率骤降,最终出现业务数据受损。主要存在以下情况:
因此,在使用定时任务调度的场景下,需要定时任务优雅下线,以实现滚动发布和重启过程中的业务平滑运行。
基于开源XXL-JOB优雅下线实践
开源XXL-JOB执行原理及优雅下线问题
目前开源XXL-Job在任务调度持续执行过程中,任务执行侧还无法有效地实现优雅下线功能。因此,想通过开源版本实现优雅下线需要自定义改造。在改造开源XXL-JOB优雅下线之前,可以先对XXL-JOB任务分发和任务执行的整体链路进行剖析。整个链路涉及XXL-JOB Admin和XXL-Job Executor两个模块。参考如下图示例:

针对XXL-Job主要的交互执行链路进行解读说明,并标注出对优雅下线的影响逻辑点,以便作为自定义改造的参考,目前主要存在以下问题:
问题一:下线节点摘流延迟
执行器在下线时未能及时完成调度和执行机器列表更新,会出现定时调度至下线节点导致调度失败。
逻辑处理一:执行器注册
- 业务应用在依赖XXL-JOB SDK启动后,会初始化- ExecutorRegistryThread线程持续向调度中心汇报心跳。
 
- 调度中心在接收到后,会通过- JobRegistryHelper,将注册上来的执行器信息写入数据库表- xxl_job_registry。
 
- JobRegistryHelper中存在一个线程,定期查询更新- xxl_job_group表的- address_list(实际使用的列表)。
 


逻辑处理二:选择在线执行机器
- 任务在通过调度线程触发后,会交给- XxlJobTrigger完成触发执行动作。
 
- 在触发执行前,会从- xxl_job_group表- address_list读取可用的执行器列表。
 
- 通过- ExecutorRouter在上述机器列表中,按对应的路由策略选择一台机器。
 
- 完成机器选择后,会通过RPC请求将任务分发至对应IP节点运行;此时如选择一个已下线节点任务触发会失败。 

总结说明:由于上述注册执行器逻辑和触发任务执行获取列表数据不实时同步,是通过异步定时更新,因此会产生可用在线机器列表刷新延迟。
问题二:任务执行强制中断
目前XXL-Job Executor在退出时会直接触发任务运行线程中断按失败处理,且队列中等待执行的任务执行请求会全部丢弃按失败处理。
逻辑处理一:将任务分发至对应机器执行
- 业务应用执行器接收到对应任务后,会根据任务ID为每个任务创建一个- JobThread线程用于任务执行。
 
- 该任务本次触发执行请求,会被添加到当前任务线程待执行队列中,任务不同阻塞策略会有不同处理。 
- JobThread该线程会持续循环读取,队列中的触发记录并执行对应的- JobHandler完成业务逻辑处理。
 
- 任务执行结束后,会将本次执行结果信息提交给- TriggerCallbackThread的执行应答队列,继续下一次执行。
 
- 执行器在停止时会执行- XxlJobExecutor.destroy方法,该方法会中断运行的线程及清理掉队列中等待执行的调度请求。
 
逻辑处理二:任务执行结果反馈
- TriggerCallbackThread会持续运行加载当前执行结果队列,批量分发执行结果给调度中心。
 
- 如向调度中心发送应答结果失败,则会写入本地文件落盘,会安排重试。 
- 调度中心在接收到执行结果后会进行执行记录的更新写入库。 

总结说明:在上述下线处理过程中,removeJobThread底层会直接中断运行中的任务线程,且线程队列中等待执行的任务会直接忽略执行按失败处理。
开源XXL-JOB实现优雅下线
通过开源XXL-JOB执行原理的过程分析,根据分析原理基于开源代码实现优雅下线功能。应用优雅下线的核心三步骤是先摘流,再等待执行中业务完成,最后停机下线。

XXL-JOB Core模块的com.xxl.job.core.executor.XxlJobExecutor#destroy,在SpringBoot模式下会在应用进程退出时自动进行回调处理,其中包含了应用执行器的一些下线回收动作,但目前此处的相关逻辑处理并不能完全实现优雅下线功能。因此,需结合上述的剖析进行以下步骤改造处理:
步骤一:应用节点摘流
- 首先- XxlJobExecutor#destroy方法中,存在- stopEmbedServer()方法会停止心跳注册并向调度中心发送- registryRemove请求,以移除当前执行节点。
 
- 调度服务端在接收请求后会将数据库- xxl_job_registry表中当前节点移除,但参考原理剖析说明实际使用的是- xxl_job_group表- address_list(并未被同步更新),此时并未真正完成摘流动作。
 
- 需对调度服务端进行相应改造来实现摘流,改造点选择(选其一): 
完成上述改造后,即可完成第一步摘流动作。
步骤二:等待执行中业务完成
- 改造- XxlJobExecutor#destroy方法中的下一步,需要等待所有待执行任务处理完成,参考如下代码:
 - public void destroy(){
    // destroy executor-server
    stopEmbedServer();
    // destroy jobThreadRepository
    if (jobThreadRepository.size() > 0) {
        List keyList = new ArrayList(jobThreadRepository.keySet());
        for (int i=0; i < keyList.size(); i++) {
            JobThread jobThread = jobThreadRepository.get(keyList.get(i));
            // 等待所有任务队列执行完成
            while (jobThread != null && jobThread.isRunningOrHasQueue()) {
                try {
                    TimeUnit.SECONDS.sleep(1L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
    jobHandlerRepository.clear();
    // destroy JobLogFileCleanThread
    JobLogFileCleanThread.getInstance().toStop();
    // destroy TriggerCallbackThread
    TriggerCallbackThread.getInstance().toStop();
}
 
至此,等待运行中任务处理即可完成。另外,您可自行发挥对不同任务类型做个性化的下线处理。
前提条件
- 引擎版本需2.1.0及以上。版本详情,请参见XXL-JOB引擎版本。 
- 客户端需接入SchedulerX plugin包。版本详情,请参见XXL-JOB插件版本。 - <dependency>
  <groupId>com.aliyun.schedulerx</groupId>
  <artifactId>schedulerx3-plugin-xxljob</artifactId>
  <version>最新版本</version>
</dependency>
 
优雅下线示意图

如何启用优雅下线
在不同的业务形态和部署场景中,完整配置并启用优雅下线方案。该过程主要包括两个步骤:
步骤一:执行器各框架初始化集成
业务应用不同的部署形态,需要按不同方式进行初始化集成。
形态一:SpringBoot业务应用(推荐)
如果业务应用采用了SpringBoot方式集成XXL-Job的执行器,那么可自动完成相应的优雅下线能力初始化集成。只需完成如下两个步骤即可:
- 添加SchedulerX插件Maven依赖。版本详情,请参见XXL-JOB插件版本。 - <dependency>
  <groupId>com.aliyun.schedulerx</groupId>
  <artifactId>schedulerx3-plugin-xxljob</artifactId>
  <version>最新版本</version>
</dependency>
 
- 添加应用配置参数,开启优雅下线。详细参数说明,请参见配置参数说明。 - # 配置优雅下线
xxl.job.executor.shutdownMode=WAIT_ALL
 
形态二:Spring业务应用
如果业务应用是通过Spring框架启动的Web应用,除了添加POM依赖和应用启动参数(参考形态一:SpringBoot业务应用(推荐)),还需通过初始化配置XxlJobExecutorEnhancerInitializer,在web.xml中添加如下配置:
<web-app>
  <context-param>
        <!-- Spring ApplicationContextInitializer 增强xxljob executor功能 -->
        <param-name>globalInitializerClasses</param-name>
        <param-value>com.aliyun.schedulerx.xxljob.enhance.XxlJobExecutorEnhancerInitializer</param-value>
    </context-param>
</web-app>
形态三:Frameless Java业务应用
如果业务应用采用xxl-job executor案例中的Frameless方式,通过纯Java编码方式启动业务应用时,可通过自定义编码完成优雅下线功能初始化集成。首先业务应用还是需要添加POM依赖和应用启动参数(参考形态一:SpringBoot业务应用(推荐)),相关参考案例如下:
示例代码
public static void main(String[] args) {
    try {
        // load executor prop
        Properties xxlJobProp = FrameLessXxlJobConfig.loadProperties("xxl-job-executor.properties");
        // 初始化增加xxl-job executor加载
        EnhancerLoader.load(xxlJobProp);
        // start xxl-job executor
        FrameLessXxlJobConfig.getInstance().initXxlJobExecutor(xxlJobProp);
        // 添加系统优雅线下hook
        Runtime.getRuntime().addShutdownHook(new Thread(){
            @Override
            public void run() {
                FrameLessXxlJobConfig.getInstance().destroyXxlJobExecutor();
            }
        });
        // Blocks until interrupted
        while (true) {
            try {
                TimeUnit.HOURS.sleep(1);
            } catch (InterruptedException e) {
                break;
            }
        }
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    } finally {
        // destroy
        FrameLessXxlJobConfig.getInstance().destroyXxlJobExecutor();
    }
}
步骤二:应用停机下线处理
自建部署,通过kill -15停机
在自建CD流程中通常会有一个应用进程停止的节点,该节点可通过构建一个stop.sh 脚本用于应用进程停止退出。脚本内容需包含应用优雅下线的相关逻辑处理,参考如下停机脚本。

应用进程停机脚本案例:
# 应用启用成功后进程ID信息会写入app.pid文件
PID="{应用部署路径}/app.pid"
FORCE=1
if [ -f ${PID} ]; then
  TARGET_PID=`cat ${PID}`
  kill -15 ${TARGET_PID}
  loop=1
  while(( $loop<=5 ))
  do
    ## health 检查当前应用进程确实已经结束,可根据应用特征自定义
    health
    if [ $? == 0 ]; then
      echo "check $loop times, current app has not stop yet."
      sleep 5s
      let "loop++"
    else
      FORCE=0
      break
    fi
  done
  if [ $FORCE -eq 1 ]; then
  	echo "App(pid:${TARGET_PID}) stop timeout, forced termination."
    kill -9 ${TARGET_PID}
  if
  rm -rf ${PID}
  echo "App(pid:${TARGET_PID}) stopped successful."
fi
K8s容器化部署,通过PreStop停机
利用k8s pod的生命周期管理可默认实现优雅下线。同时还可以使用preStop hook,通过exec执行脚本和HTTP请求方式来实现优雅下线逻辑处理。
重要 方案中Pod的terminationGracePeriodSeconds参数会控制优雅下线的整体最长等待时间(默认30s),需要按业务需要合理配置。
 apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app-image:latest
        lifecycle:
          preStop:
            exec:
              # command: ["/bin/sh", "-c", "kill -15 PID && sleep 30"]
              command: ["/bin/sh", "-c", "脚本路径/stop.sh"]
配置参数说明
在业务应用中需要配置如下参数开启优雅下线功能,并且支持通过该参数配置两种不同的优雅下线策略。

# 优雅下线模式,WAIT_ALL:等待全部; WAIT_RUNNING:等待运行中。
# 该参数不配置,则表示保持XXL-JOB原始逻辑不变(默认不开启优雅下线)。
xxl.job.executor.shutdownMode=WAIT_ALL
| 下线模式 | 描述 | 
| 等待全部(WAIT_ALL) | (推荐)该模式下,待所有已接收的任务(正在运行及队列中等待的任务)执行完成后,应用才退出。 | 
| 等待运行中(WAIT_RUNNING) | 该模式下,应用在退出时,将等待已分配线程并在处理中的执行记录完成,队列中的任务将被放弃执行。 |