CN101009642A - 一种基于任务分组的资源分配方法和装置 - Google Patents

Abstract

本发明公开了一种基于任务分组的资源分配方法，首先对接收到的任务进行分组获得不同的任务分组，然后确定不同任务分组的期望资源数，并根据所述期望资源数为不同的任务分组分配资源，使得不同分组的任务获得资源服务的机会均等。本发明还公开了一种基于任务分组的资源分配装置，包括任务分组模块和管理模块，任务分组模块用于对任务进行分组，管理模块确定不同任务分组的期望资源数，并根据所述期望资源数为任务分组模块所分的不同任务分组分配资源。这种装置使得不同分组的任务获得资源服务的机会均等。

Description

一种基于任务分组的资源分配方法和装置

技术领域

本发明涉及资源分配技术，尤指一种基于任务分组的资源分配方法和装置。

背景技术

在基于客户端/服务器(C/S)模式的服务器程序中，合理地分配服务器端的资源可以使服务器程序能够更好地服务于客户端。服务器端的资源包括：线程、处理器、内存、带宽等等。

线程是进程中某个单一顺序的控制流。与创建一个进程相比，创建一个线程将会耗费小得多的系统资源，对于那些并发进程数特别多的应用，使用线程会比使用进程获得更好的性能。

为了提高处理器的使用率，出现了多线程技术。多线程技术解决了处理器单元内多个线程并发执行的问题，可以显著减少处理器单元的闲置时间，增加处理器单元的吞吐能力。但线程的创建和销毁都需要一定的占用处理器的时间片资源，所以如果在系统较忙时，频繁地创建和销毁线程，会增加单个任务的处理时间，反而会影响服务器程序的性能。

为了减少线程创建时间和线程销毁时间对服务器性能的影响，出现了线程池技术。线程池这种技术把线程创建时间和线程销毁时间分别安排在服务器程序的启动和结束的时间或者其他的空闲时间段。创建若干数量的线程后，让这些线程都处于空闲状态，当客户端有一个新任务时，唤醒线程池中的某一个空闲线程，让它来处理客户端的这个任务，当处理完这个任务后，线程又处于空闲状态。这样，当服务器程序处理客户端发来的请求时，就不会再有线程创建和销毁时间的开销了。

目前，线程池对客户端任务的调度是：只要有空闲的线程，就依次从任务队列中取出任务进行处理。

图1是对现有的线程池调度任务的方法进行举例说明的示意图，如图1所示，假设服务器应用程序的任务队列中有两种任务，一种是轻量级任务J1，耗费线程的时间为1毫秒(ms)，另一种是重量级任务J2，耗费线程的时间是100000ms；另外还假设线程池中有两个线程Th1和Th2，且线程Th1和线程Th2的处理能力完全相同。

如图1所示，Th1和Th2只要空闲，就依次从任务队列中调度任务进行处理，调度过程如下：

Th1在第0ms取到了任务J2，Th1从第0ms到第100000ms被J2占用；

Th2在第0ms取到了任务J1，Th2从第0ms到第1ms被J1占用；

Th2在第1ms取到了任务J1，Th2从第1ms到第2ms被J1占用；

Th2在第2ms取到了任务J2，Th2从第2ms到第100002ms被J2占用；

Th1在第100000ms取到了任务J1，Th1从第100000ms到第100001ms被J1占用。

可以看出，从第2ms到第100000ms，线程池中的两个线程Th1和Th2都被重量级任务J2占用，使得极容易处理的轻量级任务J1要等过这段时间后才能得到被线程处理的机会。虽然重量级任务和轻量级任务对空闲状态线程的占有机会是均等的，但是一旦重量级任务抢占了线程池中的线程，就会占用较长的时间。所以，在现有的线程池调度任务的方法中，重量级任务和轻量级任务占有线程池中的线程的时间比例是不同的。例如在图1所示的例子中，队列中有3个轻量级任务J1和两个轻量级任务J2，处理这五个任务需要的总时间Totaltime等于处理3个J1的时间加上处理2个J2的时间，即：

Totaltime＝3×1ms+2×100000ms

因此，处理3个J1的时间占总时间的比例RateJ1和处理2个J2的时间占总时间的比例RateJ2分别为：

RateJ1＝3×1ms/Totaltime＝3×1ms/(3×1ms+2×100000ms)＝0.0015％

RateJ2＝2×100000ms/Totaltime＝2×100000ms/(3×1ms+2×100000ms)＝99.9985％

从上面的公式可以看出，在轻量级任务和重量级任务的数量相差不多的情况下，重量级任务占用线程时间的比例要大很多，轻量级任务在争抢线程池中的线程资源时相对处于弱势。这时，很容易出现重量级的任务占用了全部的线程资源，而轻量级任务得不到线程处理的情况。

实际应用中重量级任务占用全部线程资源的情况很多，例如，图2是智能网预付费信令的流程图，在图2中，主叫移动交换中心/访问位置寄存器/业务交换点(MSCa/VLR/SSP)可以看成是客户端，主叫业务控制点(SCPa)可以看成是服务器，初始检测点消息(IDP)和申请计费报告消息(ACR)相对其他任务为重量级任务，而基本呼叫状态模型事件报告消息(ERB)是轻量级任务。

如果按现有的线程资源调度方法对SCPa中的线程资源进行调度，当每秒的呼叫次数比较大的时候，就有可能使SCPa的线程资源都被IDP和ACR占用，而这个流程中的ERB任务不能得到SCPa线程的及时处理，从而造成会话超时，呼损率提高。

从以上说明可以看出，由于重量级的任务占用全部的线程资源，对服务器应用程序和客户端程序会造成不良影响。对于服务器程序来说，在所有的线程资源都被重量级任务占用的时间段内，任务队列中的其它任务得不到调度处理，使得积累在任务队列中的任务越来越多，服务器程序占用的系统内存也越来越大，最后可能导致任务队列拥塞，甚至导致服务器应用程序崩溃。对于客户端程序来说，会导致客户端的请求响应不及时，且当客户端的一个任务由多个不同重量级的任务组成时，由于服务器的所有线程资源都被重量级任务占用，其他量级的任务无法得到响应，从而导致客户端的业务无法实现。

总之，现有的线程池调度方法中，部分任务占用全部资源的情况，使得其它任务无法获得线程资源的服务。

发明内容

本发明实施例提供一种基于任务分组的资源分配方法，使得不同分组的任务获得资源服务的机会均等。

本发明实施例还提供一种基于任务分组的资源分配装置，使得不同分组的任务获得资源服务的机会均等。

本发明实施例公开了一种基于任务分组的资源分配方法，该方法包括：

对接收到的任务进行分组，获得不同的任务分组；

根据资源总数，和/或任务分组总数，和/或不同的任务分组的任务权重确定所述不同的任务分组的期望资源数；

根据所述期望资源数为不同的任务分组分配资源。

本发明还公开了一种基于任务分组的资源分配装置，其特征在于，该装置包括：

任务分组模块，用于对接收到的任务进行分组，并将不同分组的任务分配到相应的任务分组队列中；

管理模块，用于为所述任务分组模块中的不同的任务分组计算期望资源数，并根据所述期望资源数为不同的任务分组队列分配资源。

由上述技术方案可见，本发明实施例方案首先对任务进行分组，获得不同的任务分组，然后确定不同任务分组的期望资源数，并根据所述期望资源数为各个不同的任务分组队列分配资源，使得不同分组的任务获得资源服务的机会均等，从而避免了部分分组的任务占用全部资源，而其他分组的任务无法获得资源服务的情况。

附图说明

图1是对现有的线程池调度任务的方法进行举例说明的示意图；

图2是智能网也付费信令的流程图；

图3是本发明实施例基于任务分组的资源分配方法的流程图；

图4是本发明实施例基于任务分组的资源分配装置的结构框图；

图5是本发明实施例基于任务分组的线程池资源分配方案的示意图；

图6是本发明实施例基于任务分组的线程资源分配装置的结构框图；

图7是服务器应用程序处理任务的流程图；

图8是服务器应用程序调度空闲线程的流程图；

图9是服务器应用程序调度忙碌线程的流程图。

具体实施方式

本发明实施例为了使各种任务得到资源服务的机会均等，首先对接收到的任务进行分组，然后确定不同任务分组的期望资源数，并根据所述期望资源数为不同任务分组分配资源。

图3是本发明实施例基于任务分组的资源分配方法的流程图，包括以下步骤：

步骤301，对接收到的任务进行分组，获得不同的任务分组。

这里，可以根据处理任务所需资源的数目和/或任务的属性对接收到的任务进行分组，其中，任务的属性可以是任务所属的客户或任务的权重。

步骤302，根据资源总数，和/或任务分组总数，和/或不同的任务分组的任务权重确定不同任务分组的期望资源数，并根据所述期望资源数为不同任务分组分配资源。

本步骤中，可以根据式(1)所示的资源分配公式确定不同任务分组的期望资源数，式(1)的具体形式如下：

$R_i=R\×(r_i/\underset{m=1}{\overset{M}{\mathrm{\Σ}}}{r}_m)i=\mathrm{1,2},...,M---\left(1\right)$

其中，期望资源数R_i表示分配给第i个任务分组的期望服务器资源数目；

总的资源数R表示总的服务器资源数目；

r_i表示当前第i个任务分组中的任务权重；

r_m表示第m个任务分组中的任务权重，m＝1，2，…，M；

任务分组个数M表示总的任务分组个数。

公式(1)的含义是：为第i个任务分组分配的期望资源数占总的资源数的百分比例，等于第i个任务分组中的任务的权重占M个任务分组中的任务的权重的总和的百分比例。

当公式(1)中的参数R，和/或r_i，和/或M发生变化时，重新计算资源分配公式，并根据计算结果重新为每组任务分配服务器资源。

图3所示的方法可以在一定程度上保证不同分组的任务获得服务器资源服务的机会均等。

图4是本发明实施例基于任务分组的资源分配装置的结构框图，该装置包括管理模块401和任务分组模块402。

管理模块401，用于为所述任务分组模块中的不同的任务分组计算期望资源数，并根据所述期望资源数为不同的任务分组队列分配资源。

任务分组模块402，接收客户端发送的任务，对接收到的任务进行分组，并将不同分组的任务分配到相应的任务分组队列中；

以下以服务器端的线程池资源为较佳实施例，对本发明实施例进一步详细说明。

图5是本发明实施例基于任务分组的线程池资源分配方案的示意图，如图5所示，客户端的任务首先通过客户端和服务器端的接口装置任务执行器501转发后，被发送到基于任务分组的线程资源分配装置502。基于任务分组的线程资源分配装置502根据任务的类型将任务分配到任务分组队列中相应的任务分组队列当中，并根据资源分配公式动态地将线程池503中的线程资源分配给各组任务。

在图5所示的实施例中，假设资源是服务器中的线程，则式(1)所示的资源分配公式可改写成如下的线程资源分配公式：

$N_i=N\×(T_i/\underset{m=1}{\overset{M}{\mathrm{\Σ}}}{T}_m)i=\mathrm{1,2},...,M---\left(2\right)$

其中，期望线程个数N_i表示服务于第i个任务分组的期望线程个数；

总的线程N表示线程池中总的线程个数；

T_i表示一个线程处理一项第i个任务分组中的任务所需的时间；

T_m表示一个线程处理一项第m个任务分组中任务所需的时间；

任务分组个数M表示总的任务分组个数。

假设图5中所有任务按照重量级的轻重被分成3组，即M＝3。第1组是重量级任务，第3组是轻量级任务，第2组是重量级介于第1组和第3组之间的任务。这里任务的重量级是指线程处理任务时，任务占用线程时间的长短。每种任务按照到达的先后顺序排列在各自的队列当中。线程池中总共有N个线程，按照资源分配公式(2)进行线程资源分配的结果是：服务于第1组任务的线程个数为N₁，服务于第2组任务的线程个数为N₂，服务于第3组任务的线程个数为N₃，且N₁+N₂+N₃＝N。

图6是本发明实施例基于任务分组的线程资源分配装置的结构框图，如图6所示，基于任务分组的线程资源分配装置502包括：管理模块601、任务分组模块602、动态分析模块603、线程资源调度模块604、和任务队列过载检测模块605。

管理模块601，用于根据线程资源分配公式(2)为任务分组模块602所分的各个任务分组分配线程。管理模块601还记录第i个任务分组的期望线程个数N_i、实际服务于第i种任务分组的实际线程个数、一个线程处理一项第i个任务分组中的任务所需的时间T_i、线程池中总的线程个数N、每个任务队列能容纳的最大任务个数J_maxi和各个任务分组队列的标识信息。任务分组队列的标识信息用于唯一地标记相应的任务分组。上述参数中i＝1，2，…，M。当总的分组个数M变化时，管理模块601重新计算线程资源分配公式(2)，并记录计算结果。

任务分组模块602，用于接收客户端发送的任务，对接收到的任务进行分组，并将各个不同任务分组队列的标识信息注册到管理模块601中。

任务分组模块602在将所分组的任务分配到相应的任务分组队列中之前，向任务队列过载检测模块605发出检测通知，当收到任务队列过载检测模块605返回的未过载通知时，再将不同分组的任务分配到相应的任务分组队列中。

本实施例中任务分组模块602是按照线程处理任务所需的时间的长短，即按任务的重量级大小进行的分组，这样的分组在一定程度上能够保证不同重量级的任务得到线程处理的机会均等。也可以按照任务的客户号进行分组，这样的分组在一定程度上能够保证不同客户的任务得到线程处理的机会均等。以此类推，可以根据任务的各种属性进行分组，使不同组的任务得到线程处理的机会均等。

任务队列过载检测模块605，用于接收任务分组模块602发出的检测通知后，从管理模块601读取相应任务分组队列所能容纳的最大任务个数J_maxi，并检查任务分组模块中相应的任务队列中的任务个数是否达到J_maxi。如果相应的任务队列中的任务个数未达到J_maxi，则任务队列过载检测模块605向任务分组模块602返回未过载的通知。

任务队列过载检测模块605本身也可以记录各个任务分组队列所能容纳的最大任务个数J_maxi，此时无需向管理模块601查询。

动态分析模块603，用于从任务分组模块602获取第i个任务分组队列中的任务，并分析线程处理一项第i个任务分组队列中的任务所需的时间T_i，将T_i注册到管理模块601中，i＝1，2，…，M；并在增加一个新的任务分组队列，即客户端任务请求中出现第M+1种属性的任务时，接收线程资源调度模块604发送的分析通知，从任务分组模块602获取第M+1组任务队列中的任务，分析线程处理该组任务分组队列中的一项任务所需的时间T_M+1’并将T_M+1注册到管理模块601中。

管理模块601接收到T_M+1后，根据线程资源分配公式重新计算每个任务分组队列的期望线程个数N_i，i＝1，2，…，M+1，并记录计算结果。

在本实施例中资源分配公式中任务的权重是线程处理一项任务所需的时间T_i，任务分组模块602接收到的任务本身并不携带关于T_i的信息，因此需要动态分析模块来分析不同任务分组中任务的权重T_i。但任务分组模块602接收到的任务本身也可以直接携带任务权重信息，此时任务分组模块602直接将不同任务分组中任务的权重注册到管理模块中，而不需要动态分析模块603去分析任务的权重。

线程资源调度模块604，用于调度处于空闲状态的空闲线程和处理完当前任务的忙碌线程。即在总的任务分组个数发生变化时，通过调度空闲资源和忙碌资源来实现资源的重新分配。

线程资源调度模块604调度空闲资源是：

首先线程资源调度模块604向空闲资源发出激活通告，激活处于空闲状态的线程；之后，向管理模块601查询是否存在尚未确定期望资源数的任务分组队列，即查询是否存在新增的任务分组队列，如果存在，则向动态分析模块603发送分析通知，分析通知中包含尚未确定期望资源数的任务分组队列的标识信息；动态分析模块603根据根据分析通知中的标识信息从任务分组模块602中的尚未确定期望资源数的任务分组队列中获取任务，并分析线程处理该尚未确定期望资源数的任务分组队列中的一项任务所需的时间T_M+1并将T_M+1注册到管理模块601中；

当不存在尚未确定期望资源数的任务分组队列时，线程资源调度模块604向管理模块601查询是否存在实际线程个数小于期望线程个数N_i的任务分组队列。实际线程个数是指实际服务于该任务分组队列的线程个数。如果存在实际线程个数小于期望线程个数N_i的任务分组队列，则线程资源调度模块604将新激活的线程添加到实际线程个数小于期望线程个数N_i的任务分组队列的线程工作空间，并更新注册在管理模块601中的该任务分组队列的实际线程个数；否则释放激活的线程，使其重新回到空闲状态。

线程资源调度模块604调度忙碌资源是：

线程资源调度模块604待忙碌线程处理完当前任务之后，同样向管理模块601查询是否存在尚未确定期望资源数的任务分组队列，如果存在，则向动态分析模块603发送分析通知，使动态分析模块603分析线程处理该尚未确定期望资源数的任务分组中的一项任务所需的时间T_M+1，并将T_M+1注册到管理模块601中；

当不存在尚未确定期望资源数的任务分组队列时，线程资源调度模块604向管理模块601查询是否存在实际线程个数小于期望线程个数N_i的任务分组队列。如果存实际线程个数小于期望线程个数N_i的任务分组队列，则线程资源调度模块604将忙碌线程添加到实际线程个数小于期望线程个数N_i的任务分组队列的线程工作空间，并更新注册在管理模块601中的该任务分组队列的实际线程个数；否则释放忙碌线程，使其变成空闲线程。

上述过程中，资源调度模块604向管理模块601查询是否存在尚未确定期望资源数的任务分组队列是，通过查询管理模块601中记录的各个不同任务分组队列的标识信息和期望资源数来确定是否存在尚未确定期望资源数的任务分组队列。例如，管理模块601中记录了某个任务分组的标识信息，却没有记录该任务分组的期望资源数，则该任务分组是尚未确定期望资源数的任务分组。

下面通过描述服务器应用程序处理任务及调度线程池中线程的过程，来进一步详细说明本发明实施例的技术方案。

图7是服务器应用程序处理任务的流程图。图7所示，包括以下步骤：

步骤701，确定客户端程序提交的任务的重量级。

步骤702，根据任务的重量级查询任务分组队列中是否存在相应重量级的任务分组队列，如果存在执行步骤703，否则执行步骤704。

步骤703，检测相应重量级的任务分组队列是否过载，即检查相应任务分组队列中的任务数量是否大于J_max，是则执行步骤706，否则执行步骤707。

步骤704，新建一个任务分组队列，并将任务添加到该任务分组队列中。

步骤705，根据线程资源分配公式(2)重新分配线程。结束本流程。

步骤706，拒绝客户端的任务提交。结束本流程。

步骤707，将任务添加到相应的任务分组队列中，并向线程池中的空闲线程发出激活通告。

步骤705中所述根据线程资源分配公式(2)重新分配线程是，通过以一定的方法调度空闲线程和忙碌线程来实现的。下面介绍本发明提供的空闲线程和忙碌线程调度方法。

图8是服务器应用程序调度空闲线程的流程图。如图8所示，包括以下步骤：

步骤801，向线程池中的空闲线程发出激活通告，以激活处于空闲状态的线程。

步骤802，按照任务分组队列创建的时间顺序查询是否存在尚未确定期望资源数的任务分组，如果存在，执行步骤803，否则，执行步骤804。

步骤803，通过线程的自学习获得线程处理一项尚未确定期望资源数的任务分组中的任务所需的时间T_M+1，根据线程资源分配公式(2)重新计算服务于每个任务分组的期望线程个数N_i，并记录计算结果。执行步骤802。

步骤804，按照任务分组队列创建的时间顺序查询是否存在实际线程个数没有达到期望值的任务分组，如果存在，执行步骤805；否则，执行步骤806。

实际线程个数没有达到期望值的任务分组，是指实际服务于该任务分组的线程个数少于由线程资源分配公式(2)计算得出的该任务分组队列的期望线程个数N_i。

步骤805，将激活的空闲线程添加到实际线程个数没有达到期望值的任务分组的线程工作空间中。结束本流程。

步骤806，释放该线程，使线程回到空闲状态，等待激活。

图9是服务器应用程序调度忙碌线程的流程图。如图9所示，包括以下步骤：

步骤901，当线程忙碌时，等待忙碌线程完成正在处理的任务后，执行步骤902。

步骤902，按照任务分组队列创建的时间顺序查询是否存在尚未确定期望资源数的任务分组，如果存在，执行步骤903，否则，执行步骤904。

步骤903，通过线程的自学习获得线程处理一项尚未确定期望资源数的任务分组中的任务所需的时间T_M+1，根据线程资源分配公式(2)重新计算服务于每个任务分组的期望线程个数N_i，并记录计算结果。执行步骤902。

步骤904，按照任务分组队列创建的时间顺序查询是否存在实际线程个数没有达到期望值的任务分组，如果存在，执行步骤905；否则，执行步骤906。

步骤905，将激活的线程添加到实际线程个数没有达到期望值的任务分组的线程工作空间中。结束本流程。

步骤906，释放该线程，使线程变为空闲线程，等待激活。

在上述服务器应用程序调度线程的过程中，首先查询是否存在尚未确定期望资源数的任务分组，如果存在，则优先分析该任务分组中任务的权重，然后重新确定各个任务分组的期望资源数。这种方案避免了新增加的任务分组长时间得不到线程处理的情况。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1、一种基于任务分组的资源分配方法，其特征在于，该方法包括：

对接收到的任务进行分组，获得不同的任务分组；

根据资源总数，和/或任务分组总数，和/或不同的任务分组的任务权重确定所述不同的任务分组的期望资源数；

根据所述期望资源数为不同的任务分组分配资源。

2、如权利要求1所述的方法，其特征在于，该方法还包括：接收到新任务，判断所述新任务是否属于已经存在的任务分组，如果属于，则将所述新任务分配到相应的已经存在的任务分组中；否则，

新建一个任务分组，并将所述新任务分配到新建的任务分组中，同时，根据变化后的任务分组总数，重新确定不同的任务分组的期望资源数，并根据重新确定的期望资源数为不同的任务分组重新分配资源。

3、如权利要求2所述的方法，其特征在于，在将所述新任务分配到相应的已经存在的任务分组中之前，进一步包括：确定所述相应的已经存在的任务分组未过载。

4、如权利要求1所述的方法，其特征在于，该方法还包括：重新确定不同的任务分组的期望资源数，根据重新确定的期望资源数为不同的任务分组分配资源，包括：

查询是否存在尚未确定期望资源数的任务分组，如果存在，则根据资源总数，和/或任务分组总数，和/或当前不同的任务分组的任务权重，重新确定当前不同的任务分组的期望资源数；

当不存在尚未确定期望资源数的任务分组时，查询是否存在实际资源数小于所述期望资源数的任务分组，如果存在，则将空闲资源或处理完当前任务的忙碌资源分配给所述实际资源数小于期望资源数的任务分组；否则，释放所述空闲资源或处理完当前任务的忙碌资源。

5、如权利要求1所述的方法，其特征在于，对接收到的任务进行分组具体为：根据处理所述接收任务所需资源的数目和/或所述接收任务的属性进行分组。

6、如权利要求1至5所述的任一方法，其特征在于，所述资源具体为服务器端的处理器、线程、内存或带宽。

7、一种基于任务分组的资源分配装置，其特征在于，该装置包括：

任务分组模块，用于对接收到的任务进行分组，并将不同分组的任务分配到相应的任务分组队列中；

管理模块，用于为所述任务分组模块中的不同的任务分组计算期望资源数，并根据所述期望资源数为不同的任务分组队列分配资源。

8、如权利要求7所述的装置，其特征在于，该装置进一步包括：动态分析模块，用于从所述任务分组模块中的不同任务分组队列获取任务，分析不同任务分组队列中任务的权重，并将不同任务分组队列中任务的权重注册到所述管理模块中；

所述任务分组模块进一步用于将不同任务分组队列的标识信息注册到所述管理模块中；

所述管理模块进一步用于，接收并记录所述动态分析模块发送的不同任务分组队列中任务权重的注册值、所述任务分组模块发送的不同任务分组队列的标识信息，并记录计算得到的不同任务分组队列的期望资源数和实际分配给不同任务分组队列的实际资源数；管理模块根据资源总数，和/或任务分组总数，和/或不同的任务分组的任务权重计算所述不同的任务分组的期望资源数。

9、如权利要求8所述的装置，其特征在于，该装置进一步包括：资源调度模块，用于从所述管理模块查询是否存在尚未确定期望资源数的任务分组队列，在存在尚未确定期望资源数的任务分组队列时，向所述动态分析模块发送分析通知；

所述动态分析模块进一步用于，接收来自资源调度模块的分析通知，从所述分组模块中的尚未确定期望资源数的任务分组队列中获取任务，分析尚未确定期望资源数的任务分组队列中任务的权重，并将分析得到任务权重注册到所述管理模块中；

所述管理模块进一步用于，接收来自所述动态分析模块的任务权重的注册值，重新计算并记录当前不同的任务分组的期望资源数。

10、根据权利要求9所述的装置，其特征在于，在不存在尚未确定期望资源数的任务分组队列时，

所述资源调度模块进一步用于，从所述管理模块查询是否存在实际资源数小于期望资源数的任务分组队列，在存在时，将空闲资源或处理完当前任务的忙碌资源分配给所述实际资源数小于期望资源数的任务分组队列，并更新管理模块中记录的所述实际资源数小于期望资源数的任务分组队列的实际资源数；

在不存在时，所述资源调度模块释放空闲资源或处理完当前任务的忙碌资源。

11、如权利要求7所述的装置，其特征在于，该装置进一步包括：任务队列过载检测模块，用于接收来自所述任务分组模块的检测通知，检测相应的任务分组队列是否过载，在未过载时，向所述任务分组模块发送未过载通知；

所述任务分组模块进一步用于，接收来自任务队列过载检测模块的未过载通知，将所述已分组的任务分配到所述相应的任务分组队列中。

Images