定时任务优雅下线概述
在实际业务中,应用进程内的定时任务会持续按固定频率执行。当应用发布重启时,运行中的定时任务将被强制中断,可能导致数据不完整和调度成功率骤降,最终出现业务数据受损。主要存在以下情况:
因此,在使用定时任务调度的场景下,需要定时任务优雅下线,以实现滚动发布和重启过程中的业务平滑运行。
基于开源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 ) | 该模式下,应用在退出时,将等待已分配线程并在处理中的执行记录完成,队列中的任务将被放弃执行。 |