CN113806052A

CN113806052A - 一种去中心化的分布式定时任务处理方法

Info

Publication number: CN113806052A
Application number: CN202111121549.2A
Authority: CN
Inventors: 赵伟
Original assignee: Sichuan XW Bank Co Ltd
Current assignee: Sichuan XW Bank Co Ltd
Priority date: 2021-09-24
Filing date: 2021-09-24
Publication date: 2021-12-17
Anticipated expiration: 2041-09-24
Also published as: CN113806052B

Abstract

本发明公开了一种去中心化的分布式定时任务处理方法，属于数据处理技术领域，具体涉及。解决了1)硬件成本与维护成本高；2)轻量级任务与重量级任务没有隔离，会导致任务堵塞；3)任务调度强依赖于第三方组件；4)抢占式的路由策略存在问题，大概率会集中到一台任务机执行任务的问题，本发明的技术方案包括步骤1：配置任务动态信息以及基础参数；步骤2：任务机启动后，自动对任务进行注册；步骤3：注册完毕后，任务机将任务放入相应的任务池中执行，并将执行结果存入数据库中，能满足绝大部分系统的定时任务业务场景。

Description

一种去中心化的分布式定时任务处理方法

技术领域

本发明属于数据处理技术领域，具体涉及一种去中心化的分布式定时任务处理方法。

背景技术

在绝大部分的业务系统中，我们通常都会定时的对一些原始数据进行去噪、加工、汇总等操作，用来做报表或者为复杂的业务提供有效的数据支持。随着业务的发展和数据的不断沉淀，我们所需要的定时任务会越来越多，单个定时任务处理数据的量也会越来越大，相应的处理时间也会越来越长。所以后期为了不影响业务系统的平滑使用，往往会把定时任务单独从业务系统中剥离出去，做成单独任务服务，达到解耦的效果。

现有采用的技术方案为开源的分布式调度任务框架xxl-job、tbschedule等；如流程图3所示:当前方案主要分为俩部分，调度中心和执行器，调度中心主要负责任务的协调、调度、下发，执行器主要负责具体执行的任务，具体步骤如下:

1、配置调度中心节点、任务执行时刻表；

2、配置任务执行节点，编写任务执行代码；

3、任务执行时刻，调度中心根据策略对任务机发起RPC调用；

4、任务机根据调用执行相应的任务逻辑；

5、执行结果插入数据库。

该方案存在如下缺点：

1)要保证集群高可用，调度中心至少需要部署主备俩个节点，对于中小业务系统而言硬件成本与维护成本高；

2)轻量级任务与重量级任务没有隔离，会导致任务堵塞；

3)任务调度强依赖于第三方组件(如zookeeper)；

4)抢占式的路由策略存在问题，大概率会集中到一台任务机执行任务。

发明内容

为了解决上述现有技术存在的缺陷，本发明的目的在于提供一种去中心化的分布式定时任务处理方法。

本发明采用的技术方案如下：

1.一种去中心化的分布式定时任务处理方法，其中包括以下步骤：

步骤1：配置任务动态信息以及基础参数；

步骤2：任务机启动后，自动对任务进行注册；

步骤3：注册完毕后，任务机将任务放入相应的任务池中执行，并将执行结果存入数据库中；

进一步的，所述步骤1具体包括：

步骤1.1：定义任务的基础数据信息，包括任务的名称、权重、任务执行日志记录等基础信息；

步骤2.1：配置任务的动态参数信息，包括任务执行的具体时刻、任务的任务池、任务执行的策略；

通过上述步骤1.2的动态参数的设计，极大的提高了系统的灵活程度，能够让一个任务在指定的某台任务机上执行，也能把一个任务进行分片，在多个任务机上同时执行，用户可以根据每个任务的特点把任务进行自定义的拆解执行。

优选的，所述任务执行的策略包括：单机执行、多机分片执行以及自定义规则。

进一步的，所述步骤2具体包括：

步骤2.1：任务机启动后会同时读取配置文件的任务详情数据和数据库中任务配置表的数据；

步骤2.2：通过对配置文件的数据与配置表中的数据进行比较,如果配置文件中的任务没有存在于任务配置表中，则在配置表中插入这部分任务数据；如果配置文件中的任务存在于任务配置表中，优先使用任务配置表中的数据；如果任务配置表中的任务多于配置文件中的任务，仍然优先使用任务配置表中的数据；

步骤2.3：任务详细数据存入数据库后，会把所有的任务向任务管理器进行注册，注册后任务的执行、中断、停止等状态都由任务管理器进行管理；

步骤2.4：每个任务机会额外注册一个心跳任务，用来上报当前任务机的心跳数据，依据最近30秒当前任务机是否有心跳数据来判断任务机是否处于健康状态；

通过上述步骤2.2中使用数据库作为控制中心，不必引入其他第三方组件，让系统的架构更简单，使任务机承担了调度的职责，可以用更少的机器做到任务的分布式执行与控制，系统架构更加简单、稳定，降低了维护成本。

进一步的，所述步骤3具体包括：

步骤3.1：任务触发时，任务机会先获取任务的基础配置、任务池配置，策略配置数据；

步骤3.2：解析策略数据，若当前任务无策略则根据任务类型把任务放入相应的任务池中，若有策略则根据策略配置决定是否把任务放入相应的任务池里；

步骤3.3：执行任务池的任务，执行结果存入数据库中；

通过上述步骤3.2中将重量级的任务采用队列排队执行的模式，使轻量级任务与重量级任务在不同执行资源中运行，避免了资源的争抢与任务堵塞，有效的避免了重任务间资源争抢的情况，使系统的健壮性更强。

进一步的，在所述步骤3.2中，如果任务策略中没有配置当前执行的任务机，检查当前任务机是否需要托管故障任务机任务，并判断是否启用故障转移机制。

其中，所述判断方法为：获取任务中配置的任务机host与ip，查询这些任务机是否存在最近30s的心跳数据，如果存在则逻辑退出，不存在则判断当前任务机是否是有心跳任务的任务机中权重最高的机器，不是则逻辑退出，若是则执行当前任务，放入相应的任务池中，并执行结果存入数据库中。

通过引入故障转移机制的引入极大的提高了系统的容错能力。

综上所述，由于采用了上述技术方案，本发明的有益效果是：

1.通过动态参数的设计，极大的提高了系统的灵活程度，能够让一个任务在指定的某台任务机上执行，也能把一个任务进行分片，在多个任务机上同时执行，用户可以根据每个任务的特点把任务进行自定义的拆解执行。

2.通过使用数据库作为控制中心，不必引入其他第三方组件，让系统的架构更简单，使任务机承担了调度的职责，可以用更少的机器做到任务的分布式执行与控制，系统架构更加简单、稳定，降低了维护成本。

3.通过将重量级的任务采用队列排队执行的模式，使轻量级任务与重量级任务在不同执行资源中运行，避免了资源的争抢与任务堵塞，有效的避免了重任务间资源争抢的情况，使系统的健壮性更强。

4.通过引入故障转移机制的引入极大的提高了系统的容错能力。

5.本方案为一个轻量级、高可用的去中心化分布式定时任务的生产方案，能满足绝大部分系统的定时任务业务场景。本方案高可用的集群规模最小化机器仅需2台节点即可，且仅依赖应用本身的数据库。在实现了对任务动态管理的同时，还实现了任务的指派、分片、隔离、手动执行、故障转移等复杂管理，并且支持在不修改任何代码的情况下对任务机节点的进行水平扩展，非常适合任务数据量不是特别巨大的业务场景中使用。

附图说明

本发明将通过例子并参照附图的方式说明，其中：

图1是本发明中分布式定时任务处理方法的流程图；

图2是本发明中故障转移机制的流程图；

图3是现有技术方案的执行流程图。

名词解释

Java:是一门面向对象的编程语言；

XXL-JOB/TBSCHEDULE:是开源的分布式调度任务框架；

Zookeeper:是一个开源的分布式应用程序协调服务；

Quartz:是一个开源的定时任务调度框架；

RPC:远程过程调用，常用于不同系统间接口的调用；

队列:一种先进先出的数据结构；

线程池:若干个可执行的线程放入一个池(容器)中，有任务需要处理时，会提交到线程池中的任务队列，处理完之后线程并不会被销毁，而是仍然在线程池中等待下一个任务；

任务分片:把一个大任务按照某个维度拆成多个小任务交给不同的任务机同时执行。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例的描述中，需要说明的是，术语“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

下面结合图1～图3对本发明作详细说明。

一种去中心化的分布式定时任务处理方法，如图1所示，其中包括以下步骤：

步骤1：配置任务动态信息以及基础参数；

进一步的，所述步骤1具体包括：

步骤1.1：定义任务的基础数据信息，包括任务的名称、权重(发生异常时权重高的任务机获得托管任务的权力)、任务执行日志记录等基础信息；

步骤2.1：配置任务的动态参数信息，包括任务执行的具体时刻(如每周一早晨七点、每天晚上九点)、任务的任务池(独占队列、共享池)、任务执行的策略(单机执行、多机分片执行、自定义规则等)；

步骤2：任务机启动后会根据配置文件里的任务详情和当前机器的hostname、ip自动对任务进行注册；

进一步的，所述步骤2具体包括：

进一步的，所述步骤3具体包括：

步骤3.2：解析策略数据，若策略数据中的任务机IP集合包含当前任务机IP，则根据任务类型(独占、共享)把任务放入相应的任务池(独占队列、共享池)中；

步骤3.3：任务执行完成后，若在基础配置中配置了日志记录选项，执行结果存入数据库中，具体为把任务的执行情况和结果插入任务日志表中；

如图2所示，在所述步骤3.2中，任务的执行过程中解析策略数据时，若策略数据中的任务机IP集合没有包含当前任务机IP，获取任务中配置的任务机host与ip，检查当前任务机是否需要托管故障任务机任务，并判断是否启用故障转移机制。

其中，所述判断方法为：查询当前任务绑定的任务机最近30秒是否存在心跳数据,如果存在说明执行当前任务的所有任务机处于健康状态，则逻辑退出，不需要启动故障转移机制；若有任务机超过30秒没有上报过心跳数据，则表明需要启动故障转移机制。

进一步的，所述故障转移机制为：当任务机超过30秒没有上报过心跳数据后，判断当前任务机是否是最近30秒上报过心跳数据的任务机中权重最高的机器，若不是则不接管任务，逻辑退出；若是则执行当前任务，放入相应的任务池中，根据策略和环境配置数据执行任务，执行情况和结果插入任务日志表中。

本发明为一个轻量级、高可用的去中心化分布式定时任务的生产方案，能满足绝大部分系统的定时任务业务场景；本方案最高可用的集群规模最小化机器仅需2台节点即可，且仅依赖应用本身的数据库。在实现了对任务动态管理的同时，还实现了任务的指派、分片、隔离、手动执行、故障转移等复杂管理，并且支持在不修改任何代码的情况下对任务机节点的进行水平扩展，非常适合任务数据量不是特别巨大的业务场景中使用。通过引入故障转移机制的引入极大的提高了系统的容错能力。

以上所述实施例仅表达了本申请的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请技术方案构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。

Claims

1.一种去中心化的分布式定时任务处理方法，其特征在于，包括以下步骤：

步骤1：配置任务动态信息以及基础参数；

步骤2：任务机启动后，自动对任务进行注册；

步骤3：注册完毕后，任务机将任务放入相应的任务池中执行，并将执行结果存入数据库中。

2.根据权利要求1所述的一种去中心化的分布式定时任务处理方法，其特征在于，所述步骤1具体包括：

步骤2.1：配置任务的动态参数信息，包括任务执行的具体时刻、任务的任务池、任务执行的策略。

3.根据权利要求2所述的一种去中心化的分布式定时任务处理方法，其特征在于，所述任务执行的策略包括：单机执行、多机分片执行以及自定义规则。

4.根据权利要求3所述的一种去中心化的分布式定时任务处理方法，其特征在于，所述步骤2具体包括：

步骤2.4：每个任务机会额外注册一个心跳任务，用来上报当前任务机的心跳数据，依据最近30秒当前任务机是否有心跳数据来判断任务机是否处于健康状态。

5.根据权利要求4所述的一种去中心化的分布式定时任务处理方法，其特征在于，所述步骤3具体包括：

步骤3.3：执行任务池的任务，执行结果存入数据库中。

6.根据权利要求5所述的一种去中心化的分布式定时任务处理方法，其特征在于，在所述步骤3.2中，如果任务策略中没有配置当前执行的任务机，检查当前任务机是否需要托管故障任务机任务，并判断是否启用故障转移机制。

7.根据权利要求6所述的一种去中心化的分布式定时任务处理方法，其特征在于，所述判断方法为：获取任务中配置的任务机host与ip，查询这些任务机是否存在最近30s的心跳数据，如果存在则逻辑退出，不存在则判断当前任务机是否是有心跳任务的任务机中权重最高的机器，不是则逻辑退出，若是则执行当前任务，放入相应的任务池中，并执行结果存入数据库中。