CN111209110B - 一种实现负载均衡的任务调度管理方法、系统和存储介质 - Google Patents

Abstract

本发明公开了一种实现负载均衡的任务调度管理方法，包括：获取业务请求并搜索逻辑进程配置文件；如果存在所述逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量；如果不存在所述逻辑进程配置文件，则预先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量；将所述业务请求分配至所挂载的各逻辑进程。通过设置调度进程具有自动和手动两种模式来判断加载的逻辑进程的数量，达到各处理业务的逻辑进程的负载均衡，有效加强了网络数据处理能力、提高网络的灵活性和可用性。

Description

一种实现负载均衡的任务调度管理方法、系统和存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种实现负载均衡的任务调度管理方法、系统和存储介质。

背景技术

Node.js是一个基于Chrome V8引擎的JavaScript运行环境，其本身并不支持多线程，但为了充分利用server的Multi-core，就必须使用多进程的方式，那么进程之间如何负载均衡就会是一个关键所在。例如现在的电子批记录软件，具有一个后台处理模块，用以处理软件业务中产生的一个个工作流实例，后台模块需要接受前台的业务指令，根据业务需求来生成，管理，操作，或关闭一条条工作流，但当前台业务需求量较大时，单实例后台模块的计算性能就将满足不了要求，导致软件不稳定和性能不足的问题。

发明内容

本发明针对现有技术中的不足，提供了一种实现负载均衡的任务调度管理方法，包括：获取业务请求并搜索逻辑进程配置文件；如果存在所述逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量；如果不存在所述逻辑进程配置文件，则预先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量；将所述业务请求分配至所挂载的各逻辑进程。

优选的，所述步骤根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量，具体包括：获取预先挂载的逻辑进程的CPU使用率和磁盘占用率，当所述CPU使用率和磁盘占用率超过预设阈值时，持续补充挂载逻辑进程至所有逻辑进程的CPU使用率和磁盘占用率低于预设阈值。

优选的，所述步骤将所述业务请求分配至所挂载的各逻辑进程，具体包括：将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的逻辑进程。

优选的，所述最小分配策略被配置为在分配前检测挂载的各逻辑进程的负载状态并分析其繁忙度，将所述业务请求发送至繁忙度最小的逻辑进程处理。

优选的，所述随机分配策略被配置为将收到的业务请求根据预设的分发顺序依次分配至下挂的子进程中。

优选的，所述步骤将所述业务请求分配至所挂载的各逻辑进程，具体包括：当监听到一错误逻辑进程离线事件后，新挂载一逻辑进程来加载所述错误进程未完成信息。

本发明还公开了一种任务调度管理方法，包括：调度进程获取业务请求并搜索逻辑进程配置文件，其中所述调度进程为Node.js进程；调度进程如发现该逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量；调度进程如未发现该逻辑进程配置文件，则先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量；所述调度进程根据确定需加载的逻辑进程数量进行相应加载，并将所述业务请求分配至所挂载的各逻辑进程。

本发明还公开了一种实现负载均衡的任务调度管理系统，包括：多个逻辑模块，用于对调度模块分配的业务请求进行执行；调度模块，接受前台发送的业务请求并搜索逻辑模块配置文件，如果存在所述逻辑模块配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑模块数量；如果不存在所述逻辑进程配置文件，则先挂载一逻辑模块，根据该逻辑模块的运行状态和/或负载情况来确定后续补充挂载的逻辑模块数量。

本发明还公开了一种实现负载均衡的任务调度管理装置，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述所述实现负载均衡的任务调度管理方法的步骤。

本发明还公开了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述所述实现负载均衡的任务调度管理方法的步骤。

本发明通过设置调度进程具有自动和手动两种模式来判断加载的逻辑进程的数量，特别是在自动模式通过预先挂载一逻辑进程，再根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量，当逻辑进程的运行状态和/或负载情况超过预设条件时就增加所挂载的逻辑进程来用以分摊压力，来达到各处理业务的逻辑进程的负载均衡，有效加强了网络数据处理能力、提高网络的灵活性和可用性。同时也能防止在业务需求量逐渐增加，但后台模块因搭载物理设备的一些不可预知的状况导致无法正常工作时导致软件运行中断的问题。解决了目前前台业务需求量较大时单实例后台模块的计算性能满足不了要求的状况。该方法有效解决了在软件项目中，单实例后台处理模块造成的软件不稳定和性能问题，提供一种通用且代价较小的解决方案，让后台模块能自由的根据需求进行扩展并在各扩展模块中保持负载均衡。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明一实施例公开的实现负载均衡的任务调度管理方法的流程示意图。

图2为本发明另一实施例公开的实现负载均衡的任务调度管理方法的流程示意图。

图3为本发明另一实施例公开的实现负载均衡的任务调度管理方法的流程示意图。

图4为本发明一实施例公开的实现负载均衡的任务调度管理系统的结构示意图。

图5为本发明一实施例公开的实现负载均衡的任务调度管理装置的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

在本发明中，除非另有明确的规定和限定，第一特征在第二特征之“上”或之“下”可以包括第一和第二特征直接接触，也可以包括第一和第二特征不是直接接触而是通过它们之间的另外的特征接触。而且，第一特征在第二特征“之上”、“上方”和“上面”包括第一特征在第二特征正上方和斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”包括第一特征在第二特征正下方和斜下方，或仅仅表示第一特征水平高度小于第二特征。

除非另作定义，此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明专利申请说明书以及权利要求书中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”或者“一”等类似词语也不表示数量限制，而是表示存在至少一个。

实施例1

附图1为本实施例公开的实现负载均衡的任务调度管理方法的步骤示意图，该方法可用以解决在软件项目中，单实例后台处理模块造成的软件不稳定和性能问题，通过提供一种通用的并代价较小的解决方案，让后台模块能自由的根据需求进行扩展。该方法可被广泛应用于各类软件中，例如电子批记录软件。该电子批软件用以解决医药生产环境中各个流程的管控规范与记录，将医药生产用电子计算机的手段加以管理，减少人为因素产生的误差，失误导致生产过程中发生的事故。该软件具有一个后台处理模块，用以处理软件业务中产生的一个个工作流实例，后台模块需要接受前台的业务指令，根据业务需求来生成，管理，操作，或关闭一条条工作流。但在前台业务需求量较大时，单实例后台模块的计算性能可能满足不了要求，所以该本实施例提供的实现负载均衡的任务调度管理方法就是用以解决此种状况，并可以避免生产环境中一些不可预知的异常造成的损失。例如当生产环境中，若其中一台设备因一些故障导致不可使用时，该任务调度管理方法可以保证其他设备可以替代故障设备的功能，保证整个生产环境的连贯工作，不会造成生产环境的中断。该方法具体可包括如下步骤：

步骤S101，获取业务请求并搜索逻辑进程配置文件。

该方法可由node.js开发实现的调度进程来具体实现，当然也可应用于其它软件环境开发的调度进程或调度软件中。其中逻辑进程为接收调度进程进行分配的具体业务请求来进行业务处理的业务模块。以下具体以实施该方法的调度进程来进行具体举例说明。

步骤S102，如果存在所述逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量。

用户可以提前准备好配置文件，其中该配置文件中设置有调度进程在运行时所需挂载的各逻辑进程的数量等配置信息。在调度进程启动时，加载该配置文件，根据配置文件中的配置内容，来确定该调度进程需要加载几个逻辑进程。

步骤S103，如果不存在所述逻辑进程配置文件，则预先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量。

其中该步骤可具体包括：获取预先挂载的逻辑进程的CPU使用率和磁盘占用率，当所述CPU使用率和磁盘占用率超过预设阈值时，持续补充挂载逻辑进程至所有逻辑进程的CPU使用率和磁盘占用率低于预设阈值。

具体的，如果调度进程启动时没有读取到配置文件，则会首先挂载一个逻辑进程，通过调用GetProcessTimes()方法获取CPU使用时间，CPU使用时间＝(lpKernelTime+lpUserTime)/GetProcessNumber()(内核数)，在根据CPU使用时间获取CPU利用率，CPU利用率＝(现在的CPU占用时间-过去的CPU占用时间)/系统时间差。调用GetProcessIoCounters()方法获取进程的磁盘占用率。根据获取到的CPU使用率和磁盘占用率，当两个参数中的一个或两个都超过预设阈值界限时，则增加挂载另一个逻辑进程，用以分摊压力。如果增加后的两个逻辑进程中仍然出现一个或两个进程的CPU使用率或磁盘占用率超过预设阈值，则继续新增逻辑进程用以分摊压力，直至增加逻辑进程的CPU使用率或磁盘占用率均符合预设要求即进程CPU使用率或磁盘占用率低于预设阈值界限为止。

步骤S104，将所述业务请求分配至所挂载的各逻辑进程。

当调度进程进入运行状态时，则开始接受前端下发的指令。用户发起业务需求后，首先被调度进程截获，调度者会根据某种具体的分配策略将该业务请求分配到其下挂载的进程中去，业务请求内的信息同时也会被分到实时数据库中，在分配成功后，调度者会收到处理者返回的消息。

具体的，该步骤还可包括：将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的逻辑进程。

其中，随机分配策略被配置为将收到的业务请求根据预设的分发顺序依次分配至下挂的子进程中。具体的，随机分配可以设置为，调度进程将收到的命令请求根据一个随机的调度策略分发给下挂的逻辑进程中去，分发的策略是在N个工作的逻辑进程中，每次以求余的方式，选择第i＝(i+1)mod n个进程来发送请求。

其中，最小分配策略被配置为在分配前检测挂载的各逻辑进程的负载状态并分析其繁忙度，将所述业务请求发送至繁忙度最小的逻辑进程处理。具体的，最小分配可以设置为：调度进程在分发命令前检测各下挂的逻辑进程的负载状态，可以根据CPU和I/O两个维度来分析下挂逻辑进程的繁忙度。例如在WINDOWS操作系统下，可以通过系统提供的API接口查到进程占用的CPU和I/O信息，随后将命令发送到繁忙度最小的逻辑进程中去处理。

在一些具体实施例中，步骤S104还可具体包括：当监听到一错误逻辑进程离线事件后，新挂载一逻辑进程来加载所述错误进程未完成信息。

具体的，挂载的逻辑进程接受到调度进程分发的命令时，会创建一个业务实例，处理的逻辑进程内部同时会开辟多个线程，将创建的实例放入线程中执行，从而提高CPU的利用率。每个实例的生命周期可以分别设置为以下几个状态：创建状态、准备状态、执行状态、结束状态、终止状态、暂停状态。当实例的状态发生改变，或实例处于执行状态时并执行到某些预设的关键节点时，逻辑进程会自动备份该实例的快照信息到运行的实时数据库中。在逻辑进程发生异常退出时，就可将该进程下的实例恢复到其他重启或新挂载的逻辑进程中去继续执行。

处理的逻辑进程运行时，会将自己的工作状态实时汇报给调度进程，以便让调度进程实时掌控各个处理的逻辑进程运行时的负载状态，并可将状态信息通过前端界面进行展示，在处理进程超负载时可以给出适当提示。其中调度进程和逻辑进程约定了以下几种状态事件：

错误状态事件：当处理进程无法被复制创建，无法被终止，无法发送消息时，会触发该事件。

退出事件：当处理进程退出时触发。当进程是正常退出时，则返回正常结束码。当进程异常退出后，会返回该进程退出时的错误信息。

关闭事件：当处理进程完全退出时通知调度进程，当前进程已经完全离线。

放弃事件：在极端情况下，当处理进程在启动过程中就发生了错误，并无限重启达到一定次数时，则会触发该事件，代表系统发生了不可恢复的故障，导致系统已经无法正常的运行下去，触发该事件后系统会在该事件中添加重要日志，并发出报警。该事件是系统产生的最严重的的事件。

一旦处理的逻辑进程出现异常时，就会根据状态触发上述几种事件，并立即停止接受新的连接，并释放当前持有的资源，当所有连接断开，资源释放完毕后便退出进程，此时调度进程在监听到子进程的关闭事件后，会立即重启一个新的进程服务，加载之前错误进程未完成的信息，继续之前未完成的服务，以此确保整个系统中总是有进程在为用户服务。

本实施例通过设置调度进程具有自动和手动两种模式来判断加载的逻辑进程的数量，特别是在自动模式通过预先挂载一逻辑进程，再根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量，当逻辑进程的运行状态和/或负载情况超过预设条件时就增加所挂载的逻辑进程来用以分摊压力，来达到各处理业务的逻辑进程的负载均衡，有效加强了网络数据处理能力、提高网络的灵活性和可用性。同时也能防止在业务需求量逐渐增加，但后台模块因搭载物理设备的一些不可预知的状况导致无法正常工作时导致软件运行中断的问题。解决了目前前台业务需求量较大时单实例后台模块的计算性能满足不了要求的状况。该方法有效解决了在软件项目中，单实例后台处理模块造成的软件不稳定和性能问题，提供一种通用且代价较小的解决方案，让后台模块能自由的根据需求进行扩展并在各扩展模块中保持负载均衡。

实施例2

附图2为另一实施例公开的任务调度管理方法的流程示意图，该方法中调度进程由node.js开发实现，业务进程由C++开发实现。利用node的原生模块具有跨平台特性的特点，将之与C++模块结合，达到提升性能和快速调度的目的。具体的，可首先将业务进程的逻辑用C++代码实现，然后用编译器编译为动态链接库文件，node调度进程在运行时首先调用uv_dlopen()方法打开动态链接库，再调用uv_dlsym()方法找到动态链接库中通过NODE_MODULE宏定义的方法地址，将它映射为node_module_struct结构，接下来将传入的exports对象作为实参运行，将C++中定义的方法挂载在exports对象上。实现NODE模块对C++模块的调用。该方法具体包括：

步骤S201，调度进程获取业务请求并搜索逻辑进程配置文件，其中所述调度进程为Node.js进程。

该方法可由node.js开发实现的调度进程来具体实现，当然也可应用于其它软件环境开发的调度进程或调度软件中。其中逻辑进程为接收调度进程进行分配的具体业务请求来进行业务处理的业务模块。以下具体以实施该方法的调度进程来进行具体举例说明。

步骤S202，调度进程如发现该逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量。用户可以提前准备好配置文件，其中该配置文件中设置有调度进程在运行时所需挂载的各逻辑进程的数量等配置信息。在调度进程启动时，加载该配置文件，根据配置文件中的配置内容，来确定该调度进程需要加载几个逻辑进程。

步骤S203，调度进程如未发现该逻辑进程配置文件，则先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量。

其中该步骤可具体包括：获取预先挂载的逻辑进程的CPU使用率和磁盘占用率，当所述CPU使用率和磁盘占用率超过预设阈值时，持续补充挂载逻辑进程至所有逻辑进程的CPU使用率和磁盘占用率低于预设阈值。具体的，如果调度进程启动时没有读取到配置文件，则会首先挂载一个逻辑进程，通过调用GetProcessTimes()方法获取CPU使用时间，CPU使用时间＝(lpKernelTime+lpUserTime)/GetProcessNumber()(内核数)，在根据CPU使用时间获取CPU利用率，CPU利用率＝(现在的CPU占用时间-过去的CPU占用时间)/系统时间差。调用GetProcessIoCounters()方法获取进程的磁盘占用率。根据获取到的CPU使用率和磁盘占用率，当两个参数中的一个或两个都超过预设阈值界限时，则增加挂载另一个逻辑进程，用以分摊压力。如果增加后的两个逻辑进程中仍然出现一个或两个进程的CPU使用率或磁盘占用率超过预设阈值，则继续新增逻辑进程用以分摊压力，直至增加逻辑进程的CPU使用率或磁盘占用率均符合预设要求即进程CPU使用率或磁盘占用率低于预设阈值界限为止。

步骤S204，所述调度进程根据确定需加载的逻辑进程数量进行相应加载，并将所述业务请求分配至所挂载的各逻辑进程。

当调度进程进入运行状态时，则开始接受前端下发的指令。用户发起业务需求后，首先被调度进程截获，调度者会根据某种具体的分配策略将该业务请求分配到其下挂载的进程中去，业务请求内的信息同时也会被分到实时数据库中，在分配成功后，调度者会收到处理者返回的消息。具体的，该步骤还可包括：将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的逻辑进程。其中，随机分配策略被配置为将收到的业务请求根据预设的分发顺序依次分配至下挂的子进程中。具体的，随机分配可以设置为，调度进程将收到的命令请求根据一个随机的调度策略分发给下挂的逻辑进程中去，分发的策略是在N个工作的逻辑进程中，每次以求余的方式，选择第i＝(i+1)mod n个进程来发送请求。其中，最小分配策略被配置为在分配前检测挂载的各逻辑进程的负载状态并分析其繁忙度，将所述业务请求发送至繁忙度最小的逻辑进程处理。具体的，最小分配可以设置为：调度进程在分发命令前检测各下挂的逻辑进程的负载状态，可以根据CPU和I/O两个维度来分析下挂逻辑进程的繁忙度。例如在WINDOWS操作系统下，可以通过系统提供的API接口查到进程占用的CPU和I/O信息，随后将命令发送到繁忙度最小的逻辑进程中去处理。

当监听到一错误逻辑进程离线事件后，新挂载一逻辑进程来加载所述错误进程未完成信息。具体的，挂载的逻辑进程接受到调度进程分发的命令时，会创建一个业务实例，处理的逻辑进程内部同时会开辟多个线程，将创建的实例放入线程中执行，从而提高CPU的利用率。每个实例的生命周期可以分别设置为以下几个状态：创建状态、准备状态、执行状态、结束状态、终止状态、暂停状态。当实例的状态发生改变，或实例处于执行状态时并执行到某些预设的关键节点时，逻辑进程会自动备份该实例的快照信息到运行的实时数据库中。在逻辑进程发生异常退出时，就可将该进程下的实例恢复到其他重启或新挂载的逻辑进程中去继续执行。

处理的逻辑进程运行时，会将自己的工作状态实时汇报给调度进程，以便让调度进程实时掌控各个处理的逻辑进程运行时的负载状态，并可将状态信息通过前端界面进行展示，在处理进程超负载时可以给出适当提示。

其中调度进程和逻辑进程约定了以下几种状态事件：

错误状态事件：当处理进程无法被复制创建，无法被终止，无法发送消息时，会触发该事件。

退出事件：当处理进程退出时触发。当进程是正常退出时，则返回正常结束码。当进程异常退出后，会返回该进程退出时的错误信息。

关闭事件：当处理进程完全退出时通知调度进程，当前进程已经完全离线。

放弃事件：在极端情况下，当处理进程在启动过程中就发生了错误，并无限重启达到一定次数时，则会触发该事件，代表系统发生了不可恢复的故障，导致系统已经无法正常的运行下去，触发该事件后系统会在该事件中添加重要日志，并发出报警。该事件是系统产生的最严重的的事件。

一旦处理的逻辑进程出现异常时，就会根据状态触发上述几种事件，并立即停止接受新的连接，并释放当前持有的资源，当所有连接断开，资源释放完毕后便退出进程，此时调度进程在监听到子进程的关闭事件后，会立即重启一个新的进程服务，加载之前错误进程未完成的信息，继续之前未完成的服务，以此确保整个系统中总是有进程在为用户服务。

在本实施例中，调度进程也被设置有对应的守护服务用于监视其运行状态，当调度进程遇到异常终止时，此时守护服务会立刻重启调度进程，以确保整个系统的连贯运行。

本实施例通过以NODE.JS加C++技术为框架，构建的一套负载均衡的方案，其通过设置调度进程具有自动和手动两种模式来判断加载的逻辑进程的数量，特别是在自动模式通过预先挂载一逻辑进程，再根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量，当逻辑进程的运行状态和/或负载情况超过预设条件时就增加所挂载的逻辑进程来用以分摊压力，来达到各处理业务的逻辑进程的负载均衡，有效加强了网络数据处理能力、提高网络的灵活性和可用性。同时也能防止在业务需求量逐渐增加，但后台模块因搭载物理设备的一些不可预知的状况导致无法正常工作时导致软件运行中断的问题。解决了目前前台业务需求量较大时单实例后台模块的计算性能满足不了要求的状况。该方法有效解决了在软件项目中，单实例后台处理模块造成的软件不稳定和性能问题，提供一种通用且代价较小的解决方案，让后台模块能自由的根据需求进行扩展并在各扩展模块中保持负载均衡。

另外本实施例公开的任务调度管理方法具有灵活增加和裁剪挂载模块的能力和异常挂载模块业务恢复的能力。传统的负载均衡方案均是针对物理服务器所做的一个硬件上的性能提升，而本实施例则很好的解决了软件运行时单处理模块的性能提升和容错。该方法可以有效的隔绝后台处理模块和前端请求的直接交互，所有的请求收发均是经过调度进程，集中调度进程的控制权，从而最大限度的提升集群的整体性能。

实施例3

附图3为实施例公开的另一种任务调度方法，其具体可包括如下步骤：

步骤S301，调度进程获取前端业务请求，根据对所挂载的多个逻辑进程的预设分配策略将所述业务请求选择分配至所挂载的第一逻辑进程中，其中所述调度进程为Node.js进程。其中将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的第一逻辑进程。具体的，调度进程由node.js开发实现，业务进程由C++开发实现。利用node的原生模块具有跨平台特性的特点，将之与C++模块结合，达到提升性能和快速调度的目的。具体的，可首先将业务进程的逻辑用C++代码实现，然后用编译器编译为动态链接库文件，node调度进程在运行时首先调用uv_dlopen()方法打开动态链接库，再调用uv_dlsym()方法找到动态链接库中通过NODE_MODULE宏定义的方法地址，将它映射为node_module_struct结构，接下来将传入的exports对象作为实参运行，将C++中定义的方法挂载在exports对象上。实现NODE模块对C++模块的调用。其中，随机分配策略被配置为将收到的业务请求根据预设的分发顺序依次分配至下挂的子进程中。最小分配策略被配置为在分配前检测挂载的各逻辑进程的负载状态并分析其繁忙度，将所述业务请求发送至繁忙度最小的逻辑进程处理。

步骤S302，所述第一逻辑进程根据接收的业务请求创建一业务实例，并将所述业务实例输入为其创建的多个线程中执行。具体的，挂载的逻辑进程接受到调度进程分发的命令时，会创建一个业务实例，处理的逻辑进程内部同时会开辟多个线程，将创建的实例放入线程中执行，从而提高CPU的利用率。每个实例的生命周期可以分别设置为以下几个状态：创建状态、准备状态、执行状态、结束状态、终止状态、暂停状态。当实例的状态发生改变，或实例处于执行状态时并执行到某些预设的关键节点时，逻辑进程会自动备份该实例的快照信息到运行的实时数据库中。在逻辑进程发生异常退出时，就可将该进程下的实例恢复到其他重启或新挂载的逻辑进程中去继续执行。

步骤S303，当所述调度进程监听到第一逻辑进程执行出现异常离线时，重启第二逻辑进程以加载第一逻辑进程未完成信息。处理的逻辑进程运行时，会将自己的工作状态实时汇报给调度进程，以便让调度进程实时掌控各个处理的逻辑进程运行时的负载状态，并可将状态信息通过前端界面进行展示，在处理进程超负载时可以给出适当提示。

其中调度进程和逻辑进程约定了以下几种状态事件：错误状态事件：当处理进程无法被复制创建，无法被终止，无法发送消息时，会触发该事件。退出事件：当处理进程退出时触发。当进程是正常退出时，则返回正常结束码。当进程异常退出后，会返回该进程退出时的错误信息。关闭事件：当处理进程完全退出时通知调度进程，当前进程已经完全离线。放弃事件：在极端情况下，当处理进程在启动过程中就发生了错误，并无限重启达到一定次数时，则会触发该事件，代表系统发生了不可恢复的故障，导致系统已经无法正常的运行下去，触发该事件后系统会在该事件中添加重要日志，并发出报警。该事件是系统产生的最严重的的事件。

一旦处理的逻辑进程出现异常时，就会根据状态触发上述几种事件，并立即停止接受新的连接，并释放当前持有的资源，当所有连接断开，资源释放完毕后便退出进程，此时调度进程在监听到子进程的关闭事件后，会立即重启一个新的进程服务，加载之前错误进程未完成的信息，继续之前未完成的服务，以此确保整个系统中总是有进程在为用户服务。

本实施例公开的任务调度管理方法具有灵活增加和裁剪挂载模块的能力和异常挂载模块业务恢复的能力。传统的负载均衡方案均是针对物理服务器所做的一个硬件上的性能提升，而本实施例则很好的解决了软件运行时单处理模块的性能提升和容错。该方法可以有效的隔绝后台处理模块和前端请求的直接交互，所有的请求收发均是经过调度进程，集中调度进程的控制权，从而最大限度的提升集群的整体性能。

实施例4

附图4为实施例公开的一种实现负载均衡的任务调度管理系统，包括多个逻辑模块2和调度模块1，其中多个逻辑模块2可用于对调度模块分配的业务请求进行执行；调度模块1可用于接受前台发送的业务请求并搜索逻辑模块配置文件，如果存在所述逻辑模块配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑模块数量；如果不存在所述逻辑进程配置文件，则先挂载一逻辑模块，根据该逻辑模块的运行状态和/或负载情况来确定后续补充挂载的逻辑模块数量。

当调度模块进入运行状态时，则开始接受前端下发的指令。用户发起业务需求后，首先被调度模块截获，调度者会根据某种具体的分配策略将该业务请求分配到其下挂载的模块中去，业务请求内的信息同时也会被分到实时数据库中，在分配成功后，调度者会收到处理者返回的消息。具体的，该步骤还可包括：将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的逻辑模块。其中，随机分配策略被配置为将收到的业务请求根据预设的分发顺序依次分配至下挂的子模块中。具体的，随机分配可以设置为，调度模块将收到的命令请求根据一个随机的调度策略分发给下挂的逻辑模块中去，分发的策略是在N个工作的逻辑模块中，每次以求余的方式，选择第i＝(i+1)mod n个模块来发送请求。其中，最小分配策略被配置为在分配前检测挂载的各逻辑模块的负载状态并分析其繁忙度，将所述业务请求发送至繁忙度最小的逻辑模块处理。具体的，最小分配可以设置为：调度模块在分发命令前检测各下挂的逻辑模块的负载状态，可以根据CPU和I/O两个维度来分析下挂逻辑模块的繁忙度。例如在WINDOWS操作系统下，可以通过系统提供的API接口查到模块占用的CPU和I/O信息，随后将命令发送到繁忙度最小的逻辑模块中去处理。当监听到一错误逻辑模块离线事件后，新挂载一逻辑模块来加载所述错误模块未完成信息。

需要说明的是，本说明书中前述各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的上述实现负载均衡的任务调度管理系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

如附图5所示，本发明还提供了一种实现负载均衡的任务调度管理装置，包括存储器4、处理器5以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述各实施例中描述的实现负载均衡的任务调度管理方法的各个步骤。

所述实现负载均衡的任务调度管理装置可包括但不仅限于，处理器、存储器。本领域技术人员可以理解，所述示意图仅仅是实现负载均衡的任务调度管理装置的示例，并不构成对实现负载均衡的任务调度管理装置设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述实现负载均衡的任务调度管理装置设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述实现负载均衡的任务调度管理装置设备的控制中心，利用各种接口和线路连接整个实现负载均衡的任务调度管理装置设备的各个部分。

所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述实现负载均衡的任务调度管理装置设备的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所述实现负载均衡的任务调度管理装置数据管理方法如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个实现负载均衡的任务调度管理方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

总之，以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所作的均等变化与修饰，皆应属本发明专利的涵盖范围。

Claims (6)

1.一种实现负载均衡的任务调度管理方法，其特征在于，包括：

获取业务请求并搜索逻辑进程配置文件；

如果存在所述逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量；

如果不存在所述逻辑进程配置文件，则预先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量；

将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的各逻辑进程，其中随机分配策略被配置为通过调度进程将收到的命令请求根据一个随机的调度策略分发给下挂的逻辑进程中去，分发的策略是在N个工作的逻辑进程中，每次以求余的方式选择第i=(i+1) mod n个进程来发送请求；所述最小分配策略被配置为通过调度进程在分发命令前检测各下挂的逻辑进程的负载状态，根据CPU和I/O两个维度来分析下挂逻辑进程的繁忙度，通过系统提供的API接口查到进程占用的CPU和I/O信息后将命令发送到繁忙度最小的逻辑进程中去处理；

在逻辑进程运行出现异常时，根据状态触发对应状态事件，并在资源释放完毕后便退出进程，调度进程在监听到子进程的关闭事件后重启新的进程服务，加载之前错误进程未完成的信息，所述状态事件包括：

错误状态事件：当处理进程无法被复制创建、终止或发送消息时会触发该事件；

退出事件：当处理进程退出时触发；

关闭事件：当处理进程完全退出时通知调度进程，当前进程已经完全离线；

放弃事件：当处理进程在启动过程中就发生了错误，并无限重启达到一定次数时触发该事件，触发该事件后在该事件中添加重要日志并发出报警。

2.根据权利要求1所述的任务调度管理方法，其特征在于，所述步骤根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量，具体包括：

获取预先挂载的逻辑进程的CPU使用率和磁盘占用率，当所述CPU使用率和磁盘占用率超过预设阈值时，持续补充挂载逻辑进程至所有逻辑进程的CPU使用率和磁盘占用率低于预设阈值。

3.根据权利要求2所述的任务调度管理方法，其特征在于，所述步骤将所述业务请求分配至所挂载的各逻辑进程，具体包括：当监听到一错误逻辑进程离线事件后，新挂载一逻辑进程来加载所述错误进程未完成信息。

4.一种实现负载均衡的任务调度管理系统，其特征在于，包括：

多个逻辑模块，用于对调度模块分配的业务请求进行执行；

调度模块，接受前台发送的业务请求并搜索逻辑进程配置文件，

如果存在所述逻辑进程配置文件则加载该配置文件，并根据配置文件确定需加载的逻辑进程数量；

如果不存在所述逻辑进程配置文件，则先挂载一逻辑进程，根据该逻辑进程的运行状态和/或负载情况来确定后续补充挂载的逻辑进程数量；

将所述业务请求根据预设的随机分配策略或最小分配策略分配至所挂载的各逻辑进程，其中随机分配策略被配置为通过调度进程将收到的命令请求根据一个随机的调度策略分发给下挂的逻辑进程中去，分发的策略是在N个工作的逻辑进程中，每次以求余的方式选择第i=(i+1) mod n个进程来发送请求；所述最小分配策略被配置为通过调度进程在分发命令前检测各下挂的逻辑进程的负载状态，根据CPU和I/O两个维度来分析下挂逻辑进程的繁忙度，通过系统提供的API接口查到进程占用的CPU和I/O信息后将命令发送到繁忙度最小的逻辑进程中去处理；在逻辑进程运行出现异常时，根据状态触发对应状态事件，并在资源释放完毕后便退出进程，调度进程在监听到子进程的关闭事件后重启新的进程服务，加载之前错误进程未完成的信息，所述状态事件包括：

错误状态事件：当处理进程无法被复制创建、终止或发送消息时会触发该事件；

退出事件：当处理进程退出时触发；

关闭事件：当处理进程完全退出时通知调度进程，当前进程已经完全离线；

放弃事件：当处理进程在启动过程中就发生了错误，并无限重启达到一定次数时触发该事件，触发该事件后在该事件中添加重要日志并发出报警。

5.一种实现负载均衡的任务调度管理装置，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于：所述处理器执行所述计算机程序时实现如权利要求1-3任一所述方法的步骤。

6.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现如权利要求1-3任一所述方法的步骤。