CN113076192A - 一种负载均衡方法及装置、设备、存储介质 - Google Patents

Abstract

本申请实施例公开了一种负载均衡方法及装置、设备、存储介质，其中，该方法包括：基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

Description

一种负载均衡方法及装置、设备、存储介质

技术领域

本申请实施例涉及但不限于金融科技(Fintech)的信息技术，尤其涉及一种负载均衡方法及装置、设备、存储介质。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，然而，由于金融行业的安全性、实时性要求，金融科技也对技术提出了更高的要求。金融科技领域下，相关技术中负载均衡方法存在以下缺点：每次请求负载均衡器要做的计算工作很多，包括：遍历URL对应List的所有元素、计算出响应时间预测值、比较出最小响应时间预测值。

发明内容

有鉴于此，本申请实施例为解决相关技术中存在的至少一个问题而提供一种负载均衡方法及装置、设备、存储介质。

本申请实施例的技术方案是这样实现的：

一方面，本申请实施例提供一种负载均衡方法，所述方法包括：

基于客户端发送的统一资源定位器(Uniform Resource Locator，URL)请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID(Identity)；

从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

又一方面，本申请实施例提供一种负载均衡方法，所述方法包括：

第一目标服务器的代理接收负载均衡器的分析器发送的URL请求；

将当前URL请求的响应时间更新到所述第一目标服务器的响应节点数据结构；所述响应节点数据结构中包括：第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数；

根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值；

将所述更新的响应时间预测值和所述URL请求的执行结果封装成扩展协议报文；

将所述扩展协议报文作为响应结果发送给负载均衡器的分析器。

又一方面，本申请实施例提供一种负载均衡装置，所述装置包括：

第一确定模块，用于基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

第二确定模块，用于从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

第一接收模块，用于接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

第一更新模块，用于将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

又一方面，本申请实施例提供一种负载均衡装置，所述装置包括：

第一发送模块，用于第一目标服务器的代理接收负载均衡器的分析器发送的URL请求；

更新模块，用于将当前URL请求的响应时间更新到所述第一目标服务器的响应节点数据结构；所述响应节点数据结构中包括：第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数；

确定模块，用于根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值；

封装模块，用于将所述更新的响应时间预测值和所述URL请求的执行结果封装成扩展协议报文；

第二发送模块，用于将所述扩展协议报文作为响应结果发送给负载均衡器的分析器。

再一方面，本申请实施例提供一种负载均衡设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。

还一方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。

在本申请实施例中，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。这样，通过接收所述第一目标服务器的代理返回的响应结果；所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值，将原有在负载均衡分析器上执行的计算分摊在第一目标服务器上，减少了负载均衡器的CPU消耗。

附图说明

图1为本申请实施例负载均衡方法的实现流程示意图；

图2为本申请实施例负载均衡方法的实现流程示意图；

图3为本申请实施例负载均衡方法的实现流程示意图；

图4为本申请实施例负载均衡方法的实现流程示意图；

图5为本申请实施例负载均衡方法的实现流程示意图；

图6为本申请实施例负载均衡方法的实现流程示意图；

图7A为相关技术中负载均衡方法的示意图；

图7B为相关技术中负载均衡方法的实现流程示意图；

图7C为相关技术中请求信息的结构示意图；

图7D为本申请实施例负载均衡方法的示意图；

图7E为本申请实施例中扩展后的协议报文结构示意图；

图8A为本申请实施例中数据结构示意图；

图8B为本申请实施例中数据结构示意图；

图8C为本申请实施例中服务器请求相关数据结构示意图；

图8D为本申请实施例中扩展协议报文的结构示意图；

图9A为本申请实施例负载均衡装置的组成结构示意图；

图9B为本申请实施例负载均衡装置的组成结构示意图；

图10为本申请实施例中负载均衡设备的一种硬件实体示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和实施例对本申请的技术方案进一步详细阐述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

下面结合附图和实施例对本申请的技术方案进一步详细阐述。

本申请实施例提供一种负载均衡方法，图1为本申请实施例负载均衡方法的实现流程示意图，如图1所示，该方法包括：

步骤S101，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

这里，所述客户端可以为发出资源请求的请求方。

在实施过程中，发出资源请求的请求方、负载均衡器以及后台服务器(服务器、目标服务器)三者之间的交互过程为：发出资源请求的请求方将URL请求发送给负载均衡器的分析器，分析器根据请求的统一资源定位器(Uniform Resource Locator，URL)定位到自身的数据结构中，例如，图(Map)+链表(List)结构，从所述数据结构中选择响应时间预测值最小的数据元素，将所述响应时间预测值最小的数据元素作为目标元素，并将URL请求发送给所述目标元素对应的目标服务器(后台服务器)的代理；所述后台服务器的代理(Proxy)接收到所述URL请求后，根据响应所述URL请求的响应时间，计算出下一次接收到URL请求的情况下，响应所述URL请求的时间预测值；将所述响应时间预测值以及所述URL请求的执行结果一并发送给负载均衡器的分析器；由负载均衡器的分析器将执行结果返回给发出资源请求的请求方。

这里，所述数据结构可以为存储数据的任一种结构，例如，可以数组、栈、队列、链表(List)、树、散列表、堆和图(Map)。其中，所述数据结构为链表的情况下，所述数据结构中存储的数据元素可以为条目(Entry)，Entry包括以下内容：1)键值对key，value，其中，key用于存储服务器的编号(ID)，每一所述服务器ID对应一信息资源，每一信息资源对应唯一的URL；value用于存储对服务器请求的信息，包括：服务器ID、响应时间预测值(time)和权重值(weight)。这里，响应时间预测值为下一次接收到URL请求的情况下，响应所述URL请求的时间预测值。这里，所述权重值用于表示每一台服务器的优先级，例如，对2个CPU的服务器设定权重为3，给4个中央处理器(Central Processing Unit，CPU)的服务器设定权重值为6，权重越高，代表服务器响应请求的性能越好。2)pre，pro，next，其中，pre表示指向有序链表中该元素的前一个元素；pro表示指向有序链表中该元素中的后一个元素；next表示指向Map中当前下标对应链表中该元素的后一个元素。

步骤S102，从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

这里，所述响应时间预测值最小的数据元素表征对应的后台服务器具有更高效的响应URL请求的能力，响应URL请求的时间更短。

这里，所述响应时间预测值(time)最小的数据元素可以为一个数据元素，也可以为多个相同响应时间预测值的数据元素。

在一些实施例中，在time最小值对应一个数据元素(Entry)的情况下，负载均衡器的分析器请求所述Entry对应的服务器；在time最小值对应至少两个Entry的情况下，若每一Entry的权重值相同，分析器按照第一随机方法请求一台目标服务器；若每一Entry的权重值不相同，分析器按第二随机方法选择一台目标服务器进行请求。其中，目标服务器的代理接收URL请求，所述第一随机方法为等概率选择的方法，所述第二随机方法为非等概率方法。

举例说明，按照非等概率方法选择时，3台服务器，权重值分别为3、2、1，此时总权重为6，每一台服务器被选择的概率为0.5、0.33、0.17选择一台目标服务器。按照等概率方法选择时，3台服务器，权重值分别为1、1、1，此时总权重为3，每一台服务器被选择的概率都相同。

步骤S103，接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

这里，第一目标服务器的代理(Proxy)为请求的入口，Proxy分担了一部分原来由负载均衡器承担的计算职责，目的就是减轻负载均衡器的压力。其中，根据Proxy响应请求得到执行结果，并根据所述执行结果计算更新的响应时间预测值，即为分担了一部分原来由负载均衡器承担的计算职责。

这里，所述URL请求的执行结果为后台服务器对于URL请求的内容的执行结果。

步骤S104，将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

在一些实施例中，分析器将解析出的响应时间预测值更新到Entry(curEntry)的time中，由于time值发生变化，curEntry在list中的位置也可能会变动，所以要判断curEntry是否需要进行重排序操作，包括：

步骤S11，分析器将curEntry的time值(curEntryTime)与前一个Entry(preEntry)的time(preEntryTime)值进行比较；

步骤S12，如果小于preEntryTime则继续往前比较，直到遇到第一个小于等于curEntryTime的Entry(targetEntry)，或者，到达链表首部，然后将Entry从原有位置移除，插入curEntryTime后或者链表首部；

步骤S13，如果大于preEntryTime，则与后一个元素(proEntry)的time(proEntryTime)值比较，如果大于proEntryTime则继续往后查找，直到遇到第一个大于等于curEntryTime的Entry(targetEntry)，或者链表尾部，然后将Entry从原有位置移除，插入targetEntry前或者链表尾部；

步骤S14，如果大于preEntryTime并且小于proEntryTime，或等于二者中的任何一个，则元素位置不变。

在本申请实施例中，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。这样，通过接收所述第一目标服务器的代理返回的响应结果；所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值，将原有在负载均衡分析器上执行的计算分摊在第一目标服务器上，减少了负载均衡器的CPU消耗。

本申请实施例提供一种负载均衡方法，图2为本申请实施例负载均衡方法的实现流程示意图，如图2所示，该方法包括：

步骤S201，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

步骤S202，从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

步骤S203，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理；

在实施过程中，分析器在请求超时未返回的情况下，根据预设的条件重新选择一台目标服务器进行请求。

这里，重新选择一台目标服务可以保证当前请求被正常处理，预设的条件为：调用min(copyList)方法，copyList为当前List的副本。这里，需要说明的是，调用前会从copyList中移除这台请求超时的目标服务器对应的Entry，保证选出的是其他Entry。

步骤S204，接收所述第二目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

步骤S205，将更新的响应时间预测值更新到所述第二目标元素中，并将所述执行结果发送给所述客户端。

在本申请实施例中，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理，这样，能够将无法响应请求的目标服务器从服务器集群中移除，动态调整可选择的服务器列表，提高了目标服务器响应请求的概率，从而提高了负载均衡器发送请求的有效性。

本申请实施例提供一种负载均衡方法，图3为本申请实施例负载均衡方法的实现流程示意图，如图3所示，该方法包括：

步骤S301，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

步骤S302，从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

步骤S303，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，建立所述数据结构的副本；

在实施过程中，由于需要从数据结构中将无法响应请求的元素删除，因此，需要建立数据结构的副本。

步骤S304，从所述数据结构的副本中去除所述第一目标元素；

在实施过程中，从数据结构的副本(copyList)中移除这台请求超时服务器对应的entry，保证选出的是其他entry。

步骤S305，从更新后的所述副本中将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理；

步骤S306，接收所述第二目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

步骤S307，将更新的响应时间预测值更新到所述第二目标元素中，并将所述执行结果发送给所述客户端。

在本申请实施例中，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，建立所述数据结构的副本；从所述数据结构的副本中去除所述第一目标元素，这样，一方面，在调用前会从副本中移除这台请求超时服务器对应的数据元素，保证选出的是其他后台服务器；另一方面，由于需要进行移除等操作，通过建立所数据结构的副本，保证了URL请求对应的原数据元素的一致性和有效性。

本申请实施例提供一种负载均衡方法，图4为本申请实施例负载均衡方法的实现流程示意图，如图4所示，该方法包括：

步骤S401，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

步骤S402，从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

步骤S403，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理；

步骤S404，接收所述第二目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

步骤S405，将更新的响应时间预测值更新到所述第二目标元素中，并将所述执行结果发送给所述客户端。

步骤S406，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，调用滑动窗口的插入方法，判定所述第一目标服务器是否满足异常判定规则；

这里，在请求超时的服务器满足异常规则的情况下，从map及list中移除该Entry，在未判定该服务器恢复前，分析器不会再请求该服务器。

这里，异常判定规则：判定规则由负载均衡器的使用者配置，包含两个参数，winSize表示时间窗口大小(单位：秒)、timeoutTimes表示请求超时次数，例如，winSize＝10，timeoutTimes＝5表示10秒内超时5次则认定服务器异常。

步骤S407，在所述第一目标服务器满足所述异常判定规则的情况下，从所述数据结构中移除所述第一目标服务器对应的第一目标元素，以在未判定所述第一目标服务器恢复处理请求功能前，不再向所述第一目标服务器发送请求。

这里，执行步骤S403至步骤S405，与执行步骤S406和步骤S407没有先后之分。

在本申请实施例中，使用滑动窗口判定指定服务器是否触发异常规则，通过滑动窗口限定进行触发异常规则的时间范围，能够实现频率控制机制，对超时的服务器进行检测，提高服务器响应请求的概率。

本申请实施例提供一种负载均衡方法，该方法包括：

步骤S501，基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

步骤S502，从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

步骤S503，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理；

步骤S504，接收所述第二目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

步骤S505，将更新的响应时间预测值更新到所述第二目标元素中，并将所述执行结果发送给所述客户端。

步骤S506，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，获取所述第一目标服务器的滑动窗口数据结构；所述滑动窗口数据结构中元素的个数表征所述第一目标服务器发生超时的次数；

在实施过程中，将链表作为滑动窗口(sliceWindow)的数据结构，每个超时的服务器对应一个超时请求发生时间的链表，链表的每个节点仅存储一个时间戳，每个时间戳代表一个超时请求的发生时间。

步骤S507，基于所述预设的时间窗口，确定滑动窗口数据结构在所述预设的时间窗口内元素的个数；所述元素的个数表征所述第一目标服务器在预设窗口内发生超时的目标次数；

步骤S508，判断所述目标次数是否大于所述预设的次数阈值，以判定所述第一目标服务器是否满足异常判定规则；其中，所述异常判定规则包括在预设的时间窗口请求超时次数大于预设的次数阈值；

举例说明，判断元素的时间戳是否已经超出时间窗口(Tw秒)，是则移除元素，比如Tw＝60，当前时间为20点30分15秒，时间戳在20点29分15秒之前的就在时间窗口之外，应该被移除。遍历完成后，判断剩余元素数量是否大于阈值Cm，是则返回false表示服务器异常，否则返回true表示可以继续请求服务器。

步骤S509，在所述第一目标服务器满足所述异常判定规则的情况下，从所述数据结构中移除所述第一目标服务器对应的第一目标元素，以在未判定所述第一目标服务器恢复处理请求功能前，不再向所述第一目标服务器发送请求。

在一些实施例中，所述方法还包括：步骤S511，在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，向所述滑动窗口数据结构中插入元素；所述元素用于存储所述第一目标服务器超时请求的时间。

举例说明，sliceWindow插入方法：sliceWindow只对外提供一个返回值为布尔类型的插入方法，插入时，首先将当前时间戳追加到链表尾部，然后从头遍历链表元素。

在一些实施例中，所述方法还包括：步骤S521，定时扫描所述滑动窗口数据结构中的末尾元素；步骤S522，在所述末尾元素发生超时请求的时间大于所述时间窗口的预设倍数的情况下，移除所述滑动窗口数据结构。

举例说明，sliceWindow中的链表何时销毁：通常情况下，超时的概率会比较低，多数时间sliceWindow中的链表并不会发生插入操作，链表中就很可能维持着无用元素并且得不到释放。为了减小内存压力，分析器会定时扫描所有链表的尾节点，如果节点中的时间戳在当前时间3倍的窗口期之前，就会销毁该链表，回收内存，比如Tw＝60，当前时间为20点30分15秒，尾节点时间戳在20点27分15秒之前，表示该服务器已经超过3分钟没有发生超时了，就认为链表没有继续存在的意义了，可以被销毁掉。

在本申请实施例中，一方面，基于所述预设的时间窗口，确定滑动窗口数据结构在所述预设的时间窗口内元素的个数；所述元素的个数表征所述第一目标服务器在预设窗口内发生超时的目标次数；判断所述目标次数是否大于所述预设的次数阈值，以判定所述第一目标服务器是否满足异常判定规则；其中，所述异常判定规则包括在预设的时间窗口请求超时次数大于预设的次数阈值；这样，通过异常规则的判定可以及时发现异常服务器。另一方面，定时扫描所述滑动窗口数据结构中的末尾元素；在所述末尾元素发生超时请求的时间大于所述时间窗口的预设倍数的情况下，移除所述滑动窗口数据结构；这样，能够在互动窗口的数据结构不更新的情况下，释放无用元素，避免了数据结构中维持着无用元素并且得不到释放，减小了内存压力。

本申请实施例提供一种负载均衡方法，图5为本申请实施例负载均衡方法的实现流程示意图，如图5所示，该方法包括：

步骤S510，在基于所述URL请求中的URL，确定不到对应的数据结构的情况下，为所述URL初始化一对应的数据结构；

在实施过程中，在所述数据结构为Map的情况下，确定不到对应的数据结构表征如果Map为空。这里，如果map为空，说明是第一次收到对于该URL的请求。

步骤S520，向所述数据结构中插入初始化数据元素，并对所述初始化元素的响应时间预测值进行初始化；

这里，服务器ID列表以及权重值来源于负载均衡器已有数据，time参数初始化为0。

这里，在List插入Entry数据包括：1)用time初始值(curTime)从链表首节点开始逐个往后比较，直到遇到第一个time参数大于等于curTime的Entry(targetEntry)，然后将Entry插入targetEntry前面，如果到链表尾部还没找到符合条件的Entry，则将Entry插入链表尾部，注意，插入都是指针操作。

举例说明，CurTime＝4；链表中包括3个节点，从第一个节点开始每一节点中的time参数分别为，aTime＝2，bTime＝3，cTime＝6；对比到cTime节点时，cTime＝6大于CurTime＝4，将Entry插入到cTime对应的节点前。

步骤S530，将所述URL请求发送给任一所述初始化数据元素对应的第一目标服务器的代理；

举例说明，初始化为0后，每一个entry中time参数对应的值都最小，任一选择一个响应请求。

步骤S540，接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

步骤S550，将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

在一些实施例中，所述响应结果为扩展协议报文，所述步骤S540，接收所述第一目标服务器的代理返回的响应结果，包括：接收所述第一目标服务器的代理通过扩展协议返回的扩展协议报文，其中，所述扩展协议报文至少包括所述URL请求的执行结果和所述更新的响应时间预测值。

这里，图7E为本申请实施例中扩展后的协议报文结构示意图，如图7E所示，扩展后的协议报文结构由报文头(header)，报文主体(body)组成。

这里，header中存储了报文的属性信息，例如，长度(length)，报文信息(info)，扩展部分。这里，扩展部分内存储响应时间预测值。这里，body中存储根据扩展协议报文结构通信的执行结果。

在实施过程中，负载均衡器的分析器通过扩展协议报文能够读取后台服务器的代理传输的URL请求的执行结果和所述更新的响应时间预测值。

在本申请实施例中，向所述数据结构中插入初始化数据元素，并对所述初始化元素的响应时间预测值进行初始化；这样，可以为没有请求过的URL对应的服务器初始化一个数据元素，待下次访问时，能够将请求发送到闲置资源较丰富的服务器上，提高了分布式结构中请求的处理效率。

本申请实施例提供一种负载均衡方法，图6为本申请实施例负载均衡方法的实现流程示意图，如图6所示，该方法包括：

步骤S601，第一目标服务器的代理接收负载均衡器的分析器发送的URL请求；

在一些实施例中，在执行完成步骤S601之后，所述方法还包括：

步骤S21，接收负载均衡器的分析器发送的URL请求；

步骤S22，记录处理所述URL请求的起始时间；

步骤S23，将所述URL请求发送给第一目标服务器；

步骤S24，接收所述第一目标服务器发送的URL请求的执行结果，记录URL请求的结束时间；

步骤S25，将所述URL请求的起始时间和所述URL请求的结束时间差值确定为当前请求的响应时间。

步骤S602，将当前URL请求的响应时间更新到所述第一目标服务器的响应节点数据结构；所述响应节点数据结构中包括：第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数；

在实施过程中，Proxy维护一个服务器请求相关的数据结构(reqNode)，如图8C所示，reqNode中包括：总请求数、总响应时间和堆积请求数。在Proxy收到负载均衡器发来的请求后，Proxy记录请求起始时间，然后调用后台服务。

步骤S603，根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值；

举例说明，响应时间预测值通过公式(1)进行计算，公式(1)为：

响应时间预测值＝(总响应时间-超时响应时间)/(总请求数-超时请求数)×堆积请求数； (1)；

步骤S604，将所述更新的响应时间预测值和所述URL请求的执行结果封装成扩展协议报文；

举例说明，Proxy组装扩展协议报文，将后台服务执行结果result和响应时间预测值Tn放入报文中，报文的结构如图8D，返回给负载均衡器。

步骤S605，将所述扩展协议报文作为响应结果发送给负载均衡器的分析器。

在本申请实施例中，根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值，这样，能够将原本由负载均衡器负责的部分计算职责下推到目标服务器，减少了负载均衡器的CPU消耗。

图7A为相关技术中负载均衡方法的示意图，如图7A所示，相关技术中，由负载均衡器的分析器71负责请求时间预测以及路由决策，以及接收后台服务器72返回的响应结果。

本申请实施例提供一种负载均衡方法，图7B为相关技术中负载均衡方法的实现流程示意图，如图7B所示，该方法包括：

步骤S701，负载均衡器接收请求方(客户端)发出的请求(URL请求)，并根据URL请求中的URL，定位对应的数据结构(List结构)；

这里，所述负载均衡器的分析器为每类URL维护一个链表(List)结构；

这里，所述List结构中存放每一后台服务器对应的请求信息，如图7C所示，所述请求信息包括服务器ID、总请求数、总响应时间、超时请求数、超时响应时间、堆积请求数、权重值。

步骤S702，在将URL请求发送给后台服务器72之前，遍历URL请求对应的List结构；

步骤S703，计算响应时间预测值；

这里，所示响应时间预测值为下次请求到后台服务器72后预计需要等待的时间。这里，响应时间预测值通过公式(1)进行计算。

步骤S704，比较最小响应时间预测值；

步骤S705，根据比较结果，确定接收所述URL请求的目标服务器；

在一些实施例中，所述步骤S705，根据比较结果，确定接收所述URL请求的目标服务器，包括：

步骤S705A，在所述最小响应时间预测值为一个的情况下，将URL请求发送给所述最小响应时间预测值对应的目标服务器；

在实施过程中，遍历完成后，比较出最小的响应时间预测值，如果对应的服务器只有一台，就请求这台服务器。

步骤S705B，在所述最小响应时间预测值为多个且权重值相同的情况下，基于随机算法确定一个目标服务器，并将URL请求发送给所述目标服务器；

在实施过程中，如果有多台，并且权重相等，则随机选择一个。

步骤S705C，在所述最小响应时间预测值为多个且权重值不相同的情况下，基于加权随机算法确定一个目标服务器，并将URL请求发送给所述目标服务器；

在实施过程中，如果有多个并且权重不相等，通过加权随机算法选择一台。

步骤S706，接收所述目标服务器返回的执行结果(响应结果)；

步骤S707，根据所述响应结果，修改List结构中目标机器(目标服务器)的请求信息；

请求完成收到后台服务器响应后，修改list中对应服务器的请求信息(比如总请求数+1，总响应时间加上本次调用耗时等)，用于下次计算。

步骤S708，在修改List结构中目标机器的请求信息之后，将所述执行结果发送给请求方。

由此可见，相关技术中存在以下缺点：1)每次请求负载均衡器要做的计算工作很多，包括：遍历URL对应List的所有元素、计算出响应时间预测值、比较出最小响应时间预测值；2)每次请求完成后，还需要在负载均衡器的List元素中修改目标服务器对应的请求信息，包括总请求数、总响应时间；3)如果请求超时，还需要修改超时请求数以及超时响应时间；在多线程环境下，这里的修改一般通过比较并交换(Compare and Swap，CAS)实现。无论是高频请求、或，服务器数量众多的场景，都会带来CPU负载问题，并且请求频率越高、服务器数量越多，负载问题越严重。

为解决上述问题，本申请实施例提供一种负载均衡方法，通过将负载均衡器中部分计算下推到服务器，由服务器增设的代理(Proxy)执行计算，并将计算结果与服务器的执行结果组装成符合扩展通信协议的报文，通过扩展通信协议传回负载均衡器。这样，负载均衡器通过特定算法，例如，最小值算法(min(copyList))、随机算法、加权随机算法，与Proxy配合完成最短时间负载均衡。

本申请实施例通过为服务器增设代理层(Proxy)，用于实现相关技术中由负载均衡器实现的部分计算。图7D为本申请实施例负载均衡方法的示意图，如图7D所示，负载均衡器的分析器73通过扩展后的协议与每一服务器的Proxy74进行通信，例如，Proxy可以实现负责代理层所在服务器的请求数据的分析和计算、调起后台服务、并将计算结果与服务器的执行结果组装成符合扩展通信协议的报文，通过扩展通信协议传回负载均衡器。负载均衡器的分析器通过一定的算法，例如，最小值算法(min(copyList))、随机算法、加权随机算法，和Proxy配合完成最短时间响应负载均衡。

图7E为本申请实施例中扩展后的协议报文结构示意图，如图7E所示，扩展后的协议报文结构由报文头(header)，报文主体(body)组成。

这里，header中存储了报文的属性信息，例如，长度(length)，报文信息(info)，扩展部分。这里，扩展部分内存储响应时间预测值。

这里，body中存储根据扩展协议报文结构通信的执行结果。

本申请实施例提供的一种负载均衡方法，分析器为每一信息资源的唯一定位(Uniform Resource Locator，URL)维护了一个图结构(Map)和有序链表(List)结构，存储对应的服务器的响应时间信息。图8A为本申请实施例中数据结构示意图，如图8A所示，虚线表示的是Map中数组下标对应的链表中元素的前后关系；实线表示的是有序链表list中每一数据(Entry)的前后关系。

图8B为本申请实施例中数据结构示意图，如图8B所示，Entry包括以下内容：1)键值对key，value，其中，key用于存储服务器的编号(ID)，每一所述服务器ID对应一信息资源，每一信息资源对应唯一的URL；value用于存储对服务器请求的信息，包括：服务器ID、响应时间预测值(time)和权重值(weight)。这里，所述权重值用于表示每一台服务器的优先级，例如，对2个CPU的服务器设定权重为3，给4个中央处理器(Central Processing Unit，CPU)的服务器设定权重值为6，权重越高，代表服务器响应请求的性能越好。

2)pre，pro，next，其中，pre表示指向有序链表中该元素的前一个元素；pro表示指向有序链表中该元素中的后一个元素；next表示指向Map中当前下标对应链表中该元素的后一个元素。

本申请实施例提供一种负载均衡方法，该方法包括：

在请求到达负载均衡器的情况下，负载均衡器中的分析器实现负载均衡的步骤为：

步骤S801，分析器根据URL定位到对应的Map和List；

步骤S802，如果Map为空，分析器为URL初始化Map、List结构，并向Map和List中插入URL对应的Entry数据；

这里，如果map为空，说明是第一次收到对于该URL的请求。

这里，服务器ID列表以及权重值来源于负载均衡器已有数据，time参数初始化为0。

这里，在List插入Entry数据包括：1)用time初始值(curTime)从链表首节点开始逐个往后比较，直到遇到第一个time参数大于等于curTime的Entry(targetEntry)，然后将Entry插入targetEntry前面，如果到链表尾部还没找到符合条件的Entry，则将Entry插入链表尾部，注意，插入都是指针操作。

举例说明，CurTime＝4；链表中包括3个节点，从第一个节点开始每一节点中的time参数分别为，aTime＝2，bTime＝3，cTime＝6；对比到cTime节点时，cTime＝6大于CurTime＝4，将Entry插入到cTime对应的节点前。

步骤S803，如果Map不为空，分析器调用min(copyList)方法；

这里，copyList为当前List的副本，min方法会从copyList中取出time最小的(排在最前面的)一个或多个Entry。这里，所述多个Entry具有相同的time参数值，且，对应的time参数值为链表中的最小值。

步骤S804，在time最小值对应一个Entry的情况下，分析器请求所述Entry对应的服务器；在time最小值对应至少两个Entry的情况下，若每一Entry的权重值相同，分析器按照第一随机方法请求一台服务器Entry；若每一Entry的权重值不相同，分析器按第二随机方法选择一台目标服务器进行请求。

这里，所述第一随机方法为等概率选择的方法，所述第二随机方法为非等概率方法。

举例说明，按照非等概率方法选择时，3台服务器，权重值分别为3、2、1，此时总权重为6，每一台服务器被选择的概率为0.5、0.33、0.17选择一台服务器。按照等概率方法选择时，3台服务器，权重值分别为1、1、1，此时总权重为3，每一台服务器被选择的概率都相同。

分析器确定请求路由的服务器后，负载均衡器将请求路由到后台服务器，具有以下两种情况：

1)在请求正常返回的情况下，执行步骤S41和步骤S42：

步骤S41，在请求正常返回的情况下，分析器解析出服务器给出响应中的响应时间预测值；

步骤S42，根据服务器ID获取Map中的Entry，分析器将解析出的响应时间预测值更新到Entry(curEntry)的time中，由于time值发生变化，curEntry在list中的位置也可能会变动，所以要判断curEntry是否需要进行重排序操作，包括：

步骤S421，分析器将curEntry的time值(curEntryTime)与前一个Entry(preEntry)的time(preEntryTime)值进行比较；

步骤S422，如果小于preEntryTime则继续往前比较，直到遇到第一个小于等于curEntryTime的Entry(targetEntry)，或者，到达链表首部，然后将Entry从原有位置移除，插入curEntryTime后或者链表首部；

步骤S423，如果大于preEntryTime，则与后一个元素(proEntry)的time(proEntryTime)值比较，如果大于proEntryTime则继续往后查找，直到遇到第一个大于等于curEntryTime的Entry(targetEntry)，或者链表尾部，然后将Entry从原有位置移除，插入targetEntry前或者链表尾部；

步骤S424，如果大于preEntryTime并且小于proEntryTime，或等于二者中的任何一个，则元素位置不变。

2)在请求超时未返回的情况下，执行步骤S51和步骤S52：

步骤S51，分析器在请求超时未返回的情况下，根据预设的条件重新选择一台服务器进行请求；

这里，重新选择一台服务可以保证当前请求被正常处理，预设的条件为：调用min(copyList)方法，copyList为当前List的副本。这里，需要说明的是调用前会从copyList中移除这台请求超时服务器对应的Entry，保证选出的是其他Entry。由于需要进行移除等操作，因此这也是min方法使用List副本作为参数的原因，就是为了动态调整可选择的服务器列表；

步骤S52，分析器调用滑动窗口的插入方法，判定请求超时的服务器是否满足异常规则；

这里，在请求超时的服务器满足异常规则的情况下，从map及list中移除该Entry，在未判定该服务器恢复前，分析器不会再请求该服务器。

这里，服务器异常判定规则：判定规则由负载均衡器的使用者配置，包含两个参数，winSize表示时间窗口大小(单位：秒)、timeoutTimes表示请求超时次数，例如，winSize＝10，timeoutTimes＝5表示10秒内超时5次则认定服务器异常。

本申请实施例使用滑动窗口(sliceWindow)判定指定服务器是否触发异常规则，通过sliceWindow限定进行触发异常规则的时间范围，sliceWindow作为一种频率控制机制，适合用于超时频率检测的场景中。

本申请实施例将链表作为sliceWindow的数据结构，每个超时的服务器对应一个超时请求发生时间的链表，链表的每个节点仅存储一个时间戳，每个时间戳代表一个超时请求的发生时间。

sliceWindow插入方法：sliceWindow只对外提供一个返回值为布尔类型的插入方法，插入时，首先将当前时间戳追加到链表尾部，然后从头遍历链表元素，判断元素的时间戳是否已经超出时间窗口(Tw秒)，是则移除元素，比如Tw＝60，当前时间为20点30分15秒，时间戳在20点29分15秒之前的就在时间窗口之外，应该被移除。遍历完成后，判断剩余元素数量是否大于阈值Cm，是则返回false表示服务器异常，否则返回true表示可以继续请求服务器。

异常恢复检测：对于异常机器，分析器会将其对应的Entry从map和链表中移除，防止发生高频率的请求超时。在移除后，还需要有恢复机制，保证那些已经从异常中恢复的服务器可以继续被分配到流量。分析器会定时对异常机器发出多个探测请求，例如，大于等于3次的探测请求，如果探测请求都正常响应，则认为该服务器恢复正常，执行初始化时的Entry插入逻辑，time为初始值0。

sliceWindow中的链表何时销毁：通常情况下，超时的概率会比较低，多数时间sliceWindow中的链表并不会发生插入操作，链表中就很可能维持着无用元素并且得不到释放。为了减小内存压力，分析器会定时扫描所有链表的尾节点，如果节点中的时间戳在当前时间3倍的窗口期之前，就会销毁该链表，回收内存，比如Tw＝60，当前时间为20点30分15秒，尾节点时间戳在20点27分15秒之前，表示该服务器已经超过3分钟没有发生超时了，就认为链表没有继续存在的意义了，可以被销毁掉。

服务器端在收到负载均衡器发来的请求后，执行以下步骤：

步骤S61，服务器的请求入口为Proxy，Proxy分担了一部分原来由负载均衡器承担的计算职责，目的就是减轻负载均衡器的压力。Proxy维护一个服务器请求相关的数据结构(reqNode)，如图8C所示，reqNode中包括：总请求数、总响应时间和堆积请求数。在Proxy收到负载均衡器发来的请求后，Proxy记录请求起始时间，然后调用后台服务。

这里，Proxy记录的请求起始时间用于计算请求的响应时间。

步骤S62，后台服务处理完请求后，响应给(设响应为result)Proxy，Proxy计算本次调用耗时(设为Ti)，然后修改reqNode中的属性值(总请求数+1，总响应时间+Ti)，然后算出平均响应时间，结合堆积请求数算出下次请求的响应时间预测值(设为Tn)。最后，Proxy组装扩展协议报文，将后台服务执行结果result和响应时间预测值Tn放入报文中，报文的结构如图8D，返回给负载均衡器。

比较相关技术与本申请实施例的负载均衡器CPU消耗量，得到：

CPU消耗量＝进程占用的CPU时间；

其中，CPU时间可以用CPU时钟周期数来衡量，根据常见操作消耗的CPU时钟周期对照表，本申请实施例中涉及到的操作与消耗的CPU时钟周期数对应关系如下：

CAS:15～30，均值为22.5；

整数除法:12～44，均值为28；

整数乘法:3～6，均值为4.5；

加减法:<1，近似值为1；

两值比较:<1，近似值为1。

其中，均值和近似值仅仅是为了方便后续的计算和比较，不影响结论的准确性。

两种方案负载均衡器每次正常请求前后的主要计算逻辑对照表1为：

表1负载均衡器计算逻辑

设后台服务器数量为n，设CAS修改的平均并发度为m(负载均衡器上，针对一个要CAS修改的数值，同时会有m个CAS请求)

消耗的时钟周期数计算结果用x1，x2..，y1，y2..表示。

相关技术中消耗的CPU时钟周期数计算：

1)两次CAS修改操作：由于CAS修改可能会失败(多线程并发CAS修改同一个对象时)，程序会不断重试直到成功为止，所以CAS修改消耗的CPU时钟周期取决于并发度(m)，x1消耗的CPU时钟周期数根据公式(2)计算，公式(2)为：

x1＝2*m*22.5＝m*45 (2)；

2)遍历计算(响应时间预测值)：遍历n次，每次执行:堆积请求数*(总请求数-超时请求数)/(总响应时间-超时响应时间)，分别是两次减法，一次除法，一次乘法，x2消耗的CPU时钟周期数根据公式(3)计算，公式(3)为：

x2＝n*(2*1+28+4.5)＝n*34.5 (3)；

比较最值：n个数比较最值，需比较n-1次，即，x3＝n-1；

相关技术中消耗的CPU时钟周期数总和根据公式(4)计算，公式(3)为：

x＝x1+x2+x3＝n*34.5+n-1+m*45＝n*35.5+m*45-1 (4)；

本申请实施例消耗的CPU时钟周期数计算：

插入有序链表(n/2次比较)，即，y1＝1*n/2＝n/2；取出链表头元素，y2＝1本申请实施例消耗的CPU时钟周期数总和：y＝y1+y2＝n/2+1，由此，对比两种方案消耗的CPU时钟周期数可得出如下结论：

1.相关技术中的消耗与后台服务器数量、并发度线性相关，即后台服务器数量越多则消耗越高，并发度越高则消耗越高

2.本申请实施例的CPU消耗与本申请实施例的CPU消耗的比值为：

x/y＝(n*35.5+m*45-1)/(n/2+1)＝(n*35.5)/(n/2+1)+(m*45-1)/(n/2+1)其中n和m都是>＝1的正整数，所以(m*45-1)/(n/2+1)一定>0、并且(n*35.5)/(n/2+1)在n＝1时最小(23.666..)，n越大该项值越接近35.5*2＝71，因此，本申请实施例的CPU消耗远小于相关技术中。

需要说明的是：本申请实施例中，与后台服务器数量相关的CPU消耗量都用在了响应时间预测值的计算上，在本申请实施例中，这部分计算依然要进行，只不过被分摊到每个后台服务器上，因此减少了负载均衡器的CPU消耗。

基于前述的实施例，本申请实施例提供一种负载均衡装置，负载均衡装置在实施的过程中可以为图7A中的负载均衡器中的分析器，该装置包括所包括的各模块、以及各模块所包括的各子模块，可以通过负载均衡设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图9A为本申请实施例负载均衡装置的组成结构示意图，如图9A所示，所述装置900A包括第一确定模块901、第二确定模块902、第一接收模块903和更新模块904，其中：

第一确定模块901，用于基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

第二确定模块902，用于从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

第一接收模块903，用于接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

第一更新模块904，用于将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

在一些实施例中，所述装置还包括第三确定模块、第二接收模块和第二更新模块，其中：第三确定模块，用于在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理；第二接收模块，用于接收所述第二目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；第二更新模块，用于将更新的响应时间预测值更新到所述第二目标元素中，并将所述执行结果发送给所述客户端。

在一些实施例中，所述第三确定模块包括建立子模块、去除子模块和第一确定子模块，其中：复制子模块，用于在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，建立所述数据结构的副本；删除子模块，用于从所述数据结构的副本中去除所述第一目标元素；第一确定子模块，用于从更新后的所述副本中将响应时间预测值最小的数据元素确定为第二目标元素。

在一些实施例中，所述装置还包括判定模块和移除模块，其中：判定模块，用于在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，调用滑动窗口的插入方法，判定所述第一目标服务器是否满足异常判定规则；移除模块，用于在所述第一目标服务器满足所述异常判定规则的情况下，从所述数据结构中移除所述第一目标服务器对应的第一目标元素，以在未判定所述第一目标服务器恢复处理请求功能前，不再向所述第一目标服务器发送请求。

在一些实施例中，所述异常判定规则包括在预设的时间窗口请求超时次数大于预设的次数阈值；所述判定模块，包括获取子模块、第二确定子模块和判断子模块，其中：获取子模块，用于获取所述第一目标服务器的滑动窗口数据结构；所述滑动窗口数据结构中元素的个数表征所述第一目标服务器发生超时的次数；第二确定子模块，用于基于所述预设的时间窗口，确定滑动窗口数据结构在所述预设的时间窗口内元素的个数；所述元素的个数表征所述第一目标服务器在预设窗口内发生超时的目标次数；判断子模块，用于判断所述目标次数是否大于所述预设的次数阈值，以判定所述第一目标服务器是否满足异常判定规则。

在一些实施例中，所述装置还包括第一插入模块，其中：第一插入模块，用于在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，向所述滑动窗口数据结构中插入元素；所述元素用于存储所述第一目标服务器超时请求的时间。

在一些实施例中，所述装置还包括定时模块和移除模块，其中：定时模块，用于定时扫描所述滑动窗口数据结构中的末尾元素；移除模块，用于在所述末尾元素发生超时请求的时间大于所述时间窗口的预设倍数的情况下，移除所述滑动窗口数据结构。

在一些实施例中，所述装置还包括第四确定模块、第二插入模块和发送模块，其中：第四确定模块，用于在基于所述URL请求中的URL，确定不到对应的数据结构的情况下，为所述URL初始化一对应的数据结构；第二插入模块，用于向所述数据结构中插入初始化数据元素，并对所述初始化元素的响应时间预测值进行初始化；发送模块，用于将所述URL请求发送给任一所述初始化数据元素对应的第一目标服务器的代理。

在一些实施例中，所述响应结果为扩展协议报文，所述接收所述第一目标服务器的代理返回的响应结果，所述第一接收模块903，还用于接收所述第一目标服务器的代理通过扩展协议返回的扩展协议报文，其中，所述扩展协议报文至少包括所述URL请求的执行结果和所述更新的响应时间预测值。

基于前述的实施例，本申请实施例提供一种负载均衡装置，负载均衡装置在实施的过程中可以为图7A中的后台服务器的代理，该装置包括所包括的各模块、以及各模块所包括的各子模块，可以通过后台服务器中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图9B为本申请实施例负载均衡装置的组成结构示意图，如图9B所示，所述装置900B包括第一发送模块910、更新模块920、确定模块930、封装模块940和第二发送模块950，其中：

第一发送模块910，用于接收负载均衡器的分析器发送的URL请求；

更新模块920，用于将当前URL请求的响应时间更新到所述第一目标服务器的响应节点数据结构；所述响应节点数据结构中包括：第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数；

确定模块930，用于根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值；

封装模块940，用于将所述更新的响应时间预测值和所述URL请求的执行结果封装成扩展协议报文；

第二发送模块950，用于将所述扩展协议报文作为响应结果发送给负载均衡器的分析器。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的负载均衡方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台负载均衡设备(可以是服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种负载均衡设备，包括存储器和处理器所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。

对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，图10为本申请实施例中负载均衡设备的一种硬件实体示意图，如图10所示，该负载均衡设备100的硬件实体包括：处理器1001、通信接口1002和存储器1003，其中

处理器1001通常控制负载均衡设备100的总体操作。

通信接口1002可以使负载均衡设备通过网络与其他终端或服务器通信。

存储器1003配置为存储由处理器1001可执行的指令和应用，还可以缓存待处理器1001以及负载均衡设备100中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

在一些实施例中，负载均衡设备可以为图7A中的负载均衡器；在另一个些实施例中，负载均衡设备可以为图7A中的后台服务器。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

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

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

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台负载均衡设备(可以是服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种负载均衡方法，其特征在于，所述方法包括：

基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

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

在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，并基于所述第二目标元素的服务器ID将所述URL请求发送给第二目标服务器的代理；

接收所述第二目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

将更新的响应时间预测值更新到所述第二目标元素中，并将所述执行结果发送给所述客户端。

3.根据权利要求2所述的方法，其特征在于，所述在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，从除所述第一目标元素之外的数据结构中，将响应时间预测值最小的数据元素确定为第二目标元素，包括：

在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，建立所述数据结构的副本；

从所述数据结构的副本中去除所述第一目标元素；

从更新后的所述副本中将响应时间预测值最小的数据元素确定为第二目标元素。

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

在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，调用滑动窗口的插入方法，判定所述第一目标服务器是否满足异常判定规则；

在所述第一目标服务器满足所述异常判定规则的情况下，从所述数据结构中移除所述第一目标服务器对应的第一目标元素，以在未判定所述第一目标服务器恢复处理请求功能前，不再向所述第一目标服务器发送请求。

5.根据权利要求4所述的方法，其特征在于，所述异常判定规则包括在预设的时间窗口请求超时次数大于预设的次数阈值；

所述调用滑动窗口的插入方法，判定所述第一目标服务器是否满足异常判定规则，包括：

获取所述第一目标服务器的滑动窗口数据结构；所述滑动窗口数据结构中元素的个数表征所述第一目标服务器发生超时的次数；

基于所述预设的时间窗口，确定滑动窗口数据结构在所述预设的时间窗口内元素的个数；所述元素的个数表征所述第一目标服务器在预设窗口内发生超时的目标次数；

判断所述目标次数是否大于所述预设的次数阈值，以判定所述第一目标服务器是否满足异常判定规则。

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

在超时未接收所述第一目标服务器的代理返回的响应结果的情况下，向所述滑动窗口数据结构中插入元素；所述元素用于存储所述第一目标服务器超时请求的时间。

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

定时扫描所述滑动窗口数据结构中的末尾元素；

在所述末尾元素发生超时请求的时间大于所述时间窗口的预设倍数的情况下，移除所述滑动窗口数据结构。

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

在基于所述URL请求中的URL，确定不到对应的数据结构的情况下，为所述URL初始化一对应的数据结构；

向所述数据结构中插入初始化数据元素，并对所述初始化元素的响应时间预测值进行初始化；

将所述URL请求发送给任一所述初始化数据元素对应的第一目标服务器的代理。

9.根据权利要求1至7任一项所述的方法，其特征在于，所述响应结果为扩展协议报文，所述接收所述第一目标服务器的代理返回的响应结果，包括：

接收所述第一目标服务器的代理通过扩展协议返回的扩展协议报文，其中，所述扩展协议报文至少包括所述URL请求的执行结果和所述更新的响应时间预测值。

10.一种负载均衡方法，其特征在于，所述方法包括：

第一目标服务器的代理接收负载均衡器的分析器发送的URL请求；

将当前URL请求的响应时间更新到所述第一目标服务器的响应节点数据结构；所述响应节点数据结构中包括：第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数；

根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值；

将所述更新的响应时间预测值和所述URL请求的执行结果封装成扩展协议报文；

将所述扩展协议报文作为响应结果发送给负载均衡器的分析器。

11.一种负载均衡装置，其特征在于，所述装置包括：

第一确定模块，用于基于客户端发送的URL请求中的URL，确定对应的数据结构；所述数据结构中的数据元素至少包括响应时间预测值和服务器ID；

第二确定模块，用于从所述数据结构中将响应时间预测值最小的数据元素确定为第一目标元素，并基于所述第一目标元素的服务器ID将所述URL请求发送给第一目标服务器的代理；

第一接收模块，用于接收所述第一目标服务器的代理返回的响应结果，其中，所述响应结果中至少包括所述URL请求的执行结果和更新的响应时间预测值；

第一更新模块，用于将更新的响应时间预测值更新到所述第一目标元素中，并将所述执行结果发送给所述客户端。

12.一种负载均衡装置，其特征在于，所述装置包括：

第一发送模块，用于第一目标服务器的代理接收负载均衡器的分析器发送的URL请求；

更新模块，用于将当前URL请求的响应时间更新到所述第一目标服务器的响应节点数据结构；所述响应节点数据结构中包括：第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数；

确定模块，用于根据所述第一目标服务器的总请求数、第一目标服务器的总响应时间和第一目标服务器的堆积请求数，确定更新的响应时间预测值；

封装模块，用于将所述更新的响应时间预测值和所述URL请求的执行结果封装成扩展协议报文；

第二发送模块，用于将所述扩展协议报文作为响应结果发送给负载均衡器的分析器。

13.一种负载均衡设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至9任一项所述方法中的步骤，或实现权利要求10所述方法中的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至9任一项所述方法中的步骤，或实现权利要求10所述方法中的步骤。

Images