CN101610220B - 一种控制业务下发流量的方法及系统 - Google Patents

Abstract

本发明公开了一种控制业务下发流量的方法及系统，包括：内容提供平台CP进行业务的下发，同时向业务管理平台发送该业务的业务下发消息；所述业务管理平台根据定期收集的资源信息和接收的所述CP发送的业务下发消息生成系统资源占用信息，根据生成的系统资源占用信息判断如果系统的资源过负荷，则生成流量控制消息并发送给所述CP；所述CP根据接收的所述流量控制消息调整下发的业务量，进行业务的下发。应用本发明，对业务管理平台进行业务下发流量控制，解决多个CP同时下发大业务量引起的平台资源占用过高导致的业务下发失败或网络拥塞问题。

Description

一种控制业务下发流量的方法及系统

技术领域

本发明涉及通讯领域，尤其涉及一种控制业务下发流量的方法及系统。

背景技术

随着通讯技术的发展，数据通讯成为主要的业务形式。在通讯网络中，业务管理平台是一个可将各种数据业务统一管理的通讯管理平台。业务管理平台针对用户、内容提供商以及运营商等提供以下主要功能：

为用户提供统一的用户体验和业务浏览、使用的接入点；

为内容提供平台(CP，content provider，或称为内容提供商，以下简称CP)提供统一的申请合作和各种数据业务的界面；

为运营商提供统一的管理各种数据业务信息、CP信息、用户信息和运营策略的功能集中点。

业务管理平台保存了用户信息和业务、产品信息，当用户进行产品或业务订购时会生成订购关系保存，同时提供对用户和CP的鉴权和计费。当用户订购了CP提供的业务后，CP要向用户下发业务，CP向用户下发业务时需要在业务管理平台进行鉴权和计费。由于每个CP都有大量的用户订购业务，当多个CP同时向用户下发业务时，对于业务管理平台而言，可能会因为消息量太大而超出业务管理平台的处理能力，造成大量的业务下发失败，并且可能在各个CP都下发完业务后，又会出现业务管理平台长时间空闲，因而业务管理平台的资源没有得到合理的使用。

综上，如何针对业务管理平台可能出现的业务集中下发造成超出处理能力而下发失败，以及业务集中下发后在时间上可能出现的业务空闲的业务平台资源浪费等问题进行妥善控制，则成为需要解决的一个问题，因而，需要一套业务流量控制的技术方案来对业务管理平台的业务流量进行合理控制。

发明内容

本发明所要解决的技术问题是提供一种控制业务下发流量的方法及系统，对业务管理平台进行业务下发流量控制，解决多个CP同时下发大业务量引起的平台资源占用过高导致的业务下发失败或网络拥塞问题。

为了解决上述问题，本发明提供了一种控制业务下发流量的方法，包括：

内容提供平台CP进行业务的下发，同时向业务管理平台发送该业务的业务下发消息；

所述业务管理平台根据定期收集的资源信息和接收的所述CP发送的业务下发消息生成系统资源占用信息，根据生成的系统资源占用信息判断如果系统的资源过负荷，则生成流量控制消息并发送给所述CP；

所述CP根据接收的所述流量控制消息调整下发的业务量，进行业务的下发。

本发明还提供了一种控制业务下发流量的系统，包括业务管理平台和内容提供平台CP，其中，

所述业务管理平台包括系统资源收集模块和业务流量控制模块，所述CP包括下发控制模块，其中：

所述下发控制模块，用于进行业务的下发时，向所述系统资源收集模块发送该业务的业务下发消息；接收所述流量控制模块发送的所述流量控制消息，根据该流量控制消息调整下发的业务量，进行业务的下发；

所述系统资源收集模块，用于接收所述下发控制模块发送的所述业务下发消息，根据定期收集的资源信息和业务下发消息生成系统资源占用信息，上报给所述流量控制模块；

所述流量控制模块，用于根据接收的系统资源收集模块上报的系统资源占用信息，判断系统的资源是否过负荷，如果是，则生成并发送流量控制消息给所述下发控制模块。

与现有技术相比，应用本发明的控制业务下发流量的方法及系统，可以实现对业务下发流量的控制，一方面可以实现集中进行总体统一控制，也可以结合各个CP的优先级和信用度进行个性流量控制，在业务管理平台与CP之间建立了对话机制，从而有效地克服了多个CP同时集中进行业务下发，因对业务管理平台的冲击所导致的消息下发失败，可以维持业务管理平台的稳定，避免网络拥塞，使业务管理平台的资源得到合理的应用，提高业务下发的成功率和效率。同时，动态调整流量控制参数以及定期清零等手段又可提高业务下发流量控制的灵活性。

附图说明

图1是本发明中控制业务下发流量的系统的结构示意图；

图2是本发明中控制业务下发流量的方法的流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本发明作进一步地详细说明。

本发明的核心思想主要在于，针对现有技术中业务管理平台在承载各个CP下发的业务时，只是被动承载下发的情况，通过定期监测系统资源状态，由业务管理平台根据自身业务承载状态，为各个CP分配调整其被允许下发的业务量并通知各个CP，而各个CP则根据业务管理平台指定的业务量进行下发，这样，就在业务管理平台和各个CP之间建立一种会话机制，在业务量增大超过设置值时，可以及时通知各个CP调整每秒下发的业务量，避免出现集中超负荷下发的情形出现。

如图1所示，一种控制业务下发流量的系统，该系统包括业务管理平台和CP，所述业务管理平台和流量控制相关的模块包括系统资源收集模块和业务流量控制模块，所述CP和流量控制相关的模块包括下发控制模块，其中：

系统资源收集模块，用于接收下发控制模块发送的业务下发消息，根据定期收集的资源信息和业务下发消息生成系统资源占用信息，上报给所述流量控制模块；

所述系统资源收集模块生成的所述系统资源占用信息包括：CPU占用率、消息队列中未处理的业务下发消息数、设定时间内系统收到的业务下发消息总数以及各CP在设定时间内下发的业务下发消息数。

所述系统资源收集模块定期收集的所述资源信息包括所述CP的优先级系数和信用度系数；

所述流量控制模块生成所述流量控制消息并发送给所述下发控制模块，是指：

所述流量控制模块根据所述CP在设定时间内下发的业务下发消息数、所述流量调整比率、所述CP的优先级系数与所述CP的信用度系数相乘得到的数值，确定该CP调整后设定时间内下发的消息数，生成包含该CP调整后设定时间内下发的消息数的流量控制消息并发送给所述下发控制模块。

所述系统资源收集模块，还用于根据收集的所述资源信息，判断若包含已发送流量控制消息的CP，则判断该CP在设定时间内下发的业务下发消息数是否大于所述流量控制消息中所指示的该CP设定时间内下发的消息数；

若大于，且判断若未扣减所述CP的信用度系数，则将该CP的违约次数加1；当判断若该CP的违约次数大于3次时，则扣减该CP的信用度系数并记录；

若大于，且判断若已扣减所述CP的信用度系数，则不改变当前信用度系数记录。

流量控制模块，用于根据接收的系统资源收集模块上报的系统资源占用信息，判断系统的资源是否过负荷，如果是，则需要进行流量控制，生成并发送流量控制消息给所述下发控制模块；

所述流量控制模块根据生成的系统资源占用信息判断如果系统的资源过负荷，是通过以下方式完成：

所述流量控制模块根据所述系统资源占用信息中CPU占用率，判断该CPU占用率是否超过CPU占用率阀值，若是，则判定系统的资源过负荷；

或者所述流量控制模块根据所述系统资源占用信息，判断每秒需要处理的业务下发消息数是否大于该业务管理平台配置的每秒处理的业务下发消息能力数，若是，则判定系统的资源过负荷；其中，所述每秒需要处理的业务下发消息数是通过所述设定时间内系统收到的业务下发消息总数加上所述消息队列中未处理的业务下发消息数的和，除以设定时间的秒数得到的数值；

或者所述流量控制模块根据所述系统资源占用信息中CPU占用率，判断该CPU占用率是否超过CPU占用率阀值，若没有，则判断每秒需要处理的业务下发消息数是否大于该业务管理平台配置的每秒处理的业务下发消息能力数，若是，则判定系统的资源过负荷。

所述流量控制模块根据生成的系统资源占用信息判断如果系统的资源过负荷，则生成流量控制消息并发送给所述下发控制模块，是指：

所述流量控制模块根据生成的系统资源占用信息判断如果系统的资源过负荷，则确定调整后下发的业务量与原下发业务量的流量调整比率，根据该流量调整比率生成包含所述CP调整后设定时间内下发的业务下发消息数的流量控制消息，并发送给所述下发控制模块；

其中，当所述流量控制模块判断系统的资源过负荷的情况是所述CPU占用率超过所述CPU占用率阈值时，确定调整后下发的业务量与原下发业务量的流量调整比率为：1-(该CPU占用率-CPU占用率阈值)/CPU占用率阈值；

其中，当所述流量控制模块判断系统的资源过负荷的情况是每秒需要处理的业务下发消息数大于业务管理平台配置的每秒处理的业务下发消息能力数时，确定调整后下发的业务量与原下发业务量的流量调整比率为：1-(设定时间内需要处理的业务下发消息总数-该业务管理平台配置的设定时间内业务下发消息能力数)/该业务管理平台配置的设定时间内业务下发消息能力数；

下发控制模块，用于向用户进行业务的下发时，向业务管理平台中系统资源收集模块发送该业务的业务下发消息；接收所述流量控制模块发送的所述流量控制消息，根据该流量控制消息调整每秒需要下发的业务量，向用户进行业务的下发。

所述下发控制模块根据接收的所述流量控制消息调整下发的业务量，进行业务的下发，是指：所述下发控制模块根据接收的所述流量控制消息中所述CP调整后设定时间内下发的业务下发消息数，调整下发的业务量，进行业务的下发。

所述系统进行流量控制的流程，如下所示：

在该系统中，当到达业务下发时间后，CP中所述下发控制模块向用户进行业务的下发，同时向业务管理平台发送业务下发消息，并侦听是否收到流量控制消息；

当业务管理平台收到CP发送的业务下发消息进行鉴权，启动系统资源收集模块定期收集资源信息，根据定期收集的资源信息和接收的业务下发消息生成系统资源占用信息，并上报给流量控制模块；

流量控制模块根据收到的系统资源占用信息，判断当前系统是否过负荷，若是，则根据过负荷的情况生成流量控制消息，并发送给正在进行业务的下发的CP；

CP的下发控制模块侦听到所述流量控制消息后，根据流量控制消息调整每秒下发的业务量。

由于上述过程是定期动态进行的，因而，其既可以避免突发式的集中下发，将大量业务通过调整下发业务量来将业务分散开，避免了下发失败，也可以避免集中下发后的空闲，避免了资源浪费。

为实现对业务流量控制的目标，所述业务管理平台需要配置如下参数：

A、业务管理平台每秒能处理的业务下发的条数：

业务管理平台每秒能处理的业务下发的条数默认设置为其设计最大性能的70％，建议设置范围为最大处理能力的60％到80％，以便业务管理平台处于该业务负载范围时可以长期稳定的运行。

B、业务管理平台进行流量控制时的CPU占用率阀值：

业务管理平台开始进行流量控制时的CPU占用率阀值默认设置为70％，建议设置范围为60％到80％，以便业务管理平台处于该业务负载范围时可以长期稳定的运行。

C、系统资源收集模块收集和上报系统资源的时间间隔T：

时间间隔T默认为2分钟，建议设置范围为1到10分钟。设置为2分钟能比较实时的反应系统的资源占用变化，同时能给系统留出处理积压消息的时间。

D、CP的优先级系数和信用度系数。

CP的优先级系数由运营商来配置，如最高优先级系数为1，第二优先级系数为0.85，第三优先级系统为0.7等，具体系数由运营商确定，系统也可以给每个CP都设置一个默认的优先级系数。优先级系数只能通过运营商进行修改。

CP的信用度系数默认都为1，当通知CP进行流量控制，但CP在三个资源上报周期内没有进行流量控制的，则降低该CP的信用度系数。信用度每天只降低一次。各CP进行流量控制的业务量和该CP的优先级系数、信用度相关联。

图2为用户订购了包月业务后的控制业务下发流量的流程，下面结合图2对本发明进行详细的描述。

步骤201：下发控制模块启动时，启动流量控制侦听端口，侦听流量控制消息；

其中，CP根据系统的处理能力和需要下发的消息总量配置了每秒下发的业务量参数。

步骤202：业务管理平台启动，进行初始化，在内存中建立一个表，记录T时间(其中设定时间可以为T时间)内系统收到的业务下发消息总量，各个CP的地址、端口、CP的优先级系数和信用度，CP在T时间内下发的消息数，流量控制模块是否已下发流量控制消息，CP的流量控制业务量，CP的违约次数，是否已扣CP的信用度；并初始化T时间内系统收到的业务下发消息总数和CP在T时间内下发的消息数为0；

业务管理平台进行初始化，配置系统每秒能处理的业务下发的条数，设置开始进行流量控制时的CPU占用率阀值、资源收集模块收集和上报系统资源的时间间隔T、CP的优先级系数和信用度。

其中，系统每秒能处理的业务下发的条数默认设置为系统设计的最大性能的70％，建议设置范围为系统最大处理能力的60％到80％。这样当系统处于这个业务负载时可以长期稳定的运行。

开始进行流量控制时的CPU占用率阀值默认设置为70％，建议设置范围为60％到80％。这样当系统处于这个业务负载时可以长期稳定的运行。

时间间隔T可设置为2分钟，建议设置范围为1到10分钟。设置为2分钟能比较实时的反应系统的资源占用变化，同时能给系统留出处理积压消息的时间。

CP的优先级系数由运营商来配置，如最高优先级系数为1，第二优先级系数为0.85，第三优先级系统为0.7等，具体系数由运营商确定，系统也可以给每个CP都设置一个默认的优先级系数。优先级系数只能通过运营商进行修改。CP的信用度默认都为1，当通知CP进行流量控制控制但CP在三个资源上报周期内没有进行流量控制控制，则降低该CP的信用度。信用度每天只降低一次。各CP进行流量控制的业务量和该CP的优先级系数、信用度相关联。

业务管理平台定时将内存表中各CP的违约次数置为0，将CP流量控制业务量置为0，将是否已扣信用度置为0(即未扣信用度)，以及将是否已下发流量控制消息置为0(即未下发流量控制消息)；业务管理平台可以每天0点将内存表中各CP的违约次数置为0，将CP流量控制业务量置为0，是否已扣信用度置为0；将是否已下发流量控制消息置为0。

步骤203：当到达允许业务下发的时间，CP的下发控制模块重新读取所述配置的每秒下发的业务量参数，根据该参数向用户进行业务的下发，同时向业务管理平台发送业务下发消息；

步骤204：业务管理平台收到业务下发消息后，解析消息中对应的CP，根据系统过负荷情况进行鉴权，将内存表中对应CP在T时间内下发的消息数加1；

如果已经向该CP下发了流量控制消息，判断当前该CP下发的消息数是否大于流量控制限制的消息数，如果大于直接鉴权失败，返回的消息中的失败原因是超出系统流量控制的消息数；如果不大于流量控制限制的消息数或者该CP没有下发过流量控制消息，则执行下一步骤，同时将T时间内系统收到的业务下发消息总数加1；

步骤205：业务管理平台的系统资源收集模块每隔时间T收集资源信息和业务下发消息，根据收集的资源信息和业务下发消息生成系统资源占用信息并上报给流量控制模块；

系统资源占用信息上报给流量控制模块后，系统资源收集模块将内存表T时间内系统收到的业务下发消息总数清0，将各CP在T时间内下发的消息数清0，重新开始计数。

其中，所述资源信息包括所述CP的优先级系数和信用度系数。

其中，系统资源占用信息包括CPU占用率、消息队列中未处理的业务下发消息数、T时间内系统收到的业务下发消息总数以及各CP在T时间内下发的业务下发消息数。

步骤206：流量控制模块收到上报的系统资源占用信息，查找已发送流量控制消息的各CP，如果没有向该CP发送流量控制消息，则执行步骤208；如果已经向该CP发送流量控制消息，则执行步骤207；

步骤207、判断系统资源占用信息中各CP下发的消息总数是否大于该CP的流量控制业务量，如果大于，判断该CP是否已扣信用度，如果未扣，将该CP的违约次数加1，则判断该CP的违约次数是否大于3，如果大于3，则将CP的信用度降低10％记录到内存表和数据库中；如果该CP的违约次数不大于3，则不降低该CP的信用度(如果已扣信用度，则不操作)；

其中，将CP的信用度降低10％是系统的默认值，具体可以通过配置灵活实现。

步骤208：流量控制模块根据接收的系统资源占用信息判断系统资源是否过负荷，如果是，则计算需要CP降低下发的业务量比例，执行下一步骤；否则，返回步骤205；

在进行是否过负荷的判断时，可以采用3种判断方式：

(1)判断CPU占用率是否超过CPU占用率阀值；

(2)判断每秒需要处理的业务下发消息数是否大于业务管理平台配置的每秒处理的业务下发消息能力数；

(3)先判断CPU占用率是否超过CPU占用率阀值，若未超过，则继续判断每秒需要处理的业务下发消息数是否大于业务管理平台配置的每秒处理的业务下发消息能力数。

对于方式(1)，如果CPU占用率超过进行流量控制时的CPU占用率阀值，CPU占用率超过阀值的部分对应的业务量，就是需要CP减少下发的业务量。例如，进行流量控制时的CPU占用率阀值是50％，目前系统CPU占用率达到了70％，则CP需要将正在下发的业务量降低到(1-(70％-50％)/50％)，即每秒下发的业务量降低到原来的60％；通知到各CP的时候还需要乘以该CP的优先级系数p和信用度系数c。如某CP的优先级系数p为1，信用度系数c为0.8，每秒下发100条业务，则该CP需要将业务量降低到每秒100×60％×1×0.8＝48条。

对于方式(2)，则采用T时间内收到的业务下发消息总数加上消息队列的未处理业务下发消息数的和，除以资源收集上报周期的秒数，得到系统需要每秒处理的业务下发消息数。如果系统每秒需要处理的业务下发消息数大于系统配置的每秒处理的业务下发消息能力数，则超过部分即为需要CP减少下发的业务量。例如，业务管理平台的每秒处理能力是50，需要系统每秒处理的消息数70，则CP需要将正在下发的业务量降低到原来的(1-(70-50)/50)，即每秒下发的业务量降低到原来的60％。通知到各CP的时候还需要乘以该CP的优先级系数p和信用度系数c。如某CP的优先级系数p为1，信用度系数c为0.8，每秒下发100条业务，则该CP需要将业务量降低到每秒100×60％×1×0.8＝48条。

对于方式(3)，则需要先按照方式(1)进行判断，若未超负荷，则继续按照方式(2)进行判断是否超负荷。

步骤209：流量控制模块根据计算的应该每秒下发的业务量生成流量控制消息，向正在下发业务的CP发送该流量控制消息，通知下发控制模块将每秒下发的业务量降低到T时间内该CP应该下发的业务量；记录各CP的流量控制业务量，将是否已下发流量控制消息置为1(即已下发流量控制消息)；

系统资源占用信息中各CP在T时间内下发的消息数大于0则认为该CP正在进行业务下发。

步骤210：下发控制模块收到流量控制消息后，根据该消息调整每秒下发的业务量。

以上所述仅为本发明的实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。

Claims (10)

1.一种控制业务下发流量的方法，其特征在于，包括：

内容提供平台CP进行业务的下发，同时向业务管理平台发送该业务的业务下发消息；

所述业务管理平台根据定期收集的资源信息和接收的所述CP发送的业务下发消息生成系统资源占用信息，根据生成的系统资源占用信息判断如果系统的资源过负荷，则生成流量控制消息并发送给所述CP；

所述CP根据接收的所述流量控制消息调整下发的业务量，进行业务的下发，其中，所述业务管理平台根据生成的系统资源占用信息判断如果系统的资源过负荷，则确定调整后下发的业务量与原下发业务量的流量调整比率，根据该流量调整比率生成包含所述CP调整后设定时间内下发的业务下发消息数的流量控制消息，并发送给所述CP；所述CP根据接收的所述流量控制消息中所述CP调整后设定时间内下发的业务下发消息数，调整下发的业务量，进行业务的下发；其中，当所述业务管理平台判断系统的资源过负荷的情况是CPU占用率超过CPU占用率阈值时，所述业务管理平台确定调整后下发的业务量与原下发业务量的流量调整比率为：1-(该CPU占用率-CPU占用率阈值)/CPU占用率阈值；其中，当所述业务管理平台判断系统的资源过负荷的情况是每秒需要处理的业务下发消息数大于业务管理平台配置的每秒处理的业务下发消息能力数时，所述业务管理平台确定调整后下发的业务量与原下发业务量的流量调整比率为：1-(设定时间内需要处理的业务下发消息总数-该业务管理平台配置的设定时间内业务下发消息能力数)/该业务管理平台配置的设定时间内业务下发消息能力数。

2.如权利要求1所述的方法，其特征在于，

所述业务管理平台生成的所述系统资源占用信息包括：CPU占用率、消息队列中未处理的业务下发消息数、设定时间内系统收到的业务下发消息总数以及各CP在设定时间内下发的业务下发消息数。

3.如权利要求2所述的方法，其特征在于，

所述业务管理平台根据生成的系统资源占用信息判断系统的资源过负荷，包括以下方式：

所述业务管理平台根据所述系统资源占用信息中CPU占用率，判断该CPU占用率是否超过CPU占用率阈值，若是，则判定系统的资源过负荷；

或者所述业务管理平台根据所述系统资源占用信息，判断每秒需要处理的业务下发消息数是否大于该业务管理平台配置的每秒处理的业务下发消息能力数，若是，则判定系统的资源过负荷；其中，所述每秒需要处理的业务下发消息数是通过所述设定时间内系统收到的业务下发消息总数加上所述消息队列中未处理的业务下发消息数的和，除以设定时间的秒数得到的数值；

或者所述业务管理平台根据所述系统资源占用信息中CPU占用率，判断该CPU占用率是否超过CPU占用率阈值，若没有，则判断每秒需要处理的业务下发消息数是否大于该业务管理平台配置的每秒处理的业务下发消息能力数，若是，则判定系统的资源过负荷。

4.如权利要求1所述的方法，其特征在于，

所述资源信息包括所述CP的优先级系数和信用度系数；

所述业务管理平台生成所述流量控制消息并发送给所述CP，是指：

所述业务管理平台根据所述CP在设定时间内下发的业务下发消息数、所述流量调整比率、所述CP的优先级系数与所述CP的信用度系数相乘得到的数值，确定该CP调整后设定时间内下发的消息数，生成包含该CP调整后设定时间内下发的消息数的流量控制消息并发送给所述CP。

5.如权利要求4所述的方法，其特征在于，

所述业务管理平台定期收集资源信息和接收所述CP发送的业务下发消息后，还包括步骤：

所述业务管理平台根据所述资源信息，判断若包含已发送流量控制消息的CP，则判断该CP在设定时间内下发的业务下发消息数是否大于所述流量控制消息中所指示的该CP设定时间内下发的消息数；

若大于，且判断若未扣减所述CP的信用度系数，则将该CP的违约次数加1；当判断若该CP的违约次数大于3次时，则扣减该CP的信用度系数并记录；

若大于，且判断若已扣减所述CP的信用度系数，则不改变当前信用度系数记录。

6.一种控制业务下发流量的系统，包括业务管理平台和内容提供平台CP，其特征在于，

所述业务管理平台包括系统资源收集模块和业务流量控制模块，所述CP包括下发控制模块，其中：

所述下发控制模块，用于进行业务的下发时，向所述系统资源收集模块发送该业务的业务下发消息；接收所述流量控制模块发送的流量控制消息，根据该流量控制消息调整下发的业务量，进行业务的下发；

所述系统资源收集模块，用于接收所述下发控制模块发送的所述业务下发消息，根据定期收集的资源信息和业务下发消息生成系统资源占用信息，上报给所述流量控制模块；

所述流量控制模块，用于根据接收的系统资源收集模块上报的系统资源占用信息，判断系统的资源是否过负荷，如果是，则生成并发送流量控制消息给所述下发控制模块，其中，所述流量控制模块根据生成的系统资源占用信息判断如果系统的资源过负荷，则确定调整后下发的业务量与原下发业务量的流量调整比率，根据该流量调整比率生成包含所述CP调整后设定时间内下发的业务下发消息数的流量控制消息，并发送给所述下发控制模块；其中，当所述流量控制模块判断系统的资源过负荷的情况是CPU占用率超过CPU占用率阈值时，确定调整后下发的业务量与原下发业务量的流量调整比率为：1-(该CPU占用率-CPU占用率阈值)/CPU占用率阈值；其中，当所述流量控制模块判断系统的资源过负荷的情况是每秒需要处理的业务下发消息数大于业务管理平台配置的每秒处理的业务下发消息能力数时，确定调整后下发的业务量与原下发业务量的流量调整比率为：1-(设定时间内需要处理的业务下发消息总数-该业务管理平台配置的设定时间内业务下发消息能力数)/该业务管理平台配置的设定时间内业务下发消息能力数；所述下发控制模块根据接收的所述流量控制消息调整下发的业务量，进行业务的下发，是指：所述下发控制模块根据接收的所述流量控制消息中所述CP调整后设定时间内下发的业务下发消息数，调整下发的业务量，进行业务的下发。

7.如权利要求6所述的系统，其特征在于，

所述系统资源收集模块生成的所述系统资源占用信息包括：CPU占用率、消息队列中未处理的业务下发消息数、设定时间内系统收到的业务下发消息总数以及各CP在设定时间内下发的业务下发消息数。

8.如权利要求7所述的系统，其特征在于，

所述流量控制模块根据生成的系统资源占用信息判断如果系统的资源过负荷，是通过以下方式完成：

所述流量控制模块根据所述系统资源占用信息中CPU占用率，判断该CPU占用率是否超过CPU占用率阈值，若是，则判定系统的资源过负荷；

或者所述流量控制模块根据所述系统资源占用信息，判断每秒需要处理的业务下发消息数是否大于该业务管理平台配置的每秒处理的业务下发消息能力数，若是，则判定系统的资源过负荷；其中，所述每秒需要处理的业务下发消息数是通过所述设定时间内系统收到的业务下发消息总数加上所述消息队列中未处理的业务下发消息数的和，除以设定时间的秒数得到的数值；

或者所述流量控制模块根据所述系统资源占用信息中CPU占用率，判断该CPU占用率是否超过CPU占用率阈值，若没有，则判断每秒需要处理的业务下发消息数是否大于该业务管理平台配置的每秒处理的业务下发消息能力数，若是，则判定系统的资源过负荷。

9.如权利要求6所述的系统，其特征在于，

所述系统资源收集模块定期收集的所述资源信息包括所述CP的优先级系数和信用度系数；

所述流量控制模块生成所述流量控制消息并发送给所述下发控制模块，是指：

所述流量控制模块根据所述CP在设定时间内下发的业务下发消息数、所述流量调整比率、所述CP的优先级系数与所述CP的信用度系数相乘得到的数值，确定该CP调整后设定时间内下发的消息数，生成包含该CP调整后设定时间内下发的消息数的流量控制消息并发送给所述下发控制模块。

10.如权利要求9所述的系统，其特征在于，

所述系统资源收集模块，还用于根据收集的所述资源信息，判断若包含已发送流量控制消息的CP，则判断该CP在设定时间内下发的业务下发消息数是否大于所述流量控制消息中所指示的该CP设定时间内下发的消息数；

若大于，且判断若未扣减所述CP的信用度系数，则将该CP的违约次数加1；当判断若该CP的违约次数大于3次时，则扣减该CP的信用度系数并记录；

若大于，且判断若已扣减所述CP的信用度系数，则不改变当前信用度系数记录。

Images