专利名称：任务调度的方法、系统和设备的制作方法
技术领域：
本发明涉及计算系统内的任务调度。具体地说，本发明涉及可以减少计算系统内请求丢弃量和贯彻服务质量(QoS)和服务等级协定(SLA)的任务调度的方法、系统和设备。
背景技术：
计算系统可以定义为一个具有存储和处理能力的执行各种任务和处理各种请求的系统。这样的请求的范围可以是从诸如通过一个网络访问一个数据库之类的简单的数据请求到诸如运行一个应用，接着又需要一些数据(在数据库中的)来处理原始请求的较为复杂的请求。
任何接收请求(或任务)予以处理的计算系统在它的能力上都有一定限制。它同时可处理的请求的数量有一个上限。这样的限制可以是由于计算系统的结构和能力引起的。因此，诸如CPU速度、存储器容量、系统所布置的网络的连接速度之类的参数限制了系统可以处置的请求的数目。因此，如果请求数超过这个限制，将有某些请求得不到完全处理。会有一些请求将在到达计算系统前被丢弃，这些请求根本不会被计算系统接收。此外，会有一些请求被计算系统接收，但是这些请求将只得到部分处理就被异常中止了。这通常是由于存储器不足或网络连接超时而引起的。
这样的系统的一个例子可以是基于因特网的在线股票交易业务。这种业务根据用户请求为用户提供一些具体股票的价格的信息。然而，随着这样的在线因特网业务的用户越来越多，在线因特网业务的服务器同时处理的大量用户请求常常成为难以管理的。例如，提供篮球专门信息的在线因特网业务的服务器在国家级篮球锦标赛的决赛期间对于用户的请求过载。确实，由于请求过载会有一些用户请求将只得到部分处理，而有一些请求根本得不到处理。这些没有完全处理或者根本没有处理的请求也被认为是丢弃的请求。
在完全处理请求本身是关键性的任何事务未得到处理的情况下，就认为请求被丢弃。假设一个请求A的部分处理产生的一个请求B对于请求A的完全处理是关键性的。然而，如果请求B被丢弃(例如，由于加到处理请求B的部件上的请求过载)，请求A就不能得到完全处理。在这种情况下，也认为请求A是被丢弃了。
因此，概括地说，一个请求被认为是丢弃了，如果(i)这个请求在被系统或一个系统部件部分处理或完全处理前，由于这个部件上请求过载而不予考虑任何将来的处理(即完全丢弃)；(ii)任何对于完全处理这个请求是关键性的事务被异常中止；(iii)处理原来的请求产生的另一个请求被丢弃，该另一个请求得到完全处理对于完全处理原来的请求是关键性的。
一种解决由于过载而请求被丢弃的问题的方法是使用多个完全一样的系统(即多个同样的服务器)来处理进入的请求。因此，可以用一个服务器群集而不是一个服务器来处理请求。在这群集前面用一个负荷平衡器来接收请求和确保在这些同样的服务器之间公平地分配请求。负荷平衡器是硬件装置或软件程序，在群集内各个部件之间均匀地分配用户请求，以防止部件过载。例如，可以用一个负荷平衡器在若干同样的服务器(诸如http 1服务器)之间分配用户请求。这种分配可以基于预先规定的准则，诸如每个部件的工作负荷、请求内容类型(视频或文本)、部件地理位置和预期QoS和SLA之类。此外，可以预先规定如稍后将要讨论的在一些同样的部件之间分配这些请求的方法/技术。
由于运用多个同样的服务器，就会减少每个服务器处理的请求的数量。从而就减小了一个服务器过载的可能性。然而，在某些情况下请求可以多到为了满足要求要用多到不切实际的服务器。随着网络传输速度的提高和用户/客户的增多，通过网络传输请求比一个部件处理请求的速度和/或一个负荷平衡器转发请求的速度快得多。这导致一些请求累积在部件/负荷平衡器处，从而使部件/负荷平衡器过载。这引起一些请求在部件/负荷平衡器处被丢弃。在一些其他情况下，一个部件开始处理一个请求，但是由于处在高负荷的状态，在一个预定周期内不能完成处理。这也可以引起请求丢弃。
请求丢弃有害地影响了计算系统的性能。首先，浪费了资源，处理和转发请求的负荷平衡器的资源和/或部分处理请求所用的资源。这导致降低了资源有效利用率。第二，一个请求一得到处理就可能导致在一些部件(处理这个请求的部件)内状态改变。如果请求在一个中间部件被丢弃，系统就可能必需转回到它最近的一致状态。也就是说，整个系统必需转返到开始处理这个丢弃的请求之前所处的状态。每次转返都会使系统处理请求的响应时间恶化、降低系统的吞吐量，从而也浪费了系统的资源。第三，浪费系统资源可能导致丢弃其他请求，这些请求如果有充足的系统资源可用可能已经得到处理。第四，由于与以上所陈述的相同的原因，一些其他请求会以较低的服务质量处理，否则的话这些请求就可能以较高的服务质量处理。第五，部分处理一个以后被丢弃的请求所浪费的时间增加了对丢弃的或失败的请求的用户的响应时间。这可能有碍于为用户提供的服务质量(QoS)，也可能导致违反用户与网络之间的服务等级协定(SLA)。最后，由于处理请求的响应时间较长，用户不满意增加。
考虑到上述请求丢弃的缺点，势在必行的是减少请求丢弃量。有若干方法和技术用负荷平衡器来减少请求丢弃。一种由一个负荷平衡器执行用户请求分配的典型方法为轮转域名服务器(RR-DNS)方法。在这种方法中，请求按循环一个接一个发送给多个服务器(也就是说按轮转方式)。
有一些其他负荷平衡解决方案，基于在一个群集内的各个同样的部件之间的信息流的构思，以便为一个特定的用户请求确定目标部件。这信息可以是与群集内每个正由负荷平衡器平衡负荷的部件的负荷程度有关的信息。
在美国专利No.5938732“网络业务的负荷平衡和故障转移”(“Loadbalancing and fail over of network services”)揭示了一种这样的解决方案。它涉及维护在一个具有一些部件的群集内的通信和协调这些部件之间的合作。这样保证了由这个群集提供的服务即使在提供该服务的一个或多个部件有时诸如由于故障而无法使用时仍保持可提供服务。每个处理单元周期性地向群集内所有的其他处理单元发送一个有助于维护通信的控制信号。这个消息包括发送部件的状态以及有关所了解的群集内其他部件的状态的数据。
Myongsu Choe和Carl Tropper在研究报告“时间翘曲的流量控制和动态负荷平衡”(“Flow Control and Dynamic Load Balancing in TimeWarp”)提出了另一种解决方案。它揭示了一种综合流量控制和动态负荷平衡的算法。流量控制由一个群集(具有一些处理器)内的处理器用来在它们之间均分或分配负荷。流量控制在这种情况下在这些目标部件之间进行。Ossama Othman、Carlos O′Ryan和Douglas C.Schmidt的研究报告“自适应CORBA负荷平衡服务的设计和性能”(“The Design and Performanceof an Adaptive CORBA Load Balancing Service”)也提出了一种解决方案。该报告，在它的前景工作中，提出需要在各负荷平衡器之间采用流量控制，从一个给定的群集(具有一些部件)中确定目标部件。
上述所有的解决方案都采用了在一个群集(具有一些同样的部件)内的各个部件之间的信息交流来确定要处理请求的目标部件。然而，其中还没有一个考虑在要以高请求速率工作的系统内请求丢弃的问题。也要处理一些在完成前最终被丢弃的请求，这导致资源的浪费和增加了处理时间和功率消耗。这使系统效率降低。这些解决方案具有上面已经说明的通常的请求丢弃的缺点。
因此，从以上讨论来看，需要有一种可以减少在一个计算系统内请求丢弃的系统和方法。具体地说，需要有一种减少在负荷平衡器上丢弃请求的系统和方法。还需要有一种便于在负荷平衡器上贯彻服务质量(QoS)和服务等级协定(SLA)的系统和方法。也需要有一种增加系统吞吐量的负荷平衡设备。这是减少系统资源浪费所需要的。
发明内容
本发明的一个目的是调度一个计算系统内的请求。
本发明的具体目的是减少在计算系统的中间部件和负荷平衡器被丢弃的请求。
本发明的另一个具体目的是贯彻服务质量(QoS)和服务等级协定(SLA)。
本发明的另一个具体目的是提供一种在一个负荷平衡器内处理流量控制消息和贯彻QoS/SLA的系统和方法。
本发明的另一个具体目的是增加负荷平衡器和系统的请求吞吐量。
本发明的又一个目的是使系统资源有效利用率最大。
本发明的又一个目的是提供请求的有别分配。
本发明的又一个目的是大大减少系统的转返次数。
本发明的又一个目的是减少对用户的响应时间。
本发明的这些及其他一些目的由在一组同样的部件之间平衡负荷的方法、系统和计算机程序产品来实现。这方法旨在根据所执行的策略调度(来到一个计算机系统的)请求。这个计算系统包括多个级，每个级有至少一个队列，每个队列有至少一个缓冲器，而每个队列与至少一个处理部件有关。每个队列也可以对应于任何个(零个或多个)与之关联的群集。进入的请求在完全得到处理前经过一级或多级处理。在两级之间交换流量控制信息，以便减少请求丢弃。在本发明的一个实施例中，说明了在一个负荷平衡器内实现以上方法的情况。进入的请求存储在一个第一级队列内。请求再根据用户规定的参数(诸如QoS/SLA之类)分为多个类别。然后，请求根据预先规定的准则转发给多个第二级队列中的一个队列。例如，每个第二级队列可以与一个请求类别相对应。在两级队列之间存在有控制信息流。这个控制信息用来根据第二级队列的状态将一个请求转发给一个适当的第二级队列，从而减少在负荷平衡器内丢弃的请求。
在本发明的另一个实施例中，上面提到的负荷平衡器可在一个设备内用来动态平衡多个群集之间的负荷。进入的请求在第一级负荷平衡器接收。负荷平衡器根据请求的类型和/或目标部件的状态将一个请求或若干个请求同时分发给一些目标部件。一个负荷平衡器在它检测到将要有一个请求丢弃时产生流量控制消息，发送给前级负荷平衡器。在接收到一个流量控制消息时，一个负荷平衡器可以决定采取一些补偿措施以避免在以后一些级请求丢弃。负荷平衡器还可以产生可以与它的前级和下级负荷平衡器交换的流量控制消息。
以下将结合附图对本发明的优选实施例进行说明，这些附图只是例示性的，并不对本发明有所限制，其中同样的标识所表示的是同样的组成部分。在这些附图中图1示出了按照本发明的一个优选实施例处理请求的计算系统的例子；图2为按照本发明的优选实施例处理一个请求需遵循的一系列步骤的例子；图3为示出了一个例示效用值(utility value)计算的表；图4示出了在修改了负荷平衡器的请求分发速率后请求成为可通过的示范性情况中一系列步骤；图5例示了一个基于信息流思想减少请求丢弃的协作负荷分配器(CLD)的整个系统的体系结构；图6示出了基于如图5所示的CLD之间的信息流思想的协作负荷平衡设备；以及图7示出了基于负荷平衡器之间的信息流思想的另一个协作负荷平衡设备。
具体实施例方式
所用术语逻辑实例一个逻辑实例是一个物理实例/部件或一个物理实例/部件的某种能力。一个逻辑实例可以由一对物理实例的名称/地址和在物理实例内所配置的能力表示。在本申请中所谓“实例”和“复制件(replica)”都是“逻辑实例”的同义词。
群集一个群集是一些逻辑实例组成的集体，这些逻辑实例就所支持的功能、运用实例的协议等等而言是完全相同的。
下级负荷分配器LD-x的下级负荷分配器(LD)是一个与LD-x相邻的拓扑上是LD-x下一个的LD。例如，在图6中，LD 606和LD 608是LD 602的下级LD；LD 614是LD 606和LD 608的下级LD。
前级负荷分配器LD-x的前级负荷分配器(LD)是一个与LD-x相邻的拓扑上是LD-x前一个的LD。例如，在图6中LD 602是LD 606和LD 608的前级LD；LD 606和LD 608是LD 614的前级LD。
前端一个前端是由接收来自终端用户的请求的应用实例组成的一个群集。
请求分类因子(RCF)RCF用来将一个请求分类到一个类别(以区别于其他请求)。例如，本发明的一个实施例可以用与请求关联的用户身份或业务类别/等级或者用户ID和请求的业务类别的组合作为RCF对进入的请求分类。其他可用来计算RCF值的参数可以是请求类型(例如，目录查看请求，购物请求等)、请求的复杂性、请求的优先级等。
负荷监视器一个与系统或另一个部件C关联的部件M，可以监视在给定时刻的C的状态和/或加到C上的负荷。C的状态包括可用性、响应时间、CPU消耗量等。加到C上的负荷是对所消耗的C的容量或部署C的基础系统的容量的度量。
资源管理器一个能将资源从一个消耗方分配/释放给另一消耗方的部件R和/或与之关联的系统的规划能力。
本发明提供了一个使用流量控制技术大大减少请求丢弃的模型(系统和方法)。调度请求可以用现有的策略/技术执行。在本申请中，为了便于说明，用一个简单而常见的这样一种策略的例子进行说明转发具有高效用值的请求，一个请求的效用值由请求完全得到处理的概率和请求的优先级(也称为请求类别)确定。这个例子稍后将结合图3详细说明。对于熟悉该技术领域的人员来说显而易见的是为了减少请求丢弃有许多这样的策略可以实现/遵循。
图1示出了按照本发明的一个优选实施例处理请求的计算系统100。系统100可以有一个或多个级，每个级有一个或多个队列。每个级的队列还可以有一个或多个缓冲器和一个或多个与之关联的处理功能。为了便于说明，图1只例示了计算系统的两个级(即108和112)。此外，为了便于说明，图1示出了每个级其中只有一个队列(即102和110)。而且，每个队列示为只有一个缓器(即104和122)。
概括地说，一个请求在系统100内是这样处理的队列102包括一个缓冲器104和一个与之关联的处理功能106。队列102内的缓冲器104接收进入的请求和将这些进入的请求转发给处理功能106。处理功能106可以是一个请求分发功能(用来分发请求)或请求分类功能(用来对请求分类)。为了便于说明，图1所示的队列102，其中的处理功能106是一个请求分发功能。一个队列可以有任意个与之关联的群集。按需要，队列也可以没有任何与之关联的群集。在这种情况下，一个队列可以后面有另一个队列，而只有最后一个队列有一个与之关联的群集。这个群集包括一些执行同等任务的部件实例。为了便于说明，图1示出了与一个群集108关联的队列102，这个群集实际上是一个有一些履行请求执行功能的部件的群集。请求分发功能将请求分发给群集108，群集108再对请求进行处理后转发给下级队列110。每个队列最好还包括一个与前级/下级队列交换过程控制/流量控制消息的交换模块116、一个实现流量控制消息的指令的实现模块118和检测什么时候产生和发送控制/流量控制信号的检测模块120。注意，这样一个模型的实施可以不一定要有所有分得很清楚的三个模块。例如，一种实现可以只有一个模块，它执行所有三个模块的功能。然而，在任何实现中都必须执行所有三个模块的功能。本申请中稍后将详细说明这些模块的运用情况。队列110也有一个缓冲器和一个请求分发功能。请求分发功能将请求分发给一个与队列110关联的群集112。群集112的部件适当地处理请求。注意，可以有这样一种情况，将请求从群集112转发给一个以上的队列，这取决于请求的处理要求。该信息(有关处理要求的信息)可以存储在请求的头标内，因此由群集112的部件处理，以便确定目标队列。
在所揭示的这个系统中，在不同的级的队列之间存在信息(消息)流。也就是说，队列102和110交换信息114。如已经提到的那样，这两个队列的交换模块交换信息114，以便使队列102可以根据某种准则采取一些减少请求丢弃的补偿措施。缓冲器管理策略可用来完全或部分地执行补偿措施。为了例示，以下说明缓冲器管理策略的一个简单例子。
缓冲器管理策略的一个例子如下。请求被分类(或分发)并且按FCFS(先到先服务)转发到下一级。队列根据流量控制信息确定一个请求在下级队列的留存概率。在一个级内的每个队列都能向它的前级队列发送流量控制信号和向它的下级队列发送控制信号。该信息可以是相当于请求在队列内留存概率的负荷信息。利用这个概率和请求的优先级，确定请求的效用值(这将结合图3详细说明)。如果进入的请求数超过队列的请求处理能力，队列可以决定接收效用值较高的请求而丢弃其他请求。也可以将一些不能转发给下一级队列的请求组织在一个散列表内，使得这些请求在下级队列有条件接收请求时就转发。
为了减少请求丢弃，一个队列可以执行若干补偿措施。这些补偿措施将结合图2详细说明。这些补偿措施由实现模块118执行，从而使得请求丢弃明显减少。此外，在本发明的一个优选实施例中，这些措施可以导致严格地执行QoS/SLA标准。
图2为例示按照本发明的一个优选实施例处理一个请求需遵循的一系列步骤的流程图。应指出的是，在以下说明中所举的一个请求的效用值的例子只是例示本发明的一个优选实施例的工作情况。以下说明无论如何也不应被认为是什么限制。
在步骤202，队列102接收到请求后将它存储在一个缓冲器内。在步骤204，队列102的交换模块116接收到有关队列110的负荷从而也是有关群集112的负荷的信息114。在步骤206，队列102的实现模块118根据信息114以及按需要还根据与请求有关的信息(可以是存储在请求头标内的信息)计算出将请求转发给群集110的“效用值”。为了便于说明，假设效用值取决于请求完成的概率，而这概率又取决于下级队列和群集的负荷。下级队列和相应的群集的负荷越重，请求完成的概率越低，因此请求的效用值也就越低。这是因为如果队列102转发一个完成概率低的请求(例如为0.05)，它就要占用队列102的处理时间和系统资源。很可能这个请求随后(在队列110)就要被丢弃(概率为0.95)，从而浪费了系统的资源和时间。效用值也可以根据请求的类别确定。例如，转发一个QoS/SLA为黄金等级的请求在商业上比转发一个QoS/SLA为青铜等级的请求更为有益。对于熟悉该技术领域的人员来说，可以引进许多其他因素来确定请求的效用值是显而易见的。然而，为了便于说明，这里将请求的效用值限制在包括可以用信息114计算的它的完成概率和可以从请求分组的头标中得到的请求类别。按照这个例示计算效用值的情况将结合图3以一个例子详细说明。
在步骤208，将计算得到的请求的效用值与已为队列102指配的门限效用值相比较。为每个队列计算和指配一个门限效用值。这个门限值对于一个特定的队列是固定的。这个门限值的计算利用了有关所估计的下级队列和相应各群集的负荷的信息和考虑到这个队列需处理的请求的类别。这个值在系统内相继按比例增大或减小，或者依据队列需处理的请求的类别的改变而改变。
如果计算得到的效用值大于门限效用值，于是在步骤210，队列102的处理功能106对这个请求进行处理(分发或分类)。然而，如果计算得到的效用值小于门限效用值，于是在步骤212，队列102的检测模块计算出一个经修改的请求效用值。这个经修改的效用值是在假设队列采取一些补偿措施(以提高请求效用值)后计算出来的。这个值基于采取补偿措施的代价。这代价又主要取决于采取补偿措施时存储器的消耗量和处理能力的使用率。这个效用值也可以基于在已将补偿措施也作为请求的类别后完成请求的概率。
队列所采取的补偿措施可以有以下一些方面。首先，队列的检测模块可以发送一些控制信号，以改变它的请求分发速率，使得加到下一级队列和相应的群集的负荷达到一个最佳程度。如果请求早先由于下一级队列的过载而具有低的效用值，这些控制信号将减少负荷，从而提高完成这个请求的概率。这又导致增大请求的效用值。与这个措施关联的代价一般在这个措施可以只涉及执行一个小型的代码时是很低的。因此，经修改的请求效用值通常高于原来的请求效用值(由于增大了完成概率)。涉及采取这个措施的这些步骤将结合图4详细说明。在步骤214，将经修改的效用值与经修改的门限效用值相比较。注意，经修改的门限效用值在没有执行按比例增大的情况下(即如果不执行第二个措施)与原来的门限效用值相同。如果经修改的效用值小于经修改的门限值，就在步骤216，丢弃这个请求。否则，在步骤218，采取在步骤212假设的补偿措施后，由队列将请求分发给它的群集，在步骤220经适当处理后可以转发给下一级。
为了更清楚地例示效用值、门限效用值、经修改的效用值和经修改的门限效用值，来看图3所示的这个表。注意，所说明的情况只是例示性的，并不是对本发明有所限制。为了简明起见，所举的是个很简单的计算效用值的方法的例子将留存概率(在0至1之间)乘以QoS等级(对于青铜级请求为1，对于白银级请求为2，而对于黄金级请求为3)。因此，留存概率为0.75的(青铜级)请求A它的效用值将为0.75*1＝0.75。这个请求由于它的效用值超过门限效用值(对于这个队列为0.5)将被队列分发。类似，图3中的请求B也将被分发。然而，效用值为0.48的请求C(完成概率为0.16的黄金级请求(QoS＝3))由于门限效用值较高(＝0.5)不会被转发。通过假设采取了改变负荷平衡器的分发速率的补偿措施计算经修改的门限效用值。这个补偿措施的步骤如图4所示。请求C’是经修改的请求。图3示出了如果采取修改分发速率的补偿措施，完成概率就上升到0.20。然而，有一个与这个措施关联的代价因子(例如为0.9)。因此，请求C’的经修改的效用值为0.2*3*0.9＝0.54，大于门限效用值0.5。这样，采取这个补偿措施可以增大请求C的效用值，从而排除了必须丢弃请求C。
仍然来看图3，考虑请求D(完成概率＝0.4，QoS等级＝1(青铜))的情况。即使假设采取了第一个措施后，经修改的效用值(0.45)仍没有超过门限效用值。然而，假设采取第二个措施(按比例增大)。与这个措施关联的代价(乘法因子为0.8)比与第一个措施关联的(乘法因子为0.9)高。因此，经修改的效用值为0.6*1*0.8＝0.48。但是，在这种情况下，门限效用值也降低(由于按比例增大)到0.45。这样，如果采取第二个补偿措施，请求D就可以通过。然而，可以存在诸如请求E那样的请求，即使采取了这两个补偿措施仍没有通过。这样的请求就由系统丢弃。
图4示出了在一个例示性的情况中的一系列步骤，队列体现在一个负荷平衡器内，请求在负荷平衡器的分发速率修改后成为可通过的。同样，有许多方式可以使请求成为可通过的，以下说明例示了其中一种可能的方式。在这个措施中所用的信息包括有关加到下级负荷平衡器和它们相应的群集上的负荷的信息。在步骤402，队列接收到一个为特定的请求类别r的请求。在步骤404，队列的交换模块接收到有关对于请求类别r的请求的当前进入速率、对于请求类别r的预期请求进入速率和来自下级负荷平衡器的对于请求类别r的当前请求分发速率的信息。完成请求的概率通过队列的实现模块对所接收的信息的处理来确定。该概率可以以若干方式计算。计算该概率的一种典型方式将结合步骤410进行说明。
在步骤406，队列收集有关请求类别的信息。该信息最好存储在进入的请求的头标内。请求的QoS/SLA等级可以是请求类别的这样一个例子。一个简单的实现例子可以是对于黄金级请求指定值为3，对于白银级请求为2，而对于青铜级请求为1。在步骤408，队列根据在步骤404和406收集到的信息计算请求的效用值。同样，如已经提到的那样，可以有若干方式由队列利用这信息得到效用值。如所说明的那样，一个简单的例子是将完成概率与请求类别等级相乘。因此，如果下一级负荷平衡器的负荷是75％(完成概率＝0.25)，于是一个青铜级请求的效用值为0.25(而一个黄金级请求和一个白银级请求的效用值分别为0.75和0.5)。
假设，青铜级请求的效用值小于门限效用值。在这种情况下，通过假设改变队列的请求分发速率，计算经修改的效用值。在步骤410，由队列的实现模块利用收集到的信息计算请求分发速率的改变。可以利用任何技术计算分发速率。下面是一个简单的例示性方式，根据具体请求类别的留存概率计算分发速率的改变。(这个例子没有考虑请求的优先级(请求类别)。熟悉该技术领域的人员很清楚，有若干方式可以在考虑或不考虑请求类别的情况下计算分发速率。)最后，以在步骤412计算出的新的请求分发速率分发请求。
考虑一个队列Q-m，具有如Q＝{Q2，Q3，Q4，...Q-k}那样的一些前级队列。如果Q-m缓存超过对于一个请求类别r缓存的临界值(例如为缓冲器充满的95％)，于是队列Q-m决定产生一个给Q内各队列的流量控制消息。流量控制消息包括在Q-m对于类别r的进入请求速率Rrm。预期的进入速率为Erm。接收队列Q-k对消息进行处理后决定校正它的分发速率。Q-k实现的措施是降低分发速率。计算最终分发速率drk所用的算式的一个例子可以如下设Drk为来自CLD-k的类别r的请求的当前分发速率。
该成分与进入速率之比为C＝Drk/Rrm。
分发速率的改变为zrk＝C*(Erm-Rrm)。
新的分发速率为drk＝Drk+zrk。
如果drk＜Drk，Q-k就将对于请求类别r的分发速率降低到drk。这是通过在每个请求后添加分发延迟以实现新的分发速率来达到的。
所揭示的模型(系统和方法)还具有根据一些预先规定的参数(诸如服务质量/服务等级协定(QoS/SLA)之类)对请求进行分类和处理的能力。采用本发明可以显著地减少在一个系统内发生的请求丢弃。此外，由于减少了一个请求在一个计算系统内的中间部件被丢弃的可能性，系统资源的利用就有效得多。本发明的一个实施例还保证贯彻严格的服务质量/服务等级协定(QoS/SLA)，从而改善了服务质量。这保证了较快地对用户请求作出响应。
上面所说明的系统的硬件实现可以以下面的方式实现。每个队列可以由一个集成电路实现。缓冲器可以用DRAM技术或用以实现使存储操作更快的超高速缓冲存储器的技术实现。处理流量控制消息的子部件可以也包括一个微处理器、一个存储器和一个通信处理器。处理功能也可以实现为一个具有一些存储器和一个通信处理器的微处理器。在缓冲器、处理功能部件和控制器之间有一些通信链路。每个子部件可以通过用于所要求的配置和性能的专门指令集来编程。
所说明的系统还可以具有软件实现，而这种软件实现可以在一个具有存储器和处理能力的计算设备上实现。每个部件可以用任何常见的编程语言(诸如C、C++或JAVA之类)写成的软件代码实现。这些软件代码利用计算设备的存储器和处理能力执行，以实现这些部件的各种功能。
上面提到的模型可以按一种协作负荷分配器(Cooperative LoadDistributor，CLD)体系结构实现，如将结合图5所说明的那样。这个模型也可以按一种协作负荷分配设备实现，这种设备使用了若干个这样的CLD(如图5所示)。这样的设备将结合图6进行详细说明。
实现1协作负荷分配器(CLD)上面所说明的模型的作为一个CLD的实现具有n级队列，其中n≥1。前(n-1)个级都没有与之关联的群集。这些级内每个队列的处理功能是一个请求分类功能。第n级每个队列有一个或多个群集，而该级的处理功能是请求分发功能。
上面所讨论的模型的实现现在通过一个例子予以说明。图5示出了一个协作负荷分配器(CLD)500的整个系统体系结构的一个例子。CLD 500包括两级队列；第一级队列(通用请求处理器(GRH)502)和第二级队列(专用请求处理器(SRH)504)。GRH 502没有任何与之关联的群集，而GRH 502的处理功能是请求分类功能(也称为请求分类器(RC))。RC根据请求分类因子(RCF)对请求分类，而请求分类因子可以取决于某些预定的参数(诸如基于服务的分类或基于用户的分类，如稍后将说明的那样)。有若干个象SRH504那样的SRH(第二级队列)，从GRH 502接收经分类的请求。这些SRH可以分别与各个请求类别对应。在所示这个例子中，每个SRH具有请求分发功能(也称为请求分发器(RD))。每个SRH可以有一个或多个群集，由它将请求分发给这些群集。注意，虽然本发明的这个CLD实施例是结合两级队列说明的，但也可以用多级队列。例如，在第二级队列可以对请求进行子分类。具有三级的负荷平衡器的一个典型实施例可以具有一个起全局缓冲器作用的第一级队列、若干个分别用于不同服务类别的第二级队列和若干个分别用于不同用户类别的第三级队列。
CLD 500具有一个请求分发管理器(RDM)506和一个负荷分配控制器(LDC)508，执行检测模块、交换模块和实现模块的功能。注意，在这个实现中，交换模块、检测模块和实现模块没有示为队列专用的，即每个队列并不具有这三个模块。而是在这个示范性CLD体系结构只有一个RDM和一个LDC，它们体现了这些模块的功能。RDM 506起着SRH 504的负荷状态的检测器的作用，而且使GRH 504和SRH 502之间可以交换消息。RDM 506在SRH达到接近充满状态(如稍后将详细说明的那样)时向GRH发送适当的消息。RDM 506还与负荷监视器(LM)交换信息，以便获得有关每个复制件的动态负荷信息。LDC 508接收其他CLD的消息，产生一些消息发送给其他CLD(如将结合图6说明的那样)。LDC 508还与资源管理器(RM)交换信息。
现在对CLD体系结构进行较为详细的说明。如结合图5所提到的那样，CLD 500具有以下部件通用请求处理器(GRH)502，请求分发管理器(RDM)506，专用请求处理器(SRH)504和负荷分配控制器(LDC)508。GRH502包括一个缓冲器、一个请求接收器和一个请求分类功能。RDM 506包括一些从LDC 508、GRH 502接收消息的接收器和向SRH 504、LDC 508和GRH 502发送消息的发送器。RDM 506使SRH 504和GRH 502之间可以交换消息510。它按需要还可以包括一个负荷接收器和一个用于负荷监视器的消息发送器。SRH 504包括一个请求接收器、一个称为第二级缓冲器(SLB)的缓冲器和一个请求分发功能。LDC 508包括一个根据一个新的请求类别或者根据群集容量等的任何改变动态地修改CLD的配置的模块。LDC 508还包括一个实现任何与QoS/SLA有关的智能的备选模块。例如，它可以根据每个QoS类别的缓冲器充满发生的频度、请求丢弃的速率等决定每个QoS类别的缓冲器的容量。
GRH 502是第一级队列，而一组SRH组成了第二级队列。SRH的个数取决于请求类别的个数。在一个优选实施例中，它们的个数等于请求类别的个数。GRH 502主要负责接收进入的请求，按需要可以根据请求合法性认证/任何其他规定的准则执行许可控制，接受请求后对每个请求分类和将请求发送给一个与请求的类别相应的SRH。每个SRH 504主要负责从GRH502接收请求，如果它的缓冲器没有充满就将请求缓存在它的缓冲器内，否则就有选择地丢弃请求(按照如前面对模型的说明中所说明的缓冲器管理策略)，然后根据所用的负荷平衡技术分发每个请求。GRH 502和RDM 506必须执行流量控制，以便实现GRH 502与每个SRH 504之间的流量控制。RDM 506负责执行对SRH 504和每个SRH 504的分发速率的管理。
在GRH 502接收到一个请求时，它检测它的缓冲器是否充满。如果它是充满的，LDC 508就命令GRH 502根据这个请求的效用值有选择地丢弃这个请求，否则就接受这个请求。如已经说明的那样，正在执行的缓冲器管理策略决定了根据请求的效用值处理请求的方式。处理请求的一个典型方式可以是队列可以接受效用值高于门限效用值的请求而丢弃其他请求。也可以将一些由于效用值低而不能转发给下级队列的请求组织在一个散列表内，使得这些请求在下级队列一准备好接收请求时就转发。接受请求后，GRH 502将请求缓存在通用请求缓冲器内。GRH 502的请求分类功能对缓冲器内的请求分类后根据它们的RCF将它们分发给各自恰当的SRH。为了对应用层请求分类(如果负荷平衡器进行的是应用层负荷平衡)，GRH 502的请求分类功能分析请求的请求头标，确定请求分类因子(RCF)。如果负荷平衡器进行的是网络层负荷平衡，GRH 502的请求分类功能就分析IP分组头标，得出它的优先级和/或其他信息(取决于所用的是哪种RCF)，从而确定RCF。
RCF可以由GRH 502计算。根据RCF，GRH 502检查下级与这个RCF值有关的缓冲器B的状态。如果SRH 504的缓冲器充满，GRH 502的缓冲器管理策略决定怎样处理这个请求。SRH 504还可以遵从LDC 508的命令，根据请求的效用值丢弃一些它所接收的请求。否则，在确定RCF后，GRH502的请求分类功能将请求移交给适当的SRH。
SRH 504缓存给队列的请求。同时，SRH的RD接收它的目标群集内每个复制件的负荷信息。如果负荷平衡技术是静态技术(例如轮转负荷平衡技术)，实际上并没有什么负荷信息是必需的。然而，如果它是动态负荷平衡技术，请求分发功能可以需要专用请求类别的群集(SRH所属群集)的每个复制件的负荷信息。该负荷信息是从负荷监视器接收的。注意，请求分发有两种可能第一，对于每个请求，获得目标群集内每个复制件的负荷信息，计算出相应的效用值。然而，在请求密度高的网络内，请求分发速率比获得异步流量控制消息的速率高得太多。在这种情况下，负荷信息在一个预先规定的基础上接收。例如，可以只在所涉及的群集内的一些复制件的负荷有明显改变时才接收该信息。请求分发速率在这种情况下根据可得到的负荷信息计算。只有在群集的负荷有明显改变时，才得到新的负荷信息，用来计算效用值。在所说明的实施例中已说明了前一种分发请求的方式。然而，熟悉该技术领域的人员显然清楚，也可以用后一种方式和许多其他方式达到这个目的，这并不背离本发明的精神实质和专利保护范围。
在一个优选实施例中，根据所接收的负荷信息，RD识别负荷最小的复制件和这个复制件是否具有积极的剩余能力，即这个复制件是否可以处理更多的请求。于是RD从缓冲器提取一个请求，将它分发给这个(负荷最小的)复制件。RD根据分发速率继续进行这样的分发。
每个SRH 504的RD根据所用的负荷平衡技术将请求分发给目标复制件(群集)。请求分发功能需要知道怎样将请求分发给一个目标复制件。由于所用的请求分发技术在网络层和应用层的负荷平衡上是不同的，因此请求分发功能也可以对于每种情况分别执行。对于应用负荷平衡情况，请求分发随着从一个应用到另一应用而改变，取决于每个应用所用的协议。因此，对于一个类别的应用将只有一种请求分发功能的实现。
由于GRH内的RC和SRH内的RD取决于CLD正在用于应用层负荷平衡还是用于网络层负荷平衡，因此它们可以实现为负荷平衡器的可插接部件。这样的可插接部件会由负荷平衡器在它的启动期间运用。这个部件对于应用层负荷平衡来说是与应用相关的。
RDM 506跟踪每个SRH 504内的负荷状态。在一个SRH成为接近充满(例如，75％充满，这可以由用户规定)时，RDM 506就向GRH 502发送一个流量控制消息。(接近充满状态总是小于或等于缓冲器的充满状态。接近充满状态在GRH 502执行流量控制时是有用的，GRH 502会已发出多了一些的对于专用请求类别的请求。)流量控制消息包括请求类别和这个请求类别的进入请求速率及其他。GRH 502可以停止转发请求或降低分发请求的速率，也可以采取前面结合模型说明的一些其他措施。在一个SRH状态从“接近充满”状态回到“没有接近充满”状态时，RDM 506向GRH 502发出一个有关状态改变的消息。GRH 502于是可以回到它的早先状态。在GRH 502的缓冲器成为接近充满、或者GRH 502知道一些SLB较为频繁地成为接近充满、或者GRH 502由于GRB充满或进入请求速率比分发给SRH504的速率高得多而丢弃一些请求、或者出现类似情况时，GRH 502就向LDC 508发送一个有关这种状态的控制消息。这个消息含有相应的数据，可以包括进入请求速率、请求分类速率、SRH的请求分发速率等。于是，LDC决定是否增加GRB/SLB的缓冲器容量和/或向前级负荷平衡器发送一个流量控制消息。
LDC 508一接收到对于一个请求类别r的流量控制消息，就决定要将r类的分发速率降低多少、要停止分发r类的请求多长时间、缓冲器(GRH的缓冲器和对于请求类别r的SRH的缓冲器)的容量要增大多少(以便处理由于前两个决定而要缓存的请求)。如果它不知道最新的对于r类的请求分发速率，它可以通过一个控制消息向RDM询问这个值。它将计算出这个值和它的决定，然后命令RDM贯彻最终的请求分发速率、需停止请求分发的时间和/或增大SLB容量。类似，如果有对于GRH 502的任何与此有关的指令，LDC 508就命令它。RDM 506按照指令控制SRH 504的分发速率。
RDM/GRH分别增大SLB/GRB的缓冲器容量，如果需要的话。GRH 502和RDM 506如果成功实现了这个指令就向LDC 508发送肯定确认，否则就向LDC 508发送否定确认。
由于资源管理器的消息或者由于某种其他原因(例如对抗SLB或GRB的频繁溢出)，LDC 508可以决定改变(提高/降低)任何缓冲器的容量。为了改变GRB的容量，LDC 508向GRH 502发出命令。GRH 502执行这个指令，在改变成功时发送一个肯定响应，否则发送一个否定响应。为了改变一个SLB的容量或改变一个SRH的分发速率，LDC 508向RDM 506发出命令，通知它对于这个专用请求类别所需采取的措施。RDM 506执行这个指令内的措施，在改变成功时发送一个肯定响应，否则发送一个否定响应。
在资源管理器添加一个新的请求类别r时，它就通知与这更新有关的CLD的LDC 508。该更新也包括可能的QoS/SLA参数和/或可能的最大请求速率。LDC命令RDM为r建立一个新的SRH，将r添加到它的请求类别表内。RDM建立一个具有规定的SLB容量(由LDC规定)的SRH。然后，RDM向LDC发送一个消息，报告建立SRH成功。如果RDM不能建立一个SRH，它就向LDC发送一个否定响应。从RDM一接收到肯定响应，LDC就命令GRH改变GRB容量和添加新的请求类别r。GRH通过增加GRB容量和更新它的请求类别表实现LDC的指令。GRH在成功完成时发送一个肯定确认。如果GRH失败，它就发送一个否定响应。
如果GRH/LDC/RDM有任何类型的故障不允许负荷平衡器有效地添加请求类别r，LDC可以向资源管理器发送一个否定响应。
对于删除一个请求类别r来说，情况类似，LDC向RDM发送一个删除相应的SRH的指令。RDM一接收到这样一个指令就向GRH发送一个控制消息，如“删除对于r类请求的SRH”。于是，GRH停止从外界再接收任何以后的r类请求，将所有的r类请求转发给SRH。然后，GRH向RDM发送一个确认。从GRH接收到确认后，RDM等到r类的SLB清空(再也没有请求需分发)后，删除SRH。然后，它向LDC发送一个确认。LDC于是命令GRH改变GRB的容量，在适当时候从它的记录中删除请求类别r。GRH改变GRB的容量，对表进行更新后向LDC发送一个肯定响应。从GRH和RDM都接收到肯定响应后，LDC就可以向RM发送一个“请求类别r已删除”的确认，如果需要的话。如果GRH/LDC/RDM有任何类型的故障不允许负荷平衡器有效地删除请求类别r，LDC可以向资源管理器发送一个否定响应。
每个请求类别的请求与其他请求类别的请求同时分发。虽然CLD采用并行分发，以便保证每次没有两个分发器同时将请求发送给同一个实例，但每个逻辑实例应只属于一个资源类别。可以回忆一下，一个逻辑实例是一个物理实例/复制件或一个群集内的一个物理实例/复制件的某种能力。例如，如果请求类别是黄金和白银类，一个逻辑实例就属于黄金类和白银类之一，而不是两者。
在另一个实施例中，对于这种体系结构还可以采用串行分发技术。与并行分发不同，串行分发可以用以下技术实现。撤消各个SRH的请求分发器。代替这些请求分发器，对于所有的请求类别就用一个请求分发器。这个请求分发器负责根据任何参数(例如，基于QoS/SLA的加权)在各个队列之间执行调度和一次分发一个请求。
在实现1中所说明的CLD用两级缓存来处理请求。在这两级缓冲器之间存在一个信息流。这有助于识别在第二级接受一个请求的概率。结果，一些具有低留存概率的请求在第一级就被丢弃，从而减少了系统资源(诸如存储器有效利用率和处理能力之类)的浪费。
CLD还执行对请求的有别负荷平衡，从而导致严格地贯彻QoS/SLA。
各个SRH直接将一个请求分发给目标部件。从而出现并行分发请求。请求在最后分发给目标部件前不会有必须通过的瓶颈。这就增大了CLD的吞吐量。
由于系统资源更为有效地得到利用，就减少了在CLD内丢弃的请求。于是，转发到第二级的请求只是那些具有高留存概率或者高转发效用的请求。这是通过这种CLD体系结构内的级间流量控制实现的。
实现CLD可以用面向对象的技术实现。例如，可以用C++实现这个系统。各个模块/实体都具有一个所关联的类别缓冲器、队列、GRH、SRH、LDC、RDM、RD。SLB和GRB都是缓冲器的子类。在这些类别之间用对象消息进行通信。一个CLD含有一些对于一个GRH、若干个SRH、一个RDM和一个LDC的对象。每个GRH含有一个对象GRB。每个SRH含有一个对于SLB和RD的对象。每个RDM具有与每个SRH关联的关系。每个LDC都含有一个前级负荷平衡器和下级负荷平衡器的表。RDM与负荷平衡器相关。
在另一种实现中，CLD是一个IC和/或一个逻辑电路，具有以下部件作为一个Intel x86微处理器的LDC，作为另一个Intel x86的微处理器的RDM，作为一个Intel x86的RD，包括用于GRB的DRAM存储器的GRH。SLB也实现为DRAM存储器。可以用标准的网络卡/接口作为接收请求和发送请求、传送流量控制消息的I/O。负荷平衡器之间的通信协议可以是TCP/IP。
实现2协作负荷平衡的设备结合图1说明的模型在一个多级处理系统(设备)内实现；每个在一个群集前面的负荷平衡器(调度器)可以模型化为一个队列。这样一个队列的处理功能是一种分发功能。与每个队列关联的可以有一个或多个群集。检测模块、实现模块和交换模块的功能由每个负荷平衡器(CLD 500)内的LDC508执行。如上面结合图5所说明的CLD 500用于如图6所示这样的多级处理系统(设备)。
现在简要地说明一下这个设备的使用环境。一个采用协作负荷平衡设备的集中式系统涉及一组这个系统的复制件。这些复制件受到对进入的请求的负荷平衡。一种采用协作负荷平衡设备的分布系统涉及一些由它的一些部件组成的群集。不是使用整个系统的复制件。使用的是一个部件的一些复制件的群集。每个群集含有一个部件的一些复制件。一个与一个群集关联的负荷平衡器在这个群集的这些复制件之间分配负荷。为了减少请求在中间群集上的丢弃，在各群集的负荷平衡器(图6)之间采用流量控制。
现在结合图6说明基于图1所示模型的协作负荷平衡设备的一个例子。注意，可以有许多不背离本发明的精神实质和专利保护范围的采用CLD500的协作负荷平衡设备的变型。
设备中所用的这些CLD都具有CLD 500的体系结构，以便执行检测模块、实现模块和交换模块的功能。这个例子中的设备包括CLD 602、CLD606、CLD 608和CLD 614(每个都具有CLD 500的系统体系结构)，它们分别将请求分配给群集604、群集610、群集612和群集616内的部件。在CLD606和CLD 602之间交换信息(或消息)618，而在CLD 608和CLD 602之间交换信息620。类似，在CLD 614和CLD 606之间交换信息622，而在CLD 614和CLD 608之间交换信息620。
一个给负荷平衡设备的请求加到CLD 602上，分配给群集604的前端部件之一。经前端部件处理后，请求可以转给CLD 606(控制服务器应用A的群集610)或CLD 608(控制服务器应用B的群集612)，这取决于请求的后续处理要求。这样处理后，请求送至CLD 614，由CLD 614将请求分配给群集616内的数据库之一，完成对请求的处理。请求流至各群集由CLD之间的信息流决定。
现在说明CLD 500用于以上所说明的协作负荷平衡设备的情况。如已说明的那样，每个CLD 500具有LDC 508，它使CLD 500可以产生消息和与设备内其他CLD交换消息。因此，在这个实现中，LDC 508起着检测模块和CLD 500(它起着一个队列的作用)的产生模块的作用。LDC 508还与负荷监示器(LM)交换信息。除了前面说明的模块/部件之外，LDC 508还包括一些接收来自各个部件和相邻的负荷平衡器和资源管理器的消息的接收器、一些向这样一些部件发送消息的发送器、一个在系统启动时对系统初始化的模块和一个在群集内任何动态修改后更新CLD记录的模块。它还具有一个根据一个新的请求类别或者根据本群集的请求处理能力的任何改变动态地修改CLD的配置的模块。总而言之，LDC 508负责管理整个LDC系统和各群集负荷平衡器之间的流量控制。
在GRH 502的缓冲器接近充满(例如由于前级CLD请求分发速率高)时，GRH向LDC发送一个有关这个状态的控制消息。这个消息含有相应的数据，可以包括请求进入速率、请求分类速率、请求分发速率等。于是，LDC决定是否增加GRB的缓冲器容量和/或向它的前级CLD发送一个流量控制消息。
LDC 508负责决定什么时候产生流量控制消息发送给它的前级负荷分配器。在GRH接近充满时，LDC可以向GRH发送一个流量控制消息。如果需要的话，GRH增加GRB的缓冲器容量。GRH在成功执行这个指令的情况下向LDC发出肯定确认，否则向LDC发出否定确认。成功执行一个流量控制指令后，LDC向它的所有下级分配器发送它对请求类别r的新的分发速率。这些CLD接收到消息后就更新它们的记录。
在对于请求类别r的群集内SLB的容量和某个实例的能力(就请求速率而言)有显著增大时，LDC就通知前级负荷平衡器有关容量和能力增大的情况、所反映的它在容量增大后可处理的最大请求速率、它当前对于r类的分发速率、它当前对于r类的请求进入速率等等。LDC只有在它最近已向它的前级用于请求类别r的负荷平衡器发送了流量控制消息的时候才进行通知。前级CLD的一个LDC一接收到这样一个消息，就计算它对于r类的请求分发速率的增量d可以是多少。然后，前级CLD的LDC命令GRH和/或RDM增加它分发r类的速率。
在资源管理器添加一个新的请求类别r时，它就通知与这更新有关的CLD的LDC。该更新也包括可能的QoS/SLA参数和/或可能的最大请求速率。类别r的请求速率，对于前端群集来说是在一个给定时刻来自请求类别r的所有终端用户的合计请求速率。但是一个前端群集内每个类别r的请求可以产生给下级群集的多于一个的请求。因此，对于每个群集来说，可能有不同的请求进入速率。LDC决定GRB容量的可能改变和对于r类的SLB的可能容量。LDC首先命令RDM使SLB适当改变(如前面所说明的那样)。从RDM一接收到肯定响应，LDC就命令GRH改变GRB容量和添加新的请求类别r。GRH通过增加GRB容量和更新它的请求类别表实现LDC的指令。GRH在成功完成时发送一个肯定确认，如果GRH失败，它就发送一个否定响应。
类似，对于删除一个请求类别r，LDC决定有关GRB容量的可能改变情况。它向RDM发送一个撤消适当SRH的指令。从RDM接收到肯定响应，LDC就命令GRH改变GRB的容量，在适当时候从它的记录中删除请求类别r。GRH改变GRB的容量，对表进行更新后向LDC发送一个肯定响应。从GRH和RDM都接收到肯定响应后，LDC就可以向RM发送一个“请求类别r已删除”的确认，如果需要的话。如果GRH/LDC/RDM有任何类型的故障不允许负荷平衡器有效地删除请求类别r，LDC可以向资源管理器发送一个否定响应，如果必要的话。
在另一个实施例中，也可以采用群集间负荷平衡器之间的集中流量控制(如图7所示)。在这个实施例中，不是每个CLD有一个LDC，而是可以有一个(或多个)集中LDC 702，以集中方式执行流量控制。这个集中LDC 702的重要功能包括流量控制。LDC的一些功能，包括实现资源管理器配置方案、命令RDM建立或删除一个RD、从GRH和RDM接收控制消息、在启动期间初始化CLD，可以由一个对每个负荷分配器来说是本地的实体(例如一个局部的LDC)执行。图7示出了相应的负荷平衡设备。
所提出的这种用于负荷平衡的设备便于按群集进行负荷平衡和在群集间负荷平衡器之间进行流量控制。这种协作负荷分配器(CLD)的系统在群集间负荷平衡器之间执行分布式流量控制。一个协作负荷分配器考虑了由资源管理器(如果系统内有的话)为用户动态分配和去分配实例容量。它还利用负荷监视器(如果系统内有的话)收集的动态负荷信息，有效地平衡负荷。CLD动态地根据每个用户的当前请求进入速率和每个用户的请求分发速率和/或容量分配/去分配或者根据任何其他系统状态确定是否向前级CLD发送什么控制信号。
虽然以上对本发明的这些优选实施例作了例示和说明，但显然本发明并不局限于这些实施例。对于熟悉该技术领域的人员来说，各种修改、变动、替换和等效型都是显而易见的，并不背离如在权利要求书中所给出的本发明的精神实质和专利保护范围。
权利要求
1.一种在一个多级计算系统内调度需处理的请求的方法，所述计算系统每个级都具有至少一个队列，每个队列都具有至少一个与之关联的处理功能，所述方法包括下列步骤a.将请求缓存在第一级的队列内；b.与同第一级相邻的其他级交换流量信息；c.得出请求的分类值；以及d.根据所得出的值调度请求。
2.如在权利要求1中所述的方法，其中所述调度步骤包括分发请求。
3.如在权利要求1中所述的方法，其中所述调度步骤包括对请求分类。
4.如在权利要求1中所述的方法，其中所述调度步骤包括丢弃请求。
5.如在权利要求1中所述的方法，所述方法还包括如果所得出的分类值大于一个预先规定的值就在第一级处理该请求的步骤。
6.如在权利要求1中所述的方法，其中所述得出分类值的步骤包括下列步骤a.根据交换的流量信息计算一个效用值；b.如果计算的效用值小于一个预先规定的值，假设一个补偿措施；以及c.在考虑所假设的补偿措施后重新计算效用值。
7.如在权利要求6中所述的方法，所述方法还包括a.如果重新计算出的效用值大于预先规定值就采取所假设的补偿措施；以及b.在采取所假设的补偿措施后在第一级处理该请求。
8.如在权利要求6中所述的方法，其中所述假设补偿措施的步骤包括如果一个适当队列不能接受请求就假设增大这个适当队列的请求处理能力的步骤。
9.如在权利要求6中所述的方法，其中所述假设补偿措施的步骤包括如果下级的一个队列不能接受请求就假设降低一个适当队列的请求分发速率的步骤。
10.一种在一个多级计算系统内调度需处理的请求的系统，所述计算系统每个级都具有至少一个队列，每个队列都具有至少一个与之关联的处理功能，所述系统包括a.在一个第一级与同第一级相邻的其他级之间交换流量信息的装置；b.根据交换的流量信息得出请求的分类值的装置；以及c.调度请求的装置。
11.如在权利要求10中所述的系统，其中所述调度装置还包括分发请求的装置。
12.如在权利要求10中所述的系统，其中所述调度装置还包括对请求分类的装置。
13.如在权利要求10中所述的系统，其中所述调度装置还包括丢弃请求的装置。
14.如在权利要求10中所述的系统，所述系统还包括如果所得的分类值大于一个预先规定的值就在第一级处理该请求的装置。
15.如在权利要求10中所述的系统，其中所述得出分类值的装置包括a.根据交换的流量信息计算一个效用值的装置；b.在考虑一个所假设的补偿措施后重新计算效用值的装置；以及c.如果重新计算的效用值大于一个预先规定的值就采取所假设的补偿措施的装置。
16.如在权利要求15中所述的系统，其中所述采取所假设的补偿措施的装置包括如果第二级队列不能接受另外的请求就降低第一级队列的请求分发速率的装置。
17.如在权利要求15中所述的系统，其中所述采取所假设的补偿措施的装置包括如果第二级队列不能接受另外的请求就提高第二级队列的请求处理能力的装置。
18.一种在一个计算系统内调度请求的计算机程序产品，所述计算机程序产品包括a.将请求缓存在第一级的一个队列内的程序指令；b.与同第一级相邻的其他级交换流量信息的程序指令；c.得出请求的分类值的程序指令；以及d.根据分类值调度请求的程序指令。
19.一种在一个计算系统内进行负荷平衡的设备，所述设备包括a.多个队列，这些队列包括i.一个缓存进入的请求的第一级队列，ii.多个后级队列，每个后级队列与一个进入的请求的类别相对应；b.根据用户规定的参数将请求分入多个后级队列的装置；c.在多个队列的级之间交换信息的装置；以及d.将请求从队列分发给至少一个队列或目标部件的装置。
20.如在权利要求19中所述的设备，其中所述分发装置包括并行分发请求的装置。
21.如在权利要求19中所述的设备，其中所述交换信息的装置还包括控制对来自这些队列的请求的分发速率的装置。
22.如在权利要求19中所述的设备，其中对所述请求在第一级队列根据QoS/SLA和来自后级队列的信息进行分类。
23.一种在一个计算系统内进行负荷平衡的计算机程序产品，所述计算机程序产品包括a.产生多个队列的程序指令，这些队列包括i.一个缓存进入的请求的第一级队列；ii.多个后级队列，每个后级队列与一个进入的请求的类别相对应；b.根据用户规定的参数将请求分成多个类别的程序指令；c.在多个队列的级之间交换信息的程序指令；以及d.将请求从队列分发给至少一个队列或目标部件的程序指令。
24.一种在一个计算系统内调度请求的系统，所述系统包括a.多个群集；以及b.多个负荷平衡器，其中每个负荷平衡器与至少一个群集相对应，并包括i.接收请求的装置；ii.与相邻级负荷平衡器交换信息的装置；iii.得出请求分类值的装置；以及iv.根据分类值将请求分发给下一级群集的装置。
25.一种在一个网络内调度请求的方法，所述网络包括多个负荷平衡器，所述方法包括下列步骤a.在一个第一级负荷平衡器接收请求；b.与相邻级的负荷平衡器交换具体请求的信息；c.通过处理交换的信息得出请求的分类值；以及d.根据得出的值调度请求。
26.如在权利要求25中所述的方法，其中所述处理交换的信息的步骤包括a.确定转发请求的门限效用值；b.得出转发请求的效用值；c.将效用值与门限效用值相比较；以及d.如果效用值小于门限效用值就采取补偿措施。
27.如在权利要求26中所述的方法，其中所述确定门限效用值的步骤还包括a.识别网络需提供的QoS和SLA的要求；以及b.确定分配给网络内这些请求的资源。
28.如在权利要求26中所述的方法，其中所述得出效用值的步骤包括a.从请求头标中识别与请求有关的QoS和SLA；b.确定在下级平衡器所分配的与请求相应的资源；以及c.处理所识别和确定的信息，得到效用值。
29.如在权利要求26中所述的方法，其中所述采取补偿措施的步骤包括降低负荷平衡器的请求分发速率。
30.如在权利要求26所述的方法，其中所述采取补偿措施的步骤包括提高负荷平衡器能力以接受另外的负荷，其中提高负荷平衡器能力增大了请求的效用值。
31.一种在一个网络内调度请求的计算机程序产品，所述计算机程序产品包括a.在一个第一级负荷平衡器接收请求的第一程序指令；b.与相邻级负荷平衡器交换请求的信息的第二程序指令；c.根据交换的信息得出请求的分类值的第三程序指令；以及d.根据分类值调度请求的第四程序指令。
全文摘要
本发明提供了一种在一个计算系统内调度任务的系统和方法。所揭示的系统模型具有多个级，每个级有至少一个队列。每个队列有至少一个处理功能和零个或多个与之关联的群集。在各级的队列之间采用流量控制技术来有效地调度任务，从而降低了任务丢弃率。根据流量控制指令，可以由一个队列执行诸如改变分发速率或改变队列的缓冲器容量之类的补偿措施。所揭示的系统和方法可以实现为协作负荷分配器(CLD)体系结构或协作负荷分配设备。
文档编号G06F15/177GK1508682SQ20031012143
公开日2004年6月30日 申请日期2003年12月16日 优先权日2002年12月17日
发明者A·康杜, A 康杜 申请人:国际商业机器公司