CN107181636B - 一种负载均衡系统中的健康检查方法及装置 - Google Patents

Abstract

一种负载均衡系统中的健康检查方法及装置；所述方法包括：将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址；周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。本申请可以解决当一个后端服务器被配置在多个负载均衡服务中时，该后端服务器可能承受多个健康检查的流量的问题。

Description

一种负载均衡系统中的健康检查方法及装置

技术领域

本发明涉及负载均衡领域，尤其涉及一种负载均衡系统中的健康检查方法及装置。

背景技术

健康检查是负载均衡服务中非常重要的功能之一。负载均衡系统中的一个负载均衡服务主要包括以下几个元素：服务IP地址，服务端口，后端服务器IP地址，后端服务器端口。用于提供负载均衡服务的负载均衡器将流量转发到后端服务器上，并且通过周期性的健康检查来探测后端服务器是否在正常提供服务。

当前的健康检查方式是：对每个负载均衡服务的每个后端服务器分别进行健康检查，并分别根据对每个后端服务器健康检查的结果决定是否向该后端服务器进行流量转发。

健康检查涉及以下几个参数：

(1)健康检查地址(dst)，即负载均衡器对后端服务器进行健康检查的目标地址和端口；

(2)健康检查源地址(src)，即负载均衡器进行健康检查时的源地址；

(3)健康检查时间间隔(interval)，即负载均衡器对后端服务器进行健康检查的时间间隔；

(4)健康检查超时时间(timeout)，如果在这段时间内负载均衡器没有和后端服务器成功建立TCP(Transmission Control Protocol传输控制协议)连接，或者建立TCP连接成功但是后端服务器在这段时间内没有给予负载均衡器响应，那么就认为健康检查失败；

(5)健康检查正常阈值(rise)，当某台后端服务器已经处于异常状态，对它健康检查连续成功rise次，就认为这台后端服务器恢复到正常状态；

(6)健康检查异常阈值(fall)，当某台后端服务器已经处于正常状态，对它健康检查连续失败fall次，就认为这台后端服务器处于异常状态。

对于一个负载均衡服务，健康检查的流程是这样的：

一台后端服务器初始状态为正常(也可以初始状态为异常，取决于用户的配置需求)。

负载均衡器对后端服务器以interval的时间间隔分别对每台后端服务器(无论是正常状态还是异常状态)进行健康检查。对于原本状态为正常的后端服务器，如果连续fall次健康检查失败，则将这台后端服务器标记为异常，并且不会再对它进行流量转发。对于原本状态为异常的后端服务器，如果连续rise次健康检查成功，则将这台后端服务器标记为正常，并且开始对它进行流量转发。

这里，健康检查失败的定义是，负载均衡器和后端服务器建立TCP连接出错，或者在timeout时间内建立TCP连接失败，或者是建立TCP连接成功，但是在timeout时间内后端服务器没有给负载均衡器返回响应。

本申请的发明人在设计本申请的过程中发现，现有的健康检查方式存在如下问题：

往往同一台后端服务器会被配置在多个负载均衡服务里，对于每个负载均衡服务，负载均衡器会针对配置在该负载均衡服务里的每个后端服务器分别按照上述流程进行健康检查。这意味着如果一个后端服务器被配置在多个负载均衡服务中，该后端服务器就可能承受多个健康检查的流量，并且这些流量随着配置该后端服务器的负载均衡服务数量的增加而线性增加，将会给该后端服务器带来一定的压力。假定一台后端服务器被配置在M个负载均衡服务中，那么对于该后端服务器来说，一个interval内接收到的健康检查次数就为M。如果由于业务的丰富变化，需要将这台后端服务器配置到其他负载均衡服务中，即增大M，那么该后端服务器一个interval内接收到的健康检查次数也会增大。如果后端服务器本身的性能不特别强大，那么健康检查的次数增大后，产生的流量就会给后端服务器带来一定的负担。如果后端服务器上的配置不够优化，那么健康检查的次数增大后，也会造成过多的垃圾日志。

发明内容

本申请提供了一种负载均衡系统中的健康检查方法及装置，可以解决当一个后端服务器被配置在多个负载均衡服务中时，该后端服务器可能承受多个健康检查的流量的问题。

本申请采用如下技术方案。

一种负载均衡系统中的健康检查方法，包括：

将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址；

周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。

可选地，所述预定参数还包括以下任一个或任几个：健康检查源地址、健康检查时间间隔、健康检查超时时间。

可选地，所述将负载均衡系统中预定参数相同的健康检查任务进行合并包括：

当所述负载均衡系统中新增一个负载均衡服务的健康检查任务后，解析出新增的健康检查任务的所述预定参数；

在已保存的任务中根据所述预定参数进行查询，如果已保存的任务中存在与所述新增的健康检查任务的预定参数相同的第一任务，则将所述新增的健康检查任务作为所述第一任务的子任务，将所述第一任务作为合并后的健康检查任务；如果已保存的任务中不存在与所述新增的健康检查任务的预定参数相同的任务，则新建第二任务并保存，将所述新增的健康检查任务作为所述第二任务的子任务，将所述新增的健康检查任务的预定参数作为所述第二任务的预定参数，将所述第二任务作为合并后的健康检查任务。

可选地，所述在已保存的任务中根据所述预定参数进行查询包括：

对所述预定参数进行哈希运算得到哈希值；以所述哈希值作为关键字，在已保存的任务中查询是否存在以相同哈希值作为索引的任务；其中，每个所述已保存的任务的索引分别是以该任务的所述预定参数进行哈希运算得到的哈希值。

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

每次对所述健康检查地址对应的后端服务器执行所述合并后的健康检查任务之后，对于所述合并后的健康检查任务所包括的每个子任务，分别进行如下操作：

如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为正常，且对所述健康检查地址对应的后端服务器连续fall次健康检查失败，则将该后端服务器针对该子任务的状态标记为异常；其中，fall为该子任务的健康检查异常阈值；

如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为异常，且对所述健康检查地址对应的后端服务器连续rise次健康检查失败，则将该后端服务器针对该子任务的状态标记为正常；其中，rise为该子任务的健康检查正常阈值。

一种负载均衡系统中的健康检查装置，包括：

合并模块，用于将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址；

执行模块，用于周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。

可选地，所述预定参数还包括以下任一个或任几个：健康检查源地址、健康检查时间间隔、健康检查超时时间。

可选地，所述合并模块包括：

解析单元，用于当所述负载均衡系统中新增一个负载均衡服务的健康检查任务后，解析出新增的健康检查任务的所述预定参数；

更新单元，用于在已保存的任务中根据所述预定参数进行查询，如果已保存的任务中存在与所述新增的健康检查任务的预定参数相同的第一任务，则将所述新增的健康检查任务作为所述第一任务的子任务，将所述第一任务作为合并后的健康检查任务；如果已保存的任务中不存在与所述新增的健康检查任务的预定参数相同的任务，则新建第二任务并保存，将所述新增的健康检查任务作为所述第二任务的子任务，将所述新增的健康检查任务的预定参数作为所述第二任务的预定参数，将所述第二任务作为合并后的健康检查任务。

可选地，所述更新单元在已保存的任务中根据所述预定参数进行查询包括：

所述更新单元对所述预定参数进行哈希运算得到哈希值；以所述哈希值作为关键字，在已保存的任务中查询是否存在以相同哈希值作为索引的任务；其中，每个所述已保存的任务的索引分别是以该任务的所述预定参数进行哈希运算得到的哈希值。

可选地，所述的装置还包括：

状态设置模块，用于每次对所述健康检查地址对应的后端服务器执行所述合并后的健康检查任务之后，对于所述合并后的健康检查任务所包括的每个子任务，分别进行如下操作：如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为正常，且对所述健康检查地址对应的后端服务器连续fall次健康检查失败，则将该后端服务器针对该子任务的状态标记为异常；其中，fall为该子任务的健康检查异常阈值；如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为异常，且对所述健康检查地址对应的后端服务器连续rise次健康检查失败，则将该后端服务器针对该子任务的状态标记为正常；其中，rise为该子任务的健康检查正常阈值。

本申请包括以下优点：

本申请的一个备选方案能够根据健康检查配置的参数进行聚合，从而减少后端服务器上健康检查任务的数量。

本申请的一个备选方案在新增健康检查任务时首先查找是否已存在预定参数相同的任务，如果已存在则直接加入相应任务，如果不存在则新建任务并保存、加入，这样可以将每个健康检查任务的除了预定参数以外的参数保留在子任务中。

本申请的一个备选方案中，根据哈希值查找是否已存在预定参数相同的任务，加快了查找效率。

本申请的一个备选方案能够根据每个子任务的健康检查正常阈值、健康检查异常阈值分别反馈健康检查的结果。

当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有优点。

附图说明

图1是实施例一的负载均衡系统中的健康检查方法的流程图；

图2是示例的流程示意图；

图3是实施例二的负载均衡系统中的健康检查装置的示意图。

具体实施方式

下面将结合附图及实施例对本申请的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在一个典型的配置中，客户端或认证系统的计算设备可包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存(memory)。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。内存可能包括模块1，模块2，……，模块N(N为大于2的整数)。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)，快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

实施例一、一种负载均衡系统中的健康检查方法，如图1所示，包括步骤S110～S120：

S110、将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址，即健康检查的目标地址和端口；

S120、周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。

本实施例对后端服务器发起健康检查时，可以将同一个后端服务器上多个属于不同负载均衡服务、但目标地址和端口相同的健康检查任务(即：针对同一台后端服务器的同一个端口进行的健康检查)进行聚合，从而达到对该后端服务器只发起一个健康检查任务的效果。

本实施例可以但不限于应用在负载均衡器中。

本实施例的一种备选方案中，所述预定参数还可以包括以下任一个或任几个：健康检查源地址、健康检查时间间隔、健康检查超时时间。

本备选方案中，如果预定参数包括健康检查时间间隔，则意味着进行合并的健康检查任务的周期相同，因此周期性执行合并后的健康检查任务时，就是按照健康检查时间间隔执行，无需额外计算或选择执行周期/时间间隔。在其它备选方案中，健康检查时间间隔不同的健康检查也可以合并，合并时在参与合并的健康检查的参数中，挑选最短的健康检查时间间隔作为执行合并后的健康检查任务的时间间隔。

本备选方案中，如果预定参数包括健康检查源地址，则意味着进行合并的健康检查任务都是同一个负载均衡器发起的，该负载均衡器上直接可以得到执行结果。在其它备选方案中，也可以采用负载均衡器之外的设备执行合并后的健康检查任务，此时健康检查源地址不同的健康检查也可以合并，合并时记录参与合并的每个健康检查的健康检查源地址，执行完成后向所记录的每个健康检查源地址对应的负载均衡器分别反馈执行结果。

本备选方案中，如果预定参数包括健康检查超时时间，则意味着进行合并的健康检查任务的失败判断标准是相同的，因此可以对于合并后的健康检查任务一次性判断出是否失败。在其它备选方案中，健康检查超时时间不同的健康检查也可以合并，合并时记录参与合并的每个健康检查的健康检查超时时间，执行合并后的健康检查任务时，分别按照所记录的健康检查超时时间判断是否失败。

本实施例的一种备选方案中，所述将负载均衡系统中预定参数相同的健康检查任务进行合并可以包括：

当所述负载均衡系统中新增一个负载均衡服务的健康检查任务后，解析出新增的健康检查任务的所述预定参数；

在已保存的任务中根据所述预定参数进行查询，如果已保存的任务中存在与所述新增的健康检查任务的预定参数相同的第一任务，则将所述新增的健康检查任务作为所述第一任务的子任务，将所述第一任务作为合并后的健康检查任务；如果已保存的任务中不存在与所述新增的健康检查任务的预定参数相同的任务，则新建第二任务并保存，将所述新增的健康检查任务作为所述第二任务的子任务，将所述新增的健康检查任务的预定参数作为所述第二任务的预定参数，将所述第二任务作为合并后的健康检查任务。

本备选方案中，每个已保存的任务即合并后的健康检查任务，其中包括一个或多个子任务，一个已保存的任务中所包括的所有子任务的预定参数都相同。其中，每个子任务相当于一个健康检查任务，即针对一个负载均衡服务的一个后端服务器所进行的健康检查；每个子任务对应于一个负载均衡服务。每个已保存的任务的预定参数即该任务中每个子任务的预定参数。

本备选方案中，所述已保存的任务可以但不限于保存在任务列表中。

其它备选方案中，也可以采用其它方式进行合并操作；比如每次新增健康检查任务时记录参数，为所有预定参数相同的健康检查任务设置相同的标识，一个标识的健康检查任务只执行一次。

本备选方案的一种实施方式中，所述在已保存的任务中根据所述预定参数进行查询可以包括：

对所述预定参数进行哈希运算得到哈希值；以所述哈希值作为关键字，在已保存的任务中查询是否存在以相同哈希值作为索引的任务；其中，每个所述已保存的任务的索引分别是以该任务的所述预定参数进行哈希运算得到的哈希值。

比如保存的任务为任务1和任务2，任务1和任务2都是合并后的健康检查任务，各自包含一个或多个预定参数相同的子任务。假设预定参数为健康检查地址dst、健康检查源地址src、健康检查时间间隔interval和健康检查超时时间timeout，则任务1的索引为：对任务1的dst、src、interval、timeout(即任务1所包含的每个子任务的dst、src、interval、timeout)进行哈希运算得到的哈希值HASH-1；任务2的索引为：对任务2的dst、src、interval、timeout(即任务2所包含的每个子任务的dst、src、interval、timeout)进行哈希运算得到的哈希值HASH-2。假设新增的健康检查任务的预定参数与任务1的预定参数完全相同，则对新增的健康检查任务的预定参数进行哈希运算得到的结果也是HASH-1，根据HASH-1将可以查找出任务1。

其它实施方式中，也可以采用别的方式比较预定参数是否相同，比如可以直接用新增健康检查任务的预定参数和每个保存的任务的预定参数对应进行比较。

本备选方案中，一个保存的任务中如果包含两个或两个以上的子任务，则这些子任务的其它参数可以相同，也可以不同(全部不同或部分不同)。这里的其它参数可以但不限于是指健康检查涉及的上述6个参数中所述预定参数之外的参数。

本备选方案的一种实施方式中，所述方法还可以包括：

每次对所述健康检查地址对应的后端服务器执行所述合并后的健康检查任务之后，对于所述合并后的健康检查任务所包括的每个子任务，分别进行如下操作：

如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为正常，且对所述健康检查地址对应的后端服务器连续fall次健康检查失败，则将该后端服务器针对该子任务的状态标记为异常；其中，fall为该子任务的健康检查异常阈值；

如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为异常，且对所述健康检查地址对应的后端服务器连续rise次健康检查失败，则将该后端服务器针对该子任务的状态标记为正常；其中，rise为该子任务的健康检查正常阈值。

本实施方式中，一个合并后的健康检查任务中所包括的不同子任务的rise和fall可以相同，也可以不同；在进行正常/异常状态的转换时，是分别针对每个子任务进行判断。因此，当两个子任务的rise和fall不同而timeout相同时，在健康检查连续失败几次后，有可能同一台后端服务器针对一个负载均衡服务的状态仍保持正常，针对另一个负载均衡服务的状态则从正常改为异常。在进行负载均衡服务时，对于状态为正常的后端服务器进行流量转发，对于状态为异常的后端服务器则不转发流量，因此对于配置到多个负载均衡服务中的同一台后端服务器而言，有可能转发一部分负载均衡服务的流量，不转发另一部分负载均衡服务的流量。

可见，本实施方式在合并执行的情况下，能够针对不同的负载均衡服务独立设置、判断状态的转换条件，可以满足不同负载均衡服务的个性化需求。

本实施方式中，健康检查失败的含义可以为：和后端服务器建立TCP连接出错，或者在timeout时间内建立TCP连接失败，或者是建立TCP连接成功，但是在timeout时间内后端服务器没有返回响应。

本实施方式中，对于合并后的健康检查任务中所包含的每个子任务各自对应的负载均衡服务而言，同一个后端服务器的初始状态可以相同或不同；设置成不同时的例子如下：比如合并后的健康检查任务包含子任务A和子任务B，针对子任务A对应的负载均衡服务，后端服务器X的初始状态设置为正常，针对子任务B对应的负载均衡服务，后端服务器X的初始状态设置为异常。

本实施方式中，还可以保存每个子任务所对应的负载均衡服务的标识。

在其它实施方式中，不同子任务的参数中，除了rise、fall及预定参数以外的参数如果不同，则也可以按照子任务分别进行处理。比如预定参数不包括健康检查超时时间的情况下，一个已保存的任务中包括两个子任务：子任务A和子任务B。假设子任务A和子任务B的健康检查超时时间不相同，则根据子任务A的timeout判断对于子任务A是否健康检查失败，根据子任务B的timeout判断对于子任务B是否健康检查失败。假设子任务A的timeout长于子任务B的timeout，则有可能对于同一台后端服务器进行合并后的健康检查任务后，确定对于子任务B而言健康检查失败，对于子任务A则成功。

下面用一个示例说明上述实施例，该示例中定义了一个健康检查任务列表checker_queue，这个列表中的每个元素对应着一个合并后的健康检查任务checker。每个checker又包含一个或多个子任务sub_checker，每个sub_checker分别对应不同的负载均衡服务，每个sub_checker的参数来源于所对应的负载均衡服务的健康检查配置。

当新增一个负载均衡服务的健康检查任务时，发起健康检查任务的流程如图2所示，包括步骤201～206：

201、解析出新增的健康检查任务的健康检查配置(即参数)，主要是预定参数，本示例中预定参数为src、dst、interval、timeout，将这四个预定参数作为一个(src,dst,interval,timeout)四元组信息。

202、利用上述四元组信息，根据哈希算法计算出一个哈希值，以这个哈希值作为关键字在checker_queue中判断是否已经存在预定参数与新增的健康检查任务相同的checker。checker_queue中，每个checker的索引为对该checker的上述四元组信息进行哈希计算得到的哈希值。如果已经存在则进行步骤203，不存在则进行步骤204。

203、取出该预定参数相同的checker，进行步骤205。

204、根据新增的健康检查任务的健康检查配置新建一个checker，并插入到checker_queue中，进行步骤205。

205、根据新增的健康检查任务的信息(包括但不限于：预定参数以外的参数、所属负载均衡服务的标识等)生成sub_checker，并加入到步骤203取出的checker中或步骤204新建的checker中。

206、针对新增的健康检查任务所加入的checker启动健康检查任务；本步骤中可以按照该checker的参数(也就是新增的健康检查任务的参数)相应启动健康检查任务，比如根据dst对相应后端服务器执行健康检查，根据interval来确定健康检查的时间间隔等。

本示例中，对于checker_queue中的每个checker只启动一个健康检查任务；因此，对于四元组(src,dst,interval,timeout)相同的多个负载均衡服务的健康检查任务，也只会有一个checker，因此只会启动一个健康检查任务。

本实施例中，虽然同一个checker当中的sub_checker的四元组(src,dst,interval,timeout)完全相同，但是另外两个元素rise和fall不一定相同。

对于一个健康检查任务来说，它对应于一个checker，以及其下的多个sub_checker。当对一台后端服务器的一次健康检查完成之后，针对每个sub_checker分别获取rise和fall值后按照如下流程进行处理：

如果这台后端服务器对于该sub_checker对应的负载均衡服务的状态为正常，且连续fall次健康检查失败，则针对该sub_checker对应的负载均衡服务，将这台后端服务器标记为异常；这也就意味着在状态改为正常前，该sub_checker对应的负载均衡服务中不会再对该后端服务器进行流量转发(相当于在该sub_checker对应的负载均衡服务中删除该后端服务器)。

如果这台后端服务器对于该sub_checker对应的负载均衡服务的状态为异常，且连续rise次健康检查成功，则针对该sub_checker对应的负载均衡服务，将这台后端服务器标记为正常；这也就意味着在状态改为异常前，该sub_checker对应的负载均衡服务中会对该后端服务器进行流量转发(相当于在该sub_checker对应的负载均衡服务中添加该后端服务器)。

本示例通过对健康检查配置相同的负载均衡服务进行健康检查任务的聚合，来减少健康检查任务的数量。负载均衡器根据健康检查配置(src,dst,interval,timeout)四元组进行聚合，对这个四元组相同的健康检查任务只发起一个健康检查任务，在这个任务执行过程中还可以进行后端服务器的添加和删除。通过这样的设计可以减少健康检查的次数，使得健康检查流量不会因为负载均衡服务的增加而增加，可以达到降低健康检查流量对后端服务器压力的目的。

实施例二、一种负载均衡系统中的健康检查装置，如图3所示，包括：

合并模块21，用于将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址；

执行模块22，用于周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。

本实施例中，所述合并模块21是所述装置中负责合并健康检查任务的部分，可以是软件、硬件或两者的结合。

本实施例中，所述执行模块22是所述装置中负责执行合并后的健康检查任务的部分，可以是软件、硬件或两者的结合。

本实施例的一个备选方案中，所述预定参数还可以包括以下任一个或任几个：健康检查源地址、健康检查时间间隔、健康检查超时时间。

本实施例的一个备选方案中，所述合并模块可以包括：

解析单元，用于当所述负载均衡系统中新增一个负载均衡服务的健康检查任务后，解析出新增的健康检查任务的所述预定参数；

更新单元，用于在已保存的任务中根据所述预定参数进行查询，如果已保存的任务中存在与所述新增的健康检查任务的预定参数相同的第一任务，则将所述新增的健康检查任务作为所述第一任务的子任务，将所述第一任务作为合并后的健康检查任务；如果已保存的任务中不存在与所述新增的健康检查任务的预定参数相同的任务，则新建第二任务并保存，将所述新增的健康检查任务作为所述第二任务的子任务，将所述新增的健康检查任务的预定参数作为所述第二任务的预定参数，将所述第二任务作为合并后的健康检查任务。

本备选方案中，所述解析单元是所述合并模块中负责解析预定参数的部分，可以是软件、硬件或两者的结合。

本备选方案中，所述更新单元是所述合并模块中负责合并健康检查任务的部分，可以是软件、硬件或两者的结合。

本备选方案的一种实施方式中，所述更新单元在已保存的任务中根据所述预定参数进行查询可以包括：

所述更新单元对所述预定参数进行哈希运算得到哈希值；以所述哈希值作为关键字，在已保存的任务中查询是否存在以相同哈希值作为索引的任务；其中，每个所述已保存的任务的索引分别是以该任务的所述预定参数进行哈希运算得到的哈希值。

本备选方案的一种实施方式中，所述的装置还可以包括：

状态设置模块，用于每次对所述健康检查地址对应的后端服务器执行所述合并后的健康检查任务之后，对于所述合并后的健康检查任务所包括的每个子任务，分别进行如下操作：如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为正常，且对所述健康检查地址对应的后端服务器连续fall次健康检查失败，则将该后端服务器针对该子任务的状态标记为异常；其中，fall为该子任务的健康检查异常阈值；如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为异常，且对所述健康检查地址对应的后端服务器连续rise次健康检查失败，则将该后端服务器针对该子任务的状态标记为正常；其中，rise为该子任务的健康检查正常阈值。

其它实施细节可参见实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

当然，本申请还可有其他多种实施例，在不背离本申请精神及其实质的情况下，熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形，但这些相应的改变和变形都应属于本申请的权利要求的保护范围。

Claims (10)

1.一种负载均衡系统中的健康检查方法，包括：

将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址；

周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。

2.如权利要求1所述的方法，其特征在于，所述预定参数还包括以下任一个或任几个：健康检查源地址、健康检查时间间隔、健康检查超时时间。

3.如权利要求1或2所述的方法，其特征在于，所述将负载均衡系统中预定参数相同的健康检查任务进行合并包括：

当所述负载均衡系统中新增一个负载均衡服务的健康检查任务后，解析出新增的健康检查任务的所述预定参数；

在已保存的任务中根据所述预定参数进行查询，如果已保存的任务中存在与所述新增的健康检查任务的预定参数相同的第一任务，则将所述新增的健康检查任务作为所述第一任务的子任务，将所述第一任务作为合并后的健康检查任务；如果已保存的任务中不存在与所述新增的健康检查任务的预定参数相同的任务，则新建第二任务并保存，将所述新增的健康检查任务作为所述第二任务的子任务，将所述新增的健康检查任务的预定参数作为所述第二任务的预定参数，将所述第二任务作为合并后的健康检查任务。

4.如权利要求3所述的方法，其特征在于，所述在已保存的任务中根据所述预定参数进行查询包括：

对所述预定参数进行哈希运算得到哈希值；以所述哈希值作为关键字，在已保存的任务中查询是否存在以相同哈希值作为索引的任务；其中，每个所述已保存的任务的索引分别是以该任务的所述预定参数进行哈希运算得到的哈希值。

5.如权利要求3所述的方法，其特征在于，还包括：

每次对所述健康检查地址对应的后端服务器执行所述合并后的健康检查任务之后，对于所述合并后的健康检查任务所包括的每个子任务，分别进行如下操作：

如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为正常，且对所述健康检查地址对应的后端服务器连续fall次健康检查失败，则将该后端服务器针对该子任务的状态标记为异常；其中，fall为该子任务的健康检查异常阈值；

如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为异常，且对所述健康检查地址对应的后端服务器连续rise次健康检查失败，则将该后端服务器针对该子任务的状态标记为正常；其中，rise为该子任务的健康检查正常阈值。

6.一种负载均衡系统中的健康检查装置，其特征在于，包括：

合并模块，用于将所述负载均衡系统中预定参数相同的健康检查任务进行合并；所述预定参数至少包括健康检查地址；

执行模块，用于周期性对所述健康检查地址对应的后端服务器执行合并后的健康检查任务。

7.如权利要求6所述的装置，其特征在于，所述预定参数还包括以下任一个或任几个：健康检查源地址、健康检查时间间隔、健康检查超时时间。

8.如权利要求6或7所述的装置，其特征在于，所述合并模块包括：

解析单元，用于当所述负载均衡系统中新增一个负载均衡服务的健康检查任务后，解析出新增的健康检查任务的所述预定参数；

更新单元，用于在已保存的任务中根据所述预定参数进行查询，如果已保存的任务中存在与所述新增的健康检查任务的预定参数相同的第一任务，则将所述新增的健康检查任务作为所述第一任务的子任务，将所述第一任务作为合并后的健康检查任务；如果已保存的任务中不存在与所述新增的健康检查任务的预定参数相同的任务，则新建第二任务并保存，将所述新增的健康检查任务作为所述第二任务的子任务，将所述新增的健康检查任务的预定参数作为所述第二任务的预定参数，将所述第二任务作为合并后的健康检查任务。

9.如权利要求8所述的装置，其特征在于，所述更新单元在已保存的任务中根据所述预定参数进行查询包括：

所述更新单元对所述预定参数进行哈希运算得到哈希值；以所述哈希值作为关键字，在已保存的任务中查询是否存在以相同哈希值作为索引的任务；其中，每个所述已保存的任务的索引分别是以该任务的所述预定参数进行哈希运算得到的哈希值。

10.如权利要求8所述的装置，其特征在于，还包括：

状态设置模块，用于每次对所述健康检查地址对应的后端服务器执行所述合并后的健康检查任务之后，对于所述合并后的健康检查任务所包括的每个子任务，分别进行如下操作：如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为正常，且对所述健康检查地址对应的后端服务器连续fall次健康检查失败，则将该后端服务器针对该子任务的状态标记为异常；其中，fall为该子任务的健康检查异常阈值；如果所述健康检查地址对应的后端服务器针对该子任务所对应的负载均衡服务的当前状态为异常，且对所述健康检查地址对应的后端服务器连续rise次健康检查失败，则将该后端服务器针对该子任务的状态标记为正常；其中，rise为该子任务的健康检查正常阈值。

Images