CN106921754A - 集群系统的负载均衡方法、装置、介质和电子设备 - Google Patents

Abstract

本发明提供了一种集群系统的负载均衡方法、装置、介质和电子设备。该集群系统的负载均衡方法包括：获取集群系统中各个节点的资源配额信息；根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。本发明的技术方案使得能够充分且高效地利用集群系统中各个节点的资源，提高了集群系统的处理效率，解决了单个节点负载过重，而其它节点空闲的问题，实现了集群系统的负载均衡。

Description

集群系统的负载均衡方法、装置、介质和电子设备

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种集群系统的负载均衡方法、装置、介质和电子设备。

背景技术

目前，大规模应用的服务系统都采取集群的方式进行部署，支持大量的用户访问，尤其是互联网应用系统。通常情况下，集群服务器上面部署的应用系统都是相同的，通过前端的负载均衡服务器经过反向代理，将客户请求转发给后端的应用服务器，这种方式即提升了系统的容量，也增强了系统的可用性。

但是，集群系统中的应用服务器之间是相互独立的，由于应用服务器之间缺乏有效的通信，因此前端请求被负载均衡服务器调度到哪个应用服务器上时，请求的任务就由该应用服务器独自完成，而其他对等的应用服务器，即使空闲或者压力非常小，也不会帮助有任务压力的应用服务器处理任务。可见，目前集群系统中的这种负载均衡方式不能实现服务器资源的高效、充分地利用，进而会影响集群系统的处理效率。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本发明的目的在于提供一种集群系统的负载均衡方法、装置、介质和电子设备，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的第一方面，提供了一种集群系统的负载均衡方法，包括：获取集群系统中各个节点的资源配额信息；根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。

在本发明的一些实施例中，基于前述方案，获取集群系统中各个节点的资源配额信息的步骤，包括：在所述各个节点订阅的广播频道上发布资源配额的获取请求，所述获取请求中包含有所述各个节点返回所述资源配额信息所使用的第一单播频道的信息；在所述第一单播频道上接收所述各个节点返回的资源配额信息。

在本发明的一些实施例中，基于前述方案，还包括：在发布所述资源配额的获取请求之后，启动第一定时任务；在所述第一定时任务的定时时间内，接收所述各个节点返回的资源配额信息。

在本发明的一些实施例中，基于前述方案，将向所述各个节点分配的任务信息通知给所述各个节点的步骤，包括：将向所述各个节点分配的任务信息存储至指定存储空间；在所述广播频道上发布针对所述待处理业务的处理请求，以使所述各个节点在接收到所述处理请求后从所述指定存储空间获取所述任务信息。

在本发明的一些实施例中，基于前述方案，还包括：在发布所述处理请求之后，启动第二定时任务；在所述第二定时任务的定时时间内，接收所述各个节点发送的处理响应结果。

在本发明的一些实施例中，基于前述方案，所述指定存储空间包括Redis；将所述任务信息存储至指定存储空间的步骤，包括：将所述获取请求的发送方的标识信息作为key，并将所述任务信息作为value存储至所述Redis中。

在本发明的一些实施例中，基于前述方案，所述任务信息通过哈希表的形式进行存储，其中，所述各个节点的标识名称作为所述哈希表的key，向所述各个节点分配的任务作为所述哈希表的value。

在本发明的一些实施例中，基于前述方案，所述处理请求中包含有所述各个节点返回对所述任务信息的处理响应结果所使用的第二单播频道的信息；

所述负载均衡方法还包括：在所述第二单播频道上接收所述各个节点发送的处理响应结果；根据所述各个节点发送的处理响应结果，确定所述待处理业务是否处理成功。

在本发明的一些实施例中，基于前述方案，所述获取请求和所述处理请求中包含有发送方的标识信息，所述标识信息与所述第一单播频道的信息和所述第二单播频道的信息相关联。

在本发明的一些实施例中，基于前述方案，所述标识信息包括第一信息和所述发送方的标识名称，所述第一信息包括随机序列或时间戳信息。

根据本发明的第二方面，提供了一种集群系统的负载均衡装置，包括：获取单元，用于获取集群系统中各个节点的资源配额信息；分配单元，用于根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；通知单元，用于将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。

根据本发明的第三方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述第一方面所述的集群系统的负载均衡方法。

根据本发明的第四方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述第一方面所述的集群系统的负载均衡方法。

在本发明的一些实施例所提供的技术方案中，通过根据待处理业务的信息和集群系统中各个节点的资源配额信息，向上述的各个节点分配对待处理业务进行处理的任务信息，使得能够充分且高效地利用各个节点的资源，提高了集群系统的处理效率，解决了单个节点负载过重，而其它节点空闲的问题，实现了集群系统的负载均衡。

在本发明的一些实施例所提供的技术方案中，通过在广播频道上发布资源配额的获取请求及待处理业务的处理请求，并在单播频道上接收资源配额信息和处理响应结果，使得能够提高通信效率，进而能够提高系统的处理效率。

在本发明的一些实施例所提供的技术方案中，通过使资源配额的获取请求和待处理业务的处理请求中包含的发送方的标识信息与第一单播频道的信息和第二单播频道的信息相关联，可以区分不同请求对应的任务流，进而可以解决在并发环境下任务流的完整性和一致性的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了一种集群系统的部署逻辑示意图；

图2示意性示出了根据本发明的第一个实施例的集群系统的负载均衡方法的流程图；

图3示意性示出了根据本发明的第二个实施例的集群系统的负载均衡方法的流程图；

图4示意性示出了根据本发明的实施例的基于Redis的负载均衡方法的流程图；

图5示出了根据本发明的实施例的互联网Web应用场景的部署逻辑示意图；

图6示出了图5中所示的互联网Web应用场景下的具体处理流程图；

图7示意性示出了根据本发明的实施例的集群系统的负载均衡装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

如图1所示为一种集群系统的部署逻辑示意图，在图1所示的集群系统中，Web负载均衡器在接收到前端的HTTP请求时，可以根据服务器的负载情况确定将HTTP请求调度到哪个服务器上进行响应，当HTTP请求被调到到任一服务器上时，该HTTP请求对应的任务就由该服务器独自完成，而其他对等的服务器，即使空闲或者压力比较小，也不会协助有任务压力的服务器来处理任务。图1所示的集群系统的部署逻辑不利于整体效率的提升，基于此，在本发明提出了技术方案更为完善的实施例。

图2示意性示出了根据本发明的第一个实施例的集群系统的负载均衡方法的流程图。

参照图2，根据本发明的第一个实施例的集群系统的负载均衡方法，包括如下步骤：

步骤S20，获取集群系统中各个节点的资源配额信息。

根据本发明的示例性实施例，步骤S20具体包括：在所述各个节点订阅的广播频道上发布资源配额的获取请求，所述获取请求中包含有所述各个节点返回所述资源配额信息所使用的第一单播频道的信息；在所述第一单播频道上接收所述各个节点返回的资源配额信息。

具体来说，各个节点可以事先订阅指定的广播频道，然后在该广播频道上接收资源配额的获取请求。

在本发明的一些实施例中，基于前述方案，还包括：在发布所述资源配额的获取请求之后，启动第一定时任务；在所述第一定时任务的定时时间内，接收所述各个节点返回的资源配额信息。

步骤S22，根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息。

需要说明的是，可以根据一定的分配策略来向集群系统中的各个节点分配任务信息。比如各个节点的资源配额信息相同时，可以平均分配任务；若各个节点的资源配额信息不相同，则可以根据不同的资源配额，分配相应的任务。

步骤S24，将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。

根据本发明的示例性实施例，步骤S24具体包括：将向所述各个节点分配的任务信息存储至指定存储空间；在所述广播频道上发布针对所述待处理业务的处理请求，以使所述各个节点在接收到所述处理请求后从所述指定存储空间获取所述任务信息。

在本发明的一些实施例中，基于前述方案，还包括：在发布所述处理请求之后，启动第二定时任务；在所述第二定时任务的定时时间内，接收所述各个节点发送的处理响应结果。

根据本发明的示例性实施例，上述的指定存储空间包括Redis，即可以将向各个节点分配的任务信息存储至Redis中。具体地，可以将获取请求的发送方的标识信息作为key，并将所述任务信息作为value存储至Redis中。

在本发明的一些实施例中，基于前述方案，所述任务信息通过哈希表的形式进行存储，其中，所述各个节点的标识名称作为所述哈希表的key，向所述各个节点分配的任务作为所述哈希表的value。

在本发明的一些实施例中，基于前述方案，所述处理请求中包含有所述各个节点返回对所述任务信息的处理响应结果所使用的第二单播频道的信息。如图3所示，所述负载均衡方法还包括：

步骤S26，在第二单播频道上接收各个节点发送的处理响应结果。

需要说明的是，第二单播频道与第一单播频道可以是同一个信道，也可以是不同的信道。在第二单播频道上接收各个节点发送的处理响应结果时，可以考虑时效的问题，即在本发明的一个实施例中，可以在上述第二定时任务的定时时间内，在该第二单播频道上接收各个节点发送的处理响应结果。

步骤S28，根据所述各个节点发送的处理响应结果，确定所述待处理业务是否处理成功。

根据本发明的示例性实施例，若在上述第二定时任务的定时时间内，所有节点发送的处理响应结果都为处理成功，则确定待处理业务处理成功；否则，确定待处理业务处理失败。

在本发明的一些实施例中，基于前述方案，所述获取请求和所述处理请求中包含有发送方的标识信息，所述标识信息与所述第一单播频道的信息和所述第二单播频道的信息相关联。

根据本发明的示例性实施例，第一单播频道和第二单播频道的名称可以为上述发送方的标识信息。

在本发明的一些实施例中，基于前述方案，所述标识信息包括第一信息和所述发送方的标识名称，所述第一信息包括随机序列或时间戳信息。

需要说明的是，图2和图3所示的集群系统的负载均衡方法的执行主体，即分配任务信息的设备可以是集群系统中的任一节点，也可以是集群系统之外的其它设备(如服务器)。也就是说，本发明实施例的负载均衡方法涉及到的节点，可以是对等的，也可以是不对等的。

以下以服务器集群系统中的任一服务器作为分配任务的设备为例，并基于Redis的发布订阅机制来阐述本发明实施例的技术方案：

参照图4，根据本发明的实施例的基于Redis的负载均衡方法，包括：

步骤S402，集群系统中的服务器订阅广播频道。

具体地，可以利用redis的发布订阅机制，在集群系统启动时，订阅指定的广播频道。

步骤S404，(接收到客户请求的服务器)在广播频道上发送获取各服务器的资源配额信息的请求。

具体地，集群系统中接收到客户请求的服务器在广播频道上发送获取各服务器的资源配额信息的请求。其中，上述的待处理业务可以是由集群系统前端的负载均衡器分配的任务。

步骤S406，各服务器接收到资源配额信息的请求后，在单播频道上发布资源配额响应消息。

具体地，各个服务器在广播频道上监听该资源配额信息的请求，并从该请求中获取发布资源配额响应消息所需的单播频道的信息，以在该单播频道上发布资源配额响应消息。

步骤S408，接收到客户请求的服务器接收各服务器发送的资源配额响应消息，在广播频道上发布计算请求消息。

具体地，接收到客户请求的服务器可以在指定的时间内，在上述的单播频道上监听各个服务器发送的资源配额响应消息，并综合各服务器的配额信息，按照一定的策略将任务分配给相应的服务器，然后将分配的任务信息数据写入redis中，并在广播频道上发布计算请求消息。

步骤S410，各服务器接收计算请求消息，进行任务处理，并发布计算响应消息。

具体地，各个服务器在广播频道上监听到计算请求消息后，从redis中取出自己的任务信息数据，开始处理相应的计算任务，并在指定单播频道上发布计算响应消息。

步骤S412，接收到客户请求的服务器收集综合各服务器的计算响应消息，并返回最终的处理结果。

具体地，接收到客户请求的服务器在指定的时间内，在上述的单播频道上监听各个服务器发送的计算响应消息，若所有的服务器都反馈了计算响应消息且状态为成功，则确定上述待执行业务执行成功，否则，确定待处理业务执行失败。

进一步的，在步骤S402中，需要给集群系统(该集群系统可以挂载在负载均衡器的后端)中的所有服务器配置一个唯一的标识名称的前缀，例如该前缀可以为serverX，其中的X是编号，比如可以是1、2等。另外，服务器的唯一标识名称由两部分组成：serverX前缀+时间戳。时间戳是由接收到客户请求的服务器生成的，该时间戳用作客户请求序号，在并发情况下，便于服务器集群系统内部区分不同的业务流。

上述的广播频道命名为loadbalance，当然也可以是任何其他名称。该广播频道用于收到客户请求的服务器向所有订阅了该广播频道的服务器发布消息。同时，该广播频道也用于所有服务器通过订阅获取指令。

在发布订阅机制下，发布的消息都可以是基于JSON(JavaScript ObjectNotation，一种轻量级的数据交换格式)格式。

在本发明的实施例中，可以定义如下用于集群中的服务器之间通信的消息：QuotaRequest、QuotaResponse、ComputerRequest和ComputerResponse。其中，QuotaRequest用作发布获取服务器资源配额消息、QuotaResponse用作各服务器反馈服务器资源配额消息，ComputerRequest用作发布任务分配的通知信息，ComputerResponse用于反馈服务器对任务的执行结果。

进一步的，在步骤S404中，接收到客户请求的服务器可以进行初步计算，得出客户请求执行的任务总量。然后生成时间戳，并结合系统中配置的服务器唯一标识名称的前缀serverX，生成最终的服务器唯一标识名称serverX_timestamp，例如：server1_1488162046892。这个服务器唯一标识名称在同一个客户请求任务的流程中保持不变。

设置定时任务Timer1Task，超时时间为Timer1，并订阅频道名称为serverX_timestamp的单播频道，准备获取资源配额响应消息。

在本发明的实施例中，接收到客户请求的服务器构建QuotaRequest消息，其具体报文可以为：

{'msgType':'QuotaRequest','taskSn':serverX_timestamp}。其中，taskSn字段用于标识消息来源，同时也可以用于告知其它服务器资源配额响应消息在什么频道上发布。最后，接收到客户请求的服务器在广播频道loadbalance上发布构建的QuotaRequest消息。

进一步的，在步骤S406中，各服务器接收到资源配额请求消息QuotaRequest之后，从中获取到taskSn字段的值serverX_timestamp。

收到QuotaRequest消息的服务器读取本机的服务器资源配额，并构建QuotaResponse消息，在以serverX_timestamp命名的单播频道上发布服务器资源配额响应消息QuotaResponse。

在本发明的实施例中，QuotaResponse的json报文格式可以为：{'msgType':'QuotaResponse','fromServer':serverY,'quota':{'cpu':c,'mem':m}}。其中，serverX与serverY在实际实现中可以相同，也可以不相同，c表示服务器的处理单元的数量，m表示服务器的内存量。当然，在本发明的其它实施例中，也可以包含其它资源配额信息。

进一步的，在步骤S408中，定时任务Timer1Task执行后，在Timer1时间内，接收到客户请求的服务器分析监听到的各服务器在serverX_timestamp频道上发布的QuotaResponse消息。消息中的fromServer字段表明资源配额消息的来源服务器，字段内容即为系统配置中的服务器唯一标识的前缀。

在本发明的实施例中，接收到客户请求的服务器按照一定的策略并基于QuotaResponse中quota字段的值来分配任务，具体的策略可以根据业务场景的不同进行调整。

接收到客户请求的服务器在分配任务之后，将任务信息taskData写入redis中，以便于各种数据格式的解析支持。在本发明的示例性实施例中，可以采用hash结构，用serverX_timestamp作key，并用serverY:task的hash数据结构作为value插入redis中。

在完成前述工作后，前述接收到客户请求的服务器启动定时任务Timer2Task，并在loadbalance广播频道上发布ComputerRequest消息。在本发明的实施例中，ComputerRequest消息的报文为：{'msgType':'ComputerRequest','taskSn':serverX_timestamp}。

进一步的，在步骤S410中，各服务器在广播频道loadbalance上监听到ComputerRequest的消息后，再以serverX_timestamp为key，从redis中读取hash数据结构，再从读到的hash类型的value中读取key为自己服务器唯一标识名称前缀serverY的数据，该数据即为任务数据信息。然后根据自己的任务数据信息，开始执行任务。在任务执行完成后，各服务器构建执行结果消息ComputerResponse。

在本发明的实施例中，ComputerResponse的报文结构可以为：{'msgType':'ComputerResponse','fromServer':serverY,'result':resultValue}。其中，serverX与serverY可以相同，也可以不同。任务成功时resultValue为success，否则resultValue为failure。

然后各个服务器根据监听到的ComputerRequest消息中的taskSn字段，将其作为单播频道名，即在serverX_timestamp频道上发布ComputerResponse消息。

进一步的，在步骤S412中，在前述定时任务Timer2Task的定时时间Timer2内，前述收到客户请求的服务器在上述的单播频道serverX_timestamp上监听各服务器发送的任务响应消息ComputerResponse。

若在Timer2时间内，前述的taskData中所有的serverY都有任务结果反馈消息ComputerResponse，且消息中的resultValue的值都为success，则确定整体任务执行结果为成功，否则为失败。然后，前述收到客户请求的服务器构建最终结果消息，并反馈给客户。最后取消对上述频道serverX_timestamp的订阅，释放redis资源。

在本发明的一个具体应用场景中，参照图5，是互联网的Web应用场景，比如用户利用CMS(Content Management System，内容管理系统)的页面静态化功能进行页面静态操作，并且需要静态操作的页面数量非常多。假设CMS应用后端有3台应用服务器。

具体过程如下：

(1)在应用系统的配置文件中，配置每台服务器的唯一标识名称的前缀。具体地，3台服务器分别配置成server1,server2,server3。同时，配置广播频道名称loadbalance。在应用系统启动时，利用redis的发布订阅机制，3台服务器都订阅loadbalance这个频道。

(2)HTTP请求被后端集群服务器中的一台server1收到。需要说明的是，HTTP请求可以是经Web负载均衡器调度给server1的(如图5所示)，也可以是直接接收到来自客户端的HTTP请求。服务器server1首先记录收到请求时的timestamp，比如1488243428227；再进行初步的计算任务预处理，得出任务列表；然后启动定时任务Timer1Task，时间为Timer1，在频道名为server1_1488243428227的频道上监听各服务器的资源配额反馈消息QuotaResponse，并利用loadbalance广播频道，构建并对外发布的QuotaRequest消息。其中，QuotaRequest消息的格式可以如下：

{msgType:QuotaRequest,taskSn:server1_1488243428227}

(3)各服务器(server1，server2，server3)在loadbalance广播频道上接收到QuotaRequest消息后，解析QuotaRequest消息中的taskSn字段，获取资源配额请求来源信息，准备构建资源配额消息QuotaResponse，在taskSn对应的频道server1_1488243428227上进行资源配额消息的发布。其中，QuotaResponse消息报文格式可以如下：

{msgType:QuotaResponse,fromServer:server1,quota:{cpu:4,mem:8196}}

{msgType:QuotaResponse,fromServer:server2,quota:{cpu:4,mem:8196}}

{msgType:QuotaResponse,fromServer:server3,quota:{cpu:4,mem:8196}}

(4)前述获取到HTTP请求的服务器server1，在Timer1定时器超时后，统计在server1_1488243428227频道上监听到的所有QuotaResponse消息，从中获取响应消息来源字段fromServer，以及quota的值，得知该server的CPU及内存配额信息(本发明的实施例并不限于此)。server1根据所有的QuotaResponse信息，将taskSn关联的任务依据既定的规则分配给相应的服务器，将任务数据信息采用hash结构写入redis，再构建ComputerRequest。启动定时任务Timer2Task，超时时间为Timer2，在server1_1488243428227上监听各服务器任务执行结果反馈消息。并在广播频道loadbalance上发布ComputerRequest消息。其中，ComputerRequest消息的报文格式可以如下：

{msgType:ComputerRequest,taskSn:server1_1488243428227}

(5)各服务器在loadbalance频道上监听到ComputerRequest消息后，解析出taskSn字段的值server1_1488243428227，然后从redis中取出key值为server1_1488243428227的hash结构的value值，也是一个hash结构，以各自的服务器唯一标识名称的前缀为key，从中取出任务数据信息，开始任务处理。处理成功则反馈结果状态为success，否则反馈结果状态为failure。同时，构建ComputerResponse消息，并在频道server1_1488243428227上发布。其中，ComputerResponse消息的报文格式可以如下：

{msgType:ComputerResponse,fromServer:server1,result:success}

{msgType:ComputerResponse,fromServer:server2,result:success}

{msgType:ComputerResponse,fromServer:server3,result:success}

(6)前述收到HTTP请求的服务器server1在Timer2的时间内，将在频道server1_1488243428227上监听到的任务执行结果响应消息进行综合。对于任务序号为server1_1488243428227的所有被分配了任务的服务器，若都反馈了ComputerResponse消息，且result的值都是success，则该HTTP请求对应的任务执行结果为success，否则为failure。最后，构建HTTP反馈，并发出HTTP响应消息给客户方，取消对单播频道server1_1488243428227的订阅，释放redis的相关资源。

在上述的应用场景中，具体的处理流程如图6所示。在图6所示的处理流程中，左边为接收到HTTP请求的服务器的处理流程，右边为集群服务器中其它服务器的处理流程。

参照图6，在系统启动时，集群服务器中的各个服务器都订阅广播频道，做好监听准备。接收到HTTP请求的服务器在广播频道上发布QuotaRequest消息，其它服务器在该广播频道上监听QuotaRequest消息，并在监听到QuotaRequest消息之后，在单播频道上发布QuotaResponse消息，接收到HTTP请求的服务器在定时器的定时时间内，在上述单播频道上监听QuotaResponse消息。然后根据QuotaResponse消息向Redis中设置各服务器的任务信息，并在广播频道上发布ComputerRequest消息。其它服务器在上述广播频道上监听ComputerRequest消息，在监听到ComputerRequest消息之后，从Redis中取相应的任务信息进行处理，当处理之后，在单播频道上发布ComputerResponse消息。接收到HTTP请求的服务器在定时器定时时间内在单播频道上监听ComputerResponse，当定时器的定时时间超时或者各服务器发布的响应消息都接收到时，依据ComputerResponse分析任务的处理结果，具体地，若所有被分配了任务的服务器反馈的ComputerResponse消息的状态均为成功，则确定任务处理成功；否则，确定任务处理失败。最后，发出HTTP响应消息给客户方。

需要说明的是：基于上述的实施例，可以将本发明实施例的技术方案扩展到更广阔的场景，比如基于本发明实施例的技术方案，还可以解决重内存或者重网络的问题，不局限于重计算问题。此外，服务器之间的通信不一定必须是基于redis的发布订阅机制，也可以采用其它具有发布订阅机制的系统，比如zookeeper等。标记任务序的taskSn的后缀部分，可以是任何随机序列，不一定是时间戳。参与任务分配的机器，不一定都是前端负载均衡器下挂载的对等服务器，也可以是其他辅助的用来解决算力的服务器。同时，本发明实施例中涉及到的四条消息可以是任何消息名称或报文格式，并且服务器之间通信消息的数量也并不限于上述实施例中所述的四条消息。

图7示意性示出了根据本发明的实施例的集群系统的负载均衡装置的框图。

参照图7，根据本发明的实施例的集群系统的负载均衡装置700，包括：获取单元702、分配单元704和通知单元706。

具体地，获取单元702用于获取集群系统中各个节点的资源配额信息；分配单元704用于根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；通知单元706用于将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。

需要说明的是，上述集群系统的负载均衡装置700中包含的各模块/单元的具体细节已经在对应的集群系统的负载均衡方法中进行了详细的描述，因此此处不再赘述。

此外，本发明的实施方式还提供一种电子设备，可以包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现本发明上述实施例所述的集群系统的负载均衡方法。

在示例性实施例中，本发明的实施例还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备可以实现如上述实施例中所述的集群系统的负载均衡方法。例如，可以实现如图2中所示的：步骤S20，获取集群系统中各个节点的资源配额信息；步骤S22，根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；步骤S24，将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。又如，也可以实现如图3、图4和图6中所示的步骤。

需要说明的是，本发明实施例中所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明的实施例中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本发明实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (13)

1.一种集群系统的负载均衡方法，其特征在于，包括：

获取集群系统中各个节点的资源配额信息；

根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；

将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。

2.根据权利要求1所述的集群系统的负载均衡方法，其特征在于，获取集群系统中各个节点的资源配额信息的步骤，包括：

在所述各个节点订阅的广播频道上发布资源配额的获取请求，所述获取请求中包含有所述各个节点返回所述资源配额信息所使用的第一单播频道的信息；

在所述第一单播频道上接收所述各个节点返回的资源配额信息。

3.根据权利要求2所述的集群系统的负载均衡方法，其特征在于，还包括：

在发布所述资源配额的获取请求之后，启动第一定时任务；

在所述第一定时任务的定时时间内，接收所述各个节点返回的资源配额信息。

4.根据权利要求2所述的集群系统的负载均衡方法，其特征在于，将向所述各个节点分配的任务信息通知给所述各个节点的步骤，包括：

将向所述各个节点分配的任务信息存储至指定存储空间；

在所述广播频道上发布针对所述待处理业务的处理请求，以使所述各个节点在接收到所述处理请求后从所述指定存储空间获取所述任务信息。

5.根据权利要求4所述的集群系统的负载均衡方法，其特征在于，还包括：

在发布所述处理请求之后，启动第二定时任务；

在所述第二定时任务的定时时间内，接收所述各个节点发送的处理响应结果。

6.根据权利要求4所述的集群系统的负载均衡方法，其特征在于，所述指定存储空间包括Redis；

将所述任务信息存储至指定存储空间的步骤，包括：

将所述获取请求的发送方的标识信息作为key，并将所述任务信息作为value存储至所述Redis中。

7.根据权利要求6所述的集群系统的负载均衡方法，其特征在于，所述任务信息通过哈希表的形式进行存储，其中，所述各个节点的标识名称作为所述哈希表的key，向所述各个节点分配的任务作为所述哈希表的value。

8.根据权利要求4所述的集群系统的负载均衡方法，其特征在于，所述处理请求中包含有所述各个节点返回对所述任务信息的处理响应结果所使用的第二单播频道的信息；

所述负载均衡方法还包括：

在所述第二单播频道上接收所述各个节点发送的处理响应结果；

根据所述各个节点发送的处理响应结果，确定所述待处理业务是否处理成功。

9.根据权利要求8所述的集群系统的负载均衡方法，其特征在于，所述获取请求和所述处理请求中包含有发送方的标识信息，所述标识信息与所述第一单播频道的信息和所述第二单播频道的信息相关联。

10.根据权利要求9所述的集群系统的负载均衡方法，其特征在于，所述标识信息包括第一信息和所述发送方的标识名称，所述第一信息包括随机序列或时间戳信息。

11.一种集群系统的负载均衡装置，其特征在于，包括：

获取单元，用于获取集群系统中各个节点的资源配额信息；

分配单元，用于根据待处理业务的信息和所述各个节点的资源配额信息，向所述集群系统中的各个节点分配对所述待处理业务进行处理的任务信息；

通知单元，用于将向所述各个节点分配的任务信息通知给所述各个节点，以使所述各个节点根据所述任务信息处理相应的任务。

12.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至10中任一项所述的集群系统的负载均衡方法。

13.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至10中任一项所述的集群系统的负载均衡方法。