CN114625533A - 分布式任务调度方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请涉及数据处理技术领域，尤其涉及一种分布式任务调度方法、装置、电子设备及存储介质，应用于分布式***，分布式***包括多个服务节点，该方法包括：接收客户端发送的交易请求，并获取每一服务节点可处理的任务量；将交易请求对应的待处理任务量与多个服务节点的可处理的任务量进行比对；根据比对结果确定对应的负载均衡策略，并基于负载均衡策略将交易请求对应的各个任务分配至对应的服务节点进行处理；其中，负载均衡策略包括并发度优先策略和消息容量优先策略。这样，可将并发度高、交易量大的批量交易进行有效拆分，提高部署策略的灵活性，从而提高处理效率。

Description

分布式任务调度方法、装置、电子设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种分布式任务调度方法、装置、电子设备及存储介质。

背景技术

随着企业网上银行不断优化，使得企业网银业务蓬勃发展，在业务量屡创新高的同时企业网银交易的流程也变得越发的复杂，越来越多的网银交易需要通过异步流程来完成，对日间批量和日终批量的需求也越来越旺盛，而且绝大部分批量属于分钟级调度的周期性批量，给开发和运维带来了不小的压力，从而使企业网银***对批量业务的调度和处理效率提出了更高的要求。

现有技术中，可以通过利用分布式任务调度***采用分时分片的方式对待处理任务进行调度，即基于时间维度对任务进行定时定量的调度，例如，当客户提交批量交易任务后，***会新增加一条定时任务，进一步的，***利用定时调度框架按时按周期发送请求以激活作业运行。

但是，上述方法在***同时收到大量任务并发执行的时，中央处理器(CentralProcessing Unit，简称CPU)占用率较高，使得运行效率低下，当任务数量多到***无法承载时，便无法满足当前的性能要求，部署策略的灵活性较低。

发明内容

本申请提供一种分布式任务调度方法、装置、电子设备及存储介质，可以将并发度高、交易量大的批量交易进行有效拆分，提高部署策略的灵活性，从而提高处理效率。

第一方面，本申请提供一种分布式任务调度方法，应用于分布式***，所述分布式***包括多个服务节点，所述方法包括：

接收客户端发送的交易请求，并获取每一服务节点可处理的任务量；

将所述交易请求对应的待处理任务量与所述多个服务节点的可处理的任务量进行比对；

根据比对结果确定对应的负载均衡策略，并基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理；

其中，所述负载均衡策略包括并发度优先策略和消息容量优先策略；所述并发度优先策略用于将待处理任务基于服务节点个数进行均分；所述消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。

可选的，根据比对结果确定对应的负载均衡策略，包括：

若每一个服务节点的可处理的任务量均大于预设阈值，则确定负载均衡策略为并发度优先策略；

若任意一个服务节点的可处理的任务量小于预设阈值，则确定负载均衡策略为消息容量优先策略。

可选的，基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理，包括：

若确定所述负载均衡策略为并发度优先策略，则将所述交易请求对应的待处理任务基于当前服务节点的总个数进行均分，并将均分后的待处理任务分配至对应的服务节点进行处理；

若确定所述负载均衡策略为消息容量优先策略，则以所述服务节点的可处理的任务量中的最小值为基准任务量，并基于所述基准任务量将所述交易请求对应的待处理任务进行划分，将划分好的待处理任务分配至对应的服务节点进行处理。

可选的，获取每一服务节点可处理的任务量，包括：

获取每一服务节点对应的部署位置，并根据所述部署位置确定将任务发送给所述服务节点的传输路径，根据所述传输路径确定所述服务节点可处理的任务量。

可选的，基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理，包括：

基于所述负载均衡策略获取每一服务节点对应的消息队列，所述消息队列包括携带有交易类型的待处理任务，所述交易类型用于指示待处理任务的处理时间和/或处理顺序；

将所述消息队列分配至对应的服务节点进行处理，以使所述服务节点根据所述交易类型确定所述待处理任务对应的线程池，所述线程池满足所述待处理任务的处理时间和/或处理顺序的要求；并根据所述待处理任务对应的所述线程池对所述待处理任务进行处理。

可选的，所述方法还包括：

当新增M个服务节点时，获取所述M个服务节点对应的可处理的任务量；

向所述多个服务节点发送回收指令，用于回收所述交易请求剩余的待处理任务；

基于所述交易请求对应的剩余的待处理任务量和所述M个服务节点对应的可处理的任务量重新确定负载均衡策略，并基于重新确定的负载均衡策略将所述剩余的待处理任务分配至对应的服务节点进行处理。

可选的，所述方法还包括：

每隔预设周期，检查每一服务节点处理交易请求对应的各个任务时生成的日志；

判断所述日志中的是否存在异常信息；

若存在，则将所述日志对应的服务节点进行移除，并回收该服务节点内待处理的任务，将所述待处理的任务分配给除存在异常信息外的服务节点进行处理。

第二方面，本申请还提供一种分布式任务调度装置，应用于分布式***，所述分布式***包括多个服务节点，所述装置包括：

获取模块，用于接收客户端发送的交易请求，并获取每一服务节点可处理的任务量；

比对模块，用于将所述交易请求对应的待处理任务量与所述多个服务节点的可处理的任务量进行比对；

处理模块，用于根据比对结果确定对应的负载均衡策略，并基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理；

其中，所述负载均衡策略包括并发度优先策略和消息容量优先策略；所述并发度优先策略用于将待处理任务基于服务节点个数进行均分；所述消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。

第三方面，本申请还提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面中任一项所述的方法。

第四方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面任一项所述的分布式任务调度方法。

综上所述，本申请提供一种分布式任务调度方法、装置、电子设备及存储介质，可以通过接收客户端发送的交易请求，进而获取每一服务节点可处理的任务量；进一步的，将交易请求对应的待处理任务量与多个服务节点的可处理的任务量进行比对；并根据比对结果确定对应的负载均衡策略，进一步的，基于负载均衡策略将交易请求对应的各个任务分配至对应的服务节点进行处理；其中，负载均衡策略包括并发度优先策略和消息容量优先策略；该并发度优先策略用于将待处理任务基于服务节点个数进行均分；该消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。这样，可将并发度高、交易量大的批量交易进行有效拆分，提高部署策略的灵活性，从而提高处理效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的一种分布式任务调度方法的流程示意图；

图3为本申请实施例提供的一种分布式任务调度***的架构示意图；

图4为本申请实施例提供的一种服务节点部署位置的架构示意图；

图5为本申请实施例提供的一种服务节点的结构示意图；

图6为本申请实施例提供的一种分布式任务调度***的部署架构图；

图7为本申请实施例提供的一种分布式任务调度装置的结构示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一设备和第二设备仅仅是为了区分不同的设备，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

为便于理解本申请实施例，下面对本申请实施例中涉及到的词汇作简单说明。

分布式***：指的是建立在网络之上的软件***，拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换，***中存在一个以全局的方式管理计算机资源的分布式操作***，具有高度的内聚性和透明性。

下面结合附图对本申请实施例进行介绍。图1为本申请实施例提供的一种应用场景示意图，本申请提供的分布式任务调度方法可以应用于如图1所示的应用场景中，该应用场景包括：终端设备101，分布式***102，第一节点服务器103，第二节点服务器104和第三节点服务器105。

具体的，终端设备101可以将交易请求发送给分布式***102，进一步的，分布式***102接收该交易请求，并获取该交易请求中对应的待处理任务量，相应的，分布式***102获取第一节点服务器103，第二节点服务器104和第三节点服务器105的可处理的任务量，进一步的，分布式***102进行基于该待处理任务量和各个节点服务器的可处理的任务量判断将交易请求对应的各个任务以哪种方式分配给哪些节点服务器进行处理，以便于提高处理效率，并实现负载均衡。

可以理解的是，节点服务器的数量为多个，以上节点服务器的个数仅是示例说明，本申请实施例对此不作具体限定。

其中，终端设备也可以被称为终端(Terminal)、用户设备(User Equipment，简称UE)、移动台(Mobile Station，简称MS)、移动终端(Mobile Terminal，简称MT)等。终端设备可以是手机(Mobile Phone)、智能电视、穿戴式设备、智能音箱、智能安防设备、智能网关、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(Virtual Reality，简称VR)终端设备、增强现实(Augmented Reality，简称AR)终端设备、工业控制(Industrial Control)中的无线终端、无人驾驶(Self-Driving)中的无线终端、远程手术(Remote Medical Surgery)中的无线终端、智能电网(Smart Grid)中的无线终端、运输安全(Transportation Safety)中的无线终端、智慧城市(Smart City)中的无线终端、智慧家庭(Smart Home)中的无线终端等等。

需要说明的是，本实施例中对终端设备的个数和类型不作具体限定，图1中所示的终端设备的个数仅作为举例说明。

现有技术中，可以通过利用分布式任务调度***采用分时分片的方式对待处理任务进行调度，即基于时间维度对任务进行定时定量的调度，例如，当客户提交批量交易任务后，***会新增加一条定时任务，进一步的，***利用定时调度框架按时按周期发送请求以激活作业运行。

但是，上述方法在***同时收到大量任务并发执行的时，CPU占用率较高，使得运行效率低下，当任务数量多到***无法承载时，便无法满足当前的性能要求，而且当需要新增任务作业的时候，需要增加新的作业逻辑，并重新进行整体编译打包和部署，部署灵活性不高，部署策略的灵活性较低。

因此，本申请实施提供一种分布式任务调度方法，应用于分布式***，该分布式***包括多个服务节点，可以在分布式***的各个服务节点间实现调度，在调配资源的同时还可以保证分布式***各个服务节点间的一致性，并可以根据自身服务节点的运行载荷和关联服务节点的承载能力自动感知负载均衡策略，进而选择合适的负载均衡策略将任务下发给各个服务节点进行处理。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的一种分布式任务调度方法的流程示意图；如图2所示，本实施例的方法，可以应用于分布式***，所述分布式***包括多个服务节点，所述方法可以包括：

S201、接收客户端发送的交易请求，并获取每一服务节点可处理的任务量。

在本步骤中，每一服务节点之间是相互独立的，分布式***管理的服务节点中无关键服务节点，且各个服务节点间并不进行直接通信，而是依靠数据库(集群)和分布式缓存来实现***资源的调配，从而实现多道作业并发、负载均衡、故障转移和***扩容等。

示例性的，在图1的应用场景下，分布式***102可以接收终端设备101发送的交易请求，进一步的，分布式***102还需要获取第一节点服务器103，第二节点服务器104和第三节点服务器105的可处理的任务量。

S202、将所述交易请求对应的待处理任务量与所述多个服务节点的可处理的任务量进行比对。

在本步骤中，通过将交易请求对应的待处理任务量与多个服务节点的可处理的任务量之和进行比对，以及找出多个服务节点的可处理的任务量的最小值，从而判断出每一个服务节点需要接收的任务量，使得分配合理，且负载均衡，提高处理效率。

示例性的，在图1的应用场景下，分布式***102将从终端设备101接收的交易请求对应的待处理任务量与第一节点服务器103，第二节点服务器104和第三节点服务器105的可处理的任务量之和进行比对，并找出第一节点服务器103，第二节点服务器104和第三节点服务器105对应的可处理的任务量的最小值，例如，待处理任务量为30，第一节点服务器103对应的可处理的任务量为20，第二节点服务器104对应的可处理的任务量为15，第三节点服务器105对应的可处理的任务量10，由于待处理任务量为30小于各个节点服务器可处理的任务量之和45，各个节点服务器的可处理的任务量的最小值为10，故可以判断出每一个节点服务器需要接收的任务量为10个。

S203、根据比对结果确定对应的负载均衡策略，并基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理。

其中，所述负载均衡策略包括并发度优先策略和消息容量优先策略；所述并发度优先策略用于将待处理任务基于服务节点个数进行均分；所述消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。

本申请实施例中，服务节点个数可以为***中能够接收均分后待处理任务量的服务节点个数，该服务节点个数也可以人为提前设定；基准任务量可以指的是***中每个服务节点可以接收并进行处理的任务量，该任务量也可以人为提前设定，本申请实施例对服务节点个数和基准任务量的具体数值不作限定。

优选的，本申请实施例设计了两种负载均衡策略，每种策略可根据自适应结果动态调整。其中，并发度优先策略指的是将接收的任务以固定的并发度进行拆分，例如3000个任务，设定的并发度(预设的服务节点个数)是3，那么每个消息就是包含1000个任务，即每个服务节点处理1000个任务，该消息的数量是固定的。消息容量优先策略指的是每个消息所包含的任务数量是固定的，例如每条消息(发送给服务节点的任务)只能包含30个任务，若总任务数量比上消息容量有余，则将余量任务放入单独的一条消息发送给服务节点进行处理。

示例性的，在图1的应用场景下，以待处理任务量为29，第一节点服务器103对应的可处理的任务量为20，第二节点服务器104对应的可处理的任务量为15，第三节点服务器105对应的可处理的任务量10为例，分布式***102将待处理任务量为29与各个节点服务器对应的可处理的任务量以及各个节点服务器对应的可处理的任务量之和进行比对，判断出待处理任务量为29小于各个节点服务器可处理的任务量之和45，各个节点服务器的可处理的任务量的最小值为10，故可以确定选取消息容量优先策略，向第一节点服务器103发送10个待处理任务，向第二节点服务器104发送10个待处理任务，向第三节点服务器105发送9个待处理任务，相应的，各个节点服务器接收各自对应的待处理任务进行处理。

因此，本申请实施例提供的方法，可以根据待处理任务量与多个服务节点的可处理的任务量动态调整负载均衡策略，还可以将并发度高、交易量大的批量交易进行有效拆分，提高处理效率以及灵活性。

示例性的，图3为本申请实施例提供的一种分布式任务调度***的架构示意图，如图3所示，该分布式任务调度***的应用架构自底向上共分四个层次，分别是：数据层、服务层、应用层、开发层。

其中，数据层指的是分布式任务调度***框架运行的数据基础，由两部分组成，分别是可扩展标记语言(Extensible Markup Language，简称XML)存储库和关系数据库(Relational Database，简称RDB)。XML存储库以XML元数据方式进行描述，包括有调度器行为定义、任务的定义、任务的调度策略等；保存在RDB中的数据有：任务的持久化数据、任务的调度信息、用于保障分布式***运行数据等。

服务层指的是分布式任务调度***框架运行的核心机制，包括调度容器(Scheduler)、本地存储(Repository)、作业存储(Job Store)、线程池(Thread Pool)、消息队列(Message Queue，简称MQ)、客户信息控制***(Customer Information ControlSystem，简称CICS)、远程过程调用(Remote Procedure Call，简称RPC)、插件(Plugin)、通讯基础组件等内容。

应用层指的是分布式任务调度***框架提供的服务模块，包括任务定义模块、调度请求模块、数据操作模块、消息发送模块、数据同步模块和数据缓存模块等内容。

开发层指的是使用分布式任务调度***框架开发应用的程序集打包，包括集成开发环境(Integrated Development Environment，简称IDE)、插件发布、应用发布等内容。

可以理解的是，分布式任务调度***框架最核心的功能是实现调度容器并在分布式***的各个服务节点间实现调度，在调配资源的同时还要保证分布式***各个服务节点间的一致性，同时还提供了应用程序开发接口和快速发布应用的解决方案。

可选的，根据比对结果确定对应的负载均衡策略，包括：

若每一个服务节点的可处理的任务量均大于预设阈值，则确定负载均衡策略为并发度优先策略；

若任意一个服务节点的可处理的任务量小于预设阈值，则确定负载均衡策略为消息容量优先策略。

本申请实施例中，预设阈值可以指的是***用于判断每一个服务节点是否具有处理大量任务的能力所设定的阈值，该预设阈值也可以人为修改，本申请实施例对预设阈值的具体数值不作限定，例如，该预设阈值为1000。

示例性的，在图1的应用场景下，以待处理任务量为3000，第一节点服务器103对应的可处理的任务量为1005，第二节点服务器104对应的可处理的任务量为2000，第三节点服务器105对应的可处理的任务量1020为例，分布式***102通过判断发现第一节点服务器103、第二节点服务器104以及第三节点服务器105的可处理的任务量均大于预设阈值1000，则可以确定选取的负载均衡策略为并发度优先策略。

可选的，以待处理任务量为70，第一节点服务器103对应的可处理的任务量为40，第二节点服务器104对应的可处理的任务量为1001，第三节点服务器105对应的可处理的任务量30为例，分布式***102通过判断发现第一节点服务器103和第三节点服务器105的可处理的任务量小于预设阈值1000，则可以确定选取的负载均衡策略为消息容量优先策略。

因此，本申请可以基于每个服务节点的可处理的任务量和预设阈值选择合适的负载均衡策略进行任务的下发，降低每一服务节点的CPU占用率，使得每一任务都可以得到合理的分配，而且任务负载均衡。

可选的，基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理，包括：

若确定所述负载均衡策略为并发度优先策略，则将所述交易请求对应的待处理任务基于当前服务节点的总个数进行均分，并将均分后的待处理任务分配至对应的服务节点进行处理；

若确定所述负载均衡策略为消息容量优先策略，则以所述服务节点的可处理的任务量中的最小值为基准任务量，并基于所述基准任务量将所述交易请求对应的待处理任务进行划分，将划分好的待处理任务分配至对应的服务节点进行处理。

示例性的，在图1的应用场景下，以待处理任务量为3000，第一节点服务器103对应的可处理的任务量为1005，第二节点服务器104对应的可处理的任务量为2000，第三节点服务器105对应的可处理的任务量1020为例，分布式***102确定选取的负载均衡策略为并发度优先策略，则将交易请求对应的3000个待处理任务基于当前服务节点的总个数3个进行均分，每个节点服务器应处理1000个任务，进一步的，分别将1000个的待处理任务分配至第一节点服务器103，第二节点服务器104和第三节点服务器105进行处理。

在另一实施例中，在图1的应用场景下，以待处理任务量为70，第一节点服务器103对应的可处理的任务量为40，第二节点服务器104对应的可处理的任务量为1001，第三节点服务器105对应的可处理的任务量30为例，分布式***102确定选取的负载均衡策略为消息容量优先策略，则以第三节点服务器105对应的可处理的任务量30为基准任务量，并基于基准任务量将待处理任务70进行划分，即可以为第一节点服务器103处理任务量为30，第二节点服务器104处理任务量为30，第三节点服务器105处理任务量为10，进一步的，将划分好的待处理任务分配至对应的节点服务器进行处理。

需要说明的是，上述划分待处理任务至对应的服务节点，每个服务节点没有先后顺序之分，上述划分也可以为第一节点服务器103处理任务量为30，第二节点服务器104处理任务量为10，第三节点服务器105处理任务量为30，即划分给每个服务节点的任务数量是固定的，若总任务数量/服务节点数量有余，则将余量任务单独分配给任意一个服务节点进行处理。以上服务节点数量仅是示例说明，实际中包含多个服务节点。

因此，本申请可以根据服务节点的运行载荷和承载能力选择合适的负载均衡策略，在利用并发度优先策略时，可以提高处理速率，即不需要将待处理任务分给过多的服务节点进行处理，节省分配时间。

可选的，获取每一服务节点可处理的任务量，包括：

获取每一服务节点对应的部署位置，并根据所述部署位置确定将任务发送给所述服务节点的传输路径，根据所述传输路径确定所述服务节点可处理的任务量。

在本步骤中，在部署服务节点至对应的应用时，各个服务节点之间的地位是平等的，不依靠中心服务节点进行***级的决策，包含具体业务逻辑的应用模块可以和服务节点处于一个程序空间内，也可以分布在网络上的其他地方。

可以理解的是，部署在本地服务节点内实现秒级调度，分布式***中所在其他部署位置的其他服务节点可以实现分钟级调度，进行任务处理。

示例性的，图4为本申请实施例提供的一种服务节点部署位置的架构示意图，如图4所示，分布式***中的各个服务节点的承载方式有多种，可以依托在可执行程序(Executable Program，简称EXE)内(即节点1)、或者本地服务内(即节点4)，也可以使用托管的Web应用(即节点3)或者全球广域网(World Wide Web，简称Web)站点(即节点2)来进行承载，其中，每个节点对应各自的服务器。各服务节点由于可使用的***资源不同其处理能力也不同，分布式***能够识别各个服务节点的处理能力并以此为依据向各服务节点分配任务，从而实现负载均衡。由于没有关键服务节点的存在，因此，任意一个服务节点的接入或者卸载，分布式***都可以平滑处理。

需要说明的是，整个分布式***由一系列节点构成，节点间可以通过消息的方式实现信息共享。

示例性的，可以通过获取每一服务节点对应的部署位置，进一步的，根据部署位置确定将任务发送给服务节点的传输路径，例如，节点4的部署位置在本地服务器上，因此，可以确定节点4的可处理的任务量多于其他服务节点。

因此，本申请实施例可以根据服务节点的部署位置确定服务节点的处理能力，即该服务节点的可处理的任务量，提高获取服务节点可处理的任务量的准确性，使得处理任务分配时更加合理。

可选的，基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理，包括：

基于所述负载均衡策略获取每一服务节点对应的消息队列，所述消息队列包括携带有交易类型的待处理任务，所述交易类型用于指示待处理任务的处理时间和/或处理顺序；

将所述消息队列分配至对应的服务节点进行处理，以使所述服务节点根据所述交易类型确定所述待处理任务对应的线程池，所述线程池满足所述待处理任务的处理时间和/或处理顺序的要求；并根据所述待处理任务对应的所述线程池对所述待处理任务进行处理。

本申请实施例中，交易类型可以包括下述至少一项：实时交易，非实时交易和时序交易，其中，实时交易为处理时间小于预设时间的交易；非实时交易为不限制处理时间的交易；时序业交易为按照接收的时间和/或接收的顺序依次处理的交易。

例如，交易1是实时交易，该预设时间可以根据实际需要来设置，例如10s，则要求处理完成该交易1的处理时间小于10s；其中，处理时间可以是指交易1从接收到反馈处理结果所花费的时间；交易2是非实时交易，因为该交易2对处理时间没有要求，则在一定时间内将该交易2处理完成即可；交易3和交易4是时序交易，则要求按照接收该交易3和交易4的时间和/或接收的顺序依次处理的上述的交易。

需要说明的是，接收该交易3和交易4的时间和/或接收的顺序，表示可以存在三种关系，例如，接收的时间和/或接收的顺序，可以表示：单独存在接收的时间，同时存在接收的时间和接收的顺序，单独存在接收的顺序这三种情况，当到达该交易的处理时间时，计时器会通知调度器进行调度任务，进行处理。

示例性的，图5为本申请实施例提供的一种服务节点的结构示意图；如图5所示，本申请实施例中的服务节点通过线程池作为枢纽实现对任务的处理和监控，下面对节点进行介绍：

任务(Task)用于对作业进行描述，包括任务的上下文以及一个可执行的调度程序和与之相关的参数等等。

调度容器(Scheduler)指的是实现调度功能的容器，线程池、计时器、任务等都装载在容器之中。其中，一个服务节点可以配置一个或者多个容器，一个容器内可以注册多个任务(Task)，但是一个容器只能拥有且必须拥有一个计时器(Timer)和一个线程池(ThreadPool)。

线程池(Thread Pool)指的是节点处理能力的标识，线程池的大小根据节点所在服务器的可用资源情况进行定义。

计时器(Timer)用于触发调度的线程计时设备，计时器根据时间基点来进行计时，当到达任务执行的时刻时会通知调度器进行调度。

消息队列(MQ)指的是服务节点可以使用的本地或者网络上消息队列接口，接口的实现依赖不同的消息队列，框架自带微软消息队列(MicroSoft Message Queuing，简称MSMQ)和消息中间件(Tonglink/Q)的接口实现，其中，Tonglink/Q体系结构包含三大部分：服务器节点、监控管理中心和开发接口。

远程过程调用(RPC)指的是服务节点可以使用的RPC接口资源标识，遵循.NetRemoting标准。

监视器(Monitor)用于监控其他服务节点的运行情况和向***声明当前服务节点的运行情况。

XML处理器(XML Processor)指的是对XML内容的操作集合。

插件管理器(Plugin Manager)指的是管理服务节点内的插件。

缓存(Cache)指的是分布式缓存，由一个服务端实现管理和控制，有多个客户端节点存储数据，可以进一步提高数据的读取速率。

任务存储支持(ADO Store)指的是对任务(Task)进行持久化的数据库支持。

具体的，在图1的应用场景下，分布式***102可以基于选取的负载均衡策略获取第一节点服务器103，第二节点服务器104和第三节点服务器105对应的消息队列，其中，每一个消息队列均包括携带有交易类型的待处理任务，例如以第一节点服务器103对应的消息队列为例，该消息队列包含有交易1-3为实时交易，交易4-9为非实时交易和交易10-20为时序交易；进一步的，分布式***102将该消息队列分配至第一节点服务器103进行处理，以使第一节点服务器103根据上述三个交易类型确定待处理任务对应的线程池，每一个线程池均满足待处理任务交易1-20的处理时间和/或处理顺序的要求；进一步，根据待处理任务对应的线程池对交易1-20进行处理。

因此，本申请实施例可以选择不同类型的交易对应的线程池进行交易的处理，可以保证不同交易类型的交易得到及时、高效的处理，提高处理交易的效率和灵活性，从而提高***性能。

可选的，所述方法还包括：

当新增M个服务节点时，获取所述M个服务节点对应的可处理的任务量；

向所述多个服务节点发送回收指令，用于回收所述交易请求剩余的待处理任务；

基于所述交易请求对应的剩余的待处理任务量和所述M个服务节点对应的可处理的任务量重新确定负载均衡策略，并基于重新确定的负载均衡策略将所述剩余的待处理任务分配至对应的服务节点进行处理。

其中，M为大于1的正整数，本申请实施例对M个的具体数值不作限定。

在本步骤中，当分布式***中有新服务节点接入时，可以快速识别并把任务分配给其执行，从而实现分布式***的横向扩展，在新服务节点接入后，需要将下发给原各个服务节中待处理的任务中剩余的任务量(即还未被处理的任务量)进行回收，重新进行分配至新服务节点或原各个服务节，或者，也可以直接将新接收的任务量分配给新服务节点进行处理，本申请实施例对此不作具体限定。

示例性的，在图1的应用场景下，若分布式***102识别到新增2个节点服务器时，则会获取该2个节点服务器对应的可处理的任务量；进一步的，向第一节点服务器103，第二节点服务器104和第三节点服务器105发送回收指令，用于回收第一节点服务器103，第二节点服务器104和第三节点服务器105未处理完的任务；进一步的，基于未处理完的任务量、该2个服务节点对应的可处理的任务量以及第一节点服务器103，第二节点服务器104和第三节点服务器105目前可处理的任务量重新确定负载均衡策略，并基于重新确定的负载均衡策略将未处理完的任务分配至对应的服务节点进行处理。

因此，本申请实施例可以在识别到新服务节点接入时，重新进行负载策略的选取或者将新任务发送至新服务节点进行处理，提高处理的灵活性以及处理任务的实时性。

可选的，所述方法还包括：

每隔预设周期，检查每一服务节点处理交易请求对应的各个任务时生成的日志；

判断所述日志中的是否存在异常信息；

若存在，则将所述日志对应的服务节点进行移除，并回收该服务节点内待处理的任务，将所述待处理的任务分配给除存在异常信息外的服务节点进行处理。

本申请实施例中，预设周期可以指的是***用于监控任务处理有无发生异常设定的时间周期，例如，该预设周期可以为一周，也可以为一天，本申请实施例对此不作具体限定；异常信息可以指的是故障服务节点发生故障，不能处理任务或处理任务异常生成的日志信息，本申请实施例对异常信息的具体内容不作限定。

示例性的，在图1的应用场景下，每隔一周，分布式***102检查第一节点服务器103，第二节点服务器104和第三节点服务器105处理交易请求对应的各个任务时生成的日志；进一步的，判断日志中的是否存在异常信息；例如，第三节点服务器105对应的日志存在异常信息，则将第三节点服务器105进行移除，并回收该第三节点服务器105内待处理的任务，进一步的，将该待处理的任务分配给第一节点服务器103和第二节点服务器104进行处理。

因此，本申请实施例可以对***进行监控，当***内有服务节点出现故障时，可以快速识别，然后回收该服务节点内的任务并将该服务节点从***中移除，从而实现故障转移，提高***性能。

需要说明的是，本申请实施例还可以人为干预任务的执行和暂停，以及查看每一服务节点生成的***日志、任务日志和异常日志，提高处理任务的灵活性。

结合上述实施例，图6为本申请实施例提供的一种分布式任务调度***的部署架构图；如图6所示，可以将任务通过负载均衡策略发送给分布式任务调度***框架，一个框架中可以包含多个分布式任务调度***，该分布式任务调度***框架根据自身处理机制进行批量任务处理，即可以发送给不同分布式任务调度***进行业务处理，具体的，各个客户端中的应用将交易请求发送给本地的分布式任务调度***(F5)，进一步的，该分布式任务调度***还可以关联其他分布式任务调度***进行任务的处理，其中，每一个***中都部署有通信基础框架(Windows Communication Foundation，简称WCF)进行业务处理，进一步的，框架可根据自身框架的运行载荷和关联***的承载能力选择对应的负载均衡策略，然后基于负载均衡策略将交易请求对应的任务发送到每一个分布式任务调度***的消息队列(即TLQ)中，远程调用或本地调用对应的业务逻辑进行业务的处理，例如，调用转账业务逻辑进行批量转账，然后将处理结果反馈至后台服务。

在前述实施例中，对本申请实施例提供的分布式任务调度方法进行了介绍，而为了实现上述本申请实施例提供的方法中的各功能，作为执行主体的电子设备可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。

例如，图7为本申请实施例提供的一种分布式任务调度装置的结构示意图，如图7所示，该装置包括：获取模块710，比对模块720和处理模块730；其中，获取模块710，用于接收客户端发送的交易请求，并获取每一服务节点可处理的任务量；

比对模块720，用于将所述交易请求对应的待处理任务量与所述多个服务节点的可处理的任务量进行比对；

处理模块730，用于根据比对结果确定对应的负载均衡策略，并基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理；

其中，所述负载均衡策略包括并发度优先策略和消息容量优先策略；所述并发度优先策略用于将待处理任务基于服务节点个数进行均分；所述消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。

可选的，处理模块730包括确定单元和处理单元；所述确定单元，用于：

若每一个服务节点的可处理的任务量均大于预设阈值，则确定负载均衡策略为并发度优先策略；

若任意一个服务节点的可处理的任务量小于预设阈值，则确定负载均衡策略为消息容量优先策略。

可选的，所述处理单元，用于：

若确定所述负载均衡策略为并发度优先策略，则将所述交易请求对应的待处理任务基于当前服务节点的总个数进行均分，并将均分后的待处理任务分配至对应的服务节点进行处理；

若确定所述负载均衡策略为消息容量优先策略，则以所述服务节点的可处理的任务量中的最小值为基准任务量，并基于所述基准任务量将所述交易请求对应的待处理任务进行划分，将划分好的待处理任务分配至对应的服务节点进行处理。

可选的，所述获取模块710，具体用于：

获取每一服务节点对应的部署位置，并根据所述部署位置确定将任务发送给所述服务节点的传输路径，根据所述传输路径确定所述服务节点可处理的任务量。

可选的，所述处理模块730，具体用于：

基于所述负载均衡策略获取每一服务节点对应的消息队列，所述消息队列包括携带有交易类型的待处理任务，所述交易类型用于指示待处理任务的处理时间和/或处理顺序；

将所述消息队列分配至对应的服务节点进行处理，以使所述服务节点根据所述交易类型确定所述待处理任务对应的线程池，所述线程池满足所述待处理任务的处理时间和/或处理顺序的要求；并根据所述待处理任务对应的所述线程池对所述待处理任务进行处理。

可选的，所述装置还包括更新模块，所述更新模块，用于：

当新增M个服务节点时，获取所述M个服务节点对应的可处理的任务量；

向所述多个服务节点发送回收指令，用于回收所述交易请求剩余的待处理任务；

基于所述交易请求对应的剩余的待处理任务量和所述M个服务节点对应的可处理的任务量重新确定负载均衡策略，并基于重新确定的负载均衡策略将所述剩余的待处理任务分配至对应的服务节点进行处理。

可选的，所述装置还包括监控模块，所述监控模块，用于：

每隔预设周期，检查每一服务节点处理交易请求对应的各个任务时生成的日志；

判断所述日志中的是否存在异常信息；

若存在，则将所述日志对应的服务节点进行移除，并回收该服务节点内待处理的任务，将所述待处理的任务分配给除存在异常信息外的服务节点进行处理。

本申请实施例提供的分布式任务调度装置的具体实现原理和效果可以参见上述实施例对应的相关描述和效果，此处不做过多赘述。

本申请实施例还提供了一种电子设备的结构示意图，图8为本申请实施例提供的一种电子设备的结构示意图，如图8所示，该电子设备可以包括：处理器802以及与所述处理器通信连接的存储器801；该存储器801存储计算机程序；该处理器802执行该存储器801存储的计算机程序，使得该处理器802执行上述任一实施例所述的方法。

其中，存储器801和处理器802可以通过总线803连接。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序执行指令，计算机执行指令被处理器执行时用于实现如本申请前述任一实施例中的所述的方法。

本申请实施例还提供了一种运行指令的芯片，该芯片用于执行如本申请前述任一实施例中由电子设备所执行的前述任一实施例中所述的方法。

本申请实施例还提供了一种计算机程序产品，该程序产品包括计算机程序，该计算机程序被处理器执行时可实现如本申请前述任一实施例中由电子设备所执行的前述任一实施例中所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(Central Processing Unit，简称CPU)，还可以是其它通用处理器、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速随机存取存储器(Random Access memory，简称RAM)，也可能还包括非不稳定的存储器(Non-volatile Memory，简称NVM)，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，简称ISA)总线、外部设备互连(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static Random-Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-OnlyMemory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种分布式任务调度方法，其特征在于，应用于分布式***，所述分布式***包括多个服务节点，所述方法包括：

接收客户端发送的交易请求，并获取每一服务节点可处理的任务量；

将所述交易请求对应的待处理任务量与所述多个服务节点的可处理的任务量进行比对；

根据比对结果确定对应的负载均衡策略，并基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理；

其中，所述负载均衡策略包括并发度优先策略和消息容量优先策略；所述并发度优先策略用于将待处理任务基于服务节点个数进行均分；所述消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。

2.根据权利要求1所述的方法，其特征在于，根据比对结果确定对应的负载均衡策略，包括：

若每一个服务节点的可处理的任务量均大于预设阈值，则确定负载均衡策略为并发度优先策略；

若任意一个服务节点的可处理的任务量小于预设阈值，则确定负载均衡策略为消息容量优先策略。

3.根据权利要求2所述的方法，其特征在于，基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理，包括：

若确定所述负载均衡策略为并发度优先策略，则将所述交易请求对应的待处理任务基于当前服务节点的总个数进行均分，并将均分后的待处理任务分配至对应的服务节点进行处理；

若确定所述负载均衡策略为消息容量优先策略，则以所述服务节点的可处理的任务量中的最小值为基准任务量，并基于所述基准任务量将所述交易请求对应的待处理任务进行划分，将划分好的待处理任务分配至对应的服务节点进行处理。

4.根据权利要求1所述的方法，其特征在于，获取每一服务节点可处理的任务量，包括：

获取每一服务节点对应的部署位置，并根据所述部署位置确定将任务发送给所述服务节点的传输路径，根据所述传输路径确定所述服务节点可处理的任务量。

5.根据权利要求1所述的方法，其特征在于，基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理，包括：

基于所述负载均衡策略获取每一服务节点对应的消息队列，所述消息队列包括携带有交易类型的待处理任务，所述交易类型用于指示待处理任务的处理时间和/或处理顺序；

将所述消息队列分配至对应的服务节点进行处理，以使所述服务节点根据所述交易类型确定所述待处理任务对应的线程池，所述线程池满足所述待处理任务的处理时间和/或处理顺序的要求；并根据所述待处理任务对应的所述线程池对所述待处理任务进行处理。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当新增M个服务节点时，获取所述M个服务节点对应的可处理的任务量；

向所述多个服务节点发送回收指令，用于回收所述交易请求剩余的待处理任务；

基于所述交易请求对应的剩余的待处理任务量和所述M个服务节点对应的可处理的任务量重新确定负载均衡策略，并基于重新确定的负载均衡策略将所述剩余的待处理任务分配至对应的服务节点进行处理。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

每隔预设周期，检查每一服务节点处理交易请求对应的各个任务时生成的日志；

判断所述日志中的是否存在异常信息；

若存在，则将所述日志对应的服务节点进行移除，并回收该服务节点内待处理的任务，将所述待处理的任务分配给除存在异常信息外的服务节点进行处理。

8.一种分布式任务调度装置，其特征在于，应用于分布式***，所述分布式***包括多个服务节点，所述装置包括：

获取模块，用于接收客户端发送的交易请求，并获取每一服务节点可处理的任务量；

比对模块，用于将所述交易请求对应的待处理任务量与所述多个服务节点的可处理的任务量进行比对；

处理模块，用于根据比对结果确定对应的负载均衡策略，并基于所述负载均衡策略将所述交易请求对应的各个任务分配至对应的服务节点进行处理；

其中，所述负载均衡策略包括并发度优先策略和消息容量优先策略；所述并发度优先策略用于将待处理任务基于服务节点个数进行均分；所述消息容量优先策略用于将待处理任务量基于基准任务量进行划分并分配给服务节点。

9.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-7任一项所述的分布式任务调度方法。

Images