一种基于分布式任务调度框架的任务容灾方法技术

本发明专利技术公开一种基于分布式任务调度框架的任务容灾方法，包括以下步骤：第一步，初始化任务调度中心，并在初始化过程中启动一个守护线程，用于监测执行器的心跳状态；第二步，用户通过任务调度中心注册任务信息；第三步，调度中心根据任务的Cron配置按时提交调度请求；第四步，执行器接收并运行调度中心提交的调度请求；第五步，若守护线程监测到执行器在执行任务的过程中发生故障，则确认该执行器上是否有处于运行态的任务，如果存在，则更新该任务的运行状态；触发任务被重新调度到在线的执行器上运行；第六步，任务执行完成，返回调度结果。本发明专利技术解决了现有的分布式任务调度框架无法处理容灾场景的任务自动恢复问题。

A disaster recovery method based on distributed task scheduling framework

【技术实现步骤摘要】
一种基于分布式任务调度框架的任务容灾方法
本专利技术属于大数据
，具体是一种基于分布式任务调度框架的任务容灾方法。
技术介绍
在企业级大数据平台系统中，普遍存在着大量业务相关的需要被周期性调度运行的各种任务。这些任务的特点是按照一定的时间规律周期性的进行自动调度、自动运行、自动结束。例如周期更新采样数据、每天凌晨定点执行建表任务、每月定期生成数据库报表等。对于上述业务场景，目前业界存在一系列的开源分布式任务调度框架，比如LTS、XXL-JOB、Elastic-Job，这些分布式任务调度框架具有良好的伸缩性、扩展性，提供了用户友好的运维管理界面，支持动态的对任务进行CRUD操作等，是企业级大数据平台任务调度的很好选择。其中，XXL-JOB是一个轻量级、易扩展的分布式任务调度框架，该框架操作简单、使用方便，是目前比较流行的开源分布式任务调度框架。XXL-JOB在任务容灾方面已实现的特性有：可以根据执行器的在线情况动态的调整任务调度，避免把任务调度到发生故障的执行器上面运行；当正在运行调度任务的执行器发生故障时，任务管理界面提供了“终止任务”的操作按钮，通过手工点击“终止任务”按钮可以触发任务被重新调度执行。XXL-JOB虽然在一定程度上提供了任务容灾的方法，但是需要结合运维人员的手工操作才能实现。目前虽然存在一些不错的分布式任务调度框架，但是，在实际生产环境使用中普遍存在以下问题：当一个分布式任务执行器节点因故掉线或者发生重启之后，调度中心调度到该执行器节点上面并且处于运行态的任务会出现挂死问题，无法自动恢复执行。现有的分布式任务调度框架还无法很好地处理容灾场景下的任务自动恢复问题，而任务运行的可靠性恰恰又是电网、银行、保险等行业领域选型分布式任务调度系统的一个重要考量指标。针对上述问题，目前尚未提出有效的解决方案。
技术实现思路
本专利技术的目的是针对现有技术存在的问题，提供一种基于分布式任务调度框架的任务容灾方法，以解决容灾场景下正在运行任务出现挂死，无法自动恢复的问题。为实现上述目的，本专利技术采用的技术方案是：一种基于分布式任务调度框架的任务容灾方法，包括以下步骤：S1，部署多个执行器，多个所述执行器分别与调度中心通信连接；S2，通过调度中心注册任务信息，并基于任务的Cron配置向执行器提交调度请求；S3，执行器接收并运行调度中心提交的调度请求；S4，通过调度中心监测多个所述执行器的心跳状态；S5，监测到执行器在执行任务的过程中发生故障，确认该执行器上是否存在处于运行态的任务，如果存在，则更新该任务的运行状态；触发任务被重新调度到在线的执行器上运行；如果不存在，则刷新该执行器的在线状态；S6，执行器完成调度请求任务，返回调度结果。具体地，步骤S4中，所述执行器的心跳状态通过守护线程监测，所述守护线程在任务调度中心初始化过程中启动；所述守护线程监测执行器的心跳状态的方法为：守护线程每隔1个心跳周期查询一次数据库的执行器信息注册表，根据注册表的update_time字段判断是否有掉线的执行器；所述执行器信息注册表中update_time字段若存在超过3个心跳周期没有更新的执行器，则认为该执行器处于掉线状态。具体地，步骤S5中，所述执行器发生的故障包括掉线故障和因故重启故障；进一步地，当所述执行器发生掉线故障时，守护线程会查询数据库的调度日志信息表，确认该执行器上是否存在处于运行态的任务，若存在，则更新该任务的运行状态为失败；然后调度中心根据任务配置的重试次数进行重试调度，触发任务被重新调度到在线的执行器上运行；若不存在，则刷新执行器信息注册表。进一步地，当所述执行器发生因故重启故障时，调用调度中心的rescheduling服务接口，通过rescheduling服务接口判断执行器重启时间是否超过3个心跳周期，若超过，则将该执行器发生的故障归为掉线故障处理；若重启时间未超过3个心跳周期，则通过rescheduling服务接口查询数据库调度日志，确认该执行器上是否存在运行态的任务，若存在，则更新该任务的运行状态为失败；然后调度中心根据任务配置的重试次数进行重试调度，触发任务被重新调度到在线的执行器上运行；若不存在，则刷新执行器信息注册表。进一步地，根据任务配置的重试次数进行重试调度具体为：调度中心后台运行的守护线程周期性的轮询任务监控队列中每个任务的调度日志信息表，如果存在失败状态并且重试次数大于0的监控任务，则把该任务对应的重试次数减一后重新提交到任务调度中心被调度运行。具体地，所述心跳周期为30s。具体地，所述调度中心与执行器之间通过DB方式进行信息注册发现(即服务注册发现)。与上述任务容灾方法相对应的，本专利技术还提供了一种基于分布式任务调度框架的任务容灾系统，包括调度中心和多个执行器，多个所述执行器与调度中心通过DB方式进行信息注册发现；所述调度中心用于注册任务信息，并基于任务的Cron配置向执行器提交调度请求；所述执行器用于接收并运行调度请求；所述调度中心通过监测执行器的心跳状态判断执行器是否发生故障；当监测到执行器在执行任务的过程中发生故障，确认该执行器上是否存在处于运行态的任务，如果存在，则更新该任务的运行状态；触发任务被重新调度到在线的执行器上运行；如果不存在，则刷新该执行器的在线状态。具体地，所述调度中心通过守护线程监测执行器的心跳状态，所述守护线程在调度中心初始化过程中启动；所述守护线程监测执行器的心跳状态的方法为：守护线程每隔1个心跳周期查询一次数据库的执行器信息注册表，根据注册表的update_time字段判断是否有掉线的执行器；所述执行器信息注册表中update_time字段若存在超过3个心跳周期没有更新的执行器，则认为该执行器处于掉线状态。具体地，所述执行器发生的故障包括掉线故障和因故重启故障；当所述执行器发生掉线故障时，守护线程会查询数据库的调度日志信息表，确认该执行器上是否存在处于运行态的任务，若存在，则更新该任务的运行状态为失败；然后调度中心根据任务配置的重试次数进行重试调度，触发任务被重新调度到在线的执行器上运行；若不存在，则刷新执行器信息注册表；当所述执行器发生因故重启故障时，调用调度中心的rescheduling服务接口，通过rescheduling服务接口判断执行器重启时间是否超过3个心跳周期，若超过，则将该执行器发生的故障归为掉线故障处理；若重启时间未超过3个心跳周期，则通过rescheduling服务接口查询数据库调度日志，确认该执行器上是否存在运行态的任务，若存在，则更新该任务的运行状态为失败；然后调度中心根据任务配置的重试次数进行重试调度，触发任务被重新调度到在线的执行器上运行；若不存在，则刷新执行器信息注册表。具体地，所述心跳周期为30s。具体地，多个所述执行器与调度中心通过DB方式进行信息注册发现。与现有技术相比，本专利技术的有益效果是：本专利技术可以对分布式任务调度系统中各种类型的故障做到及时的反应和本文档来自技高网...

【技术保护点】
1.一种基于分布式任务调度框架的任务容灾方法，其特征在于，包括以下步骤：/nS1，部署多个执行器，多个所述执行器分别与调度中心通信连接；/nS2，注册任务信息，并基于任务的Cron配置向执行器提交调度请求；/nS3，执行器接收并运行调度中心提交的调度请求；/nS4，监测多个所述执行器的心跳状态；/nS5，监测到执行器在执行任务的过程中发生故障，确认该执行器上是否存在处于运行态的任务，如果存在，则更新该任务的运行状态；触发任务被重新调度到在线的执行器上运行；如果不存在，则刷新该执行器的在线状态；/nS6，执行器完成调度请求任务，返回调度结果。/n

【技术特征摘要】
1.一种基于分布式任务调度框架的任务容灾方法，其特征在于，包括以下步骤：
S1，部署多个执行器，多个所述执行器分别与调度中心通信连接；
S2，注册任务信息，并基于任务的Cron配置向执行器提交调度请求；
S3，执行器接收并运行调度中心提交的调度请求；
S4，监测多个所述执行器的心跳状态；
S5，监测到执行器在执行任务的过程中发生故障，确认该执行器上是否存在处于运行态的任务，如果存在，则更新该任务的运行状态；触发任务被重新调度到在线的执行器上运行；如果不存在，则刷新该执行器的在线状态；
S6，执行器完成调度请求任务，返回调度结果。


2.根据权利要求1所述的一种基于分布式任务调度框架的任务容灾方法，其特征在于，步骤S4中，所述执行器的心跳状态通过守护线程监测，所述守护线程在调度中心初始化过程中启动；所述守护线程监测执行器的心跳状态的方法为：守护线程每隔1个心跳周期查询一次数据库的执行器信息注册表，根据注册表的update_time字段判断是否有掉线的执行器；所述执行器信息注册表中update_time字段若存在超过3个心跳周期没有更新的执行器，则认为该执行器处于掉线状态。


3.根据权利要求1所述的一种基于分布式任务调度框架的任务容灾方法，其特征在于，步骤S5中，所述执行器发生的故障包括掉线故障和因故重启故障；
当所述执行器发生掉线故障时，守护线程会查询数据库的调度日志信息表，确认该执行器上是否存在处于运行态的任务，若存在，则更新该任务的运行状态为失败；然后调度中心根据任务配置的重试次数进行重试调度，触发任务被重新调度到在线的执行器上运行；若不存在，则刷新执行器信息注册表；
当所述执行器发生因故重启故障时，调用调度中心的rescheduling服务接口，通过rescheduling服务接口判断执行器重启时间是否超过3个心跳周期，若超过，则将该执行器发生的故障归为掉线故障处理；若重启时间未超过3个心跳周期，则通过rescheduling服务接口查询数据库调度日志，确认该执行器上是否存在运行态的任务，若存在，则更新该任务的运行状态为失败；然后调度中心根据任务配置的重试次数进行重试调度，触发任务被重新调度到在线的执行器上运行；若不存在，则刷新执行器信息注册表。


4.根据权利要求2或3所述的一种基于分布式任务调度框架的任务容灾方法，其特征在于，所述心跳周期为30s。


5.根据权利要求1所述的一种基于分布式任务调度框架的任务容灾方法，其特征在于，所述调度中心与执行器之间通过DB方式...

【专利技术属性】
技术研发人员：陈佳佳，赵京虎，孙云枫，季学纯，马德超，李昊，赵宇，闫妮，
申请(专利权)人：国电南瑞科技股份有限公司，国电南瑞南京控制系统有限公司，
类型：发明
国别省市：江苏;32