CN101174986A - 动态反馈负载分发方法和装置 - Google Patents
动态反馈负载分发方法和装置 Download PDFInfo
- Publication number
- CN101174986A CN101174986A CNA2007101662574A CN200710166257A CN101174986A CN 101174986 A CN101174986 A CN 101174986A CN A2007101662574 A CNA2007101662574 A CN A2007101662574A CN 200710166257 A CN200710166257 A CN 200710166257A CN 101174986 A CN101174986 A CN 101174986A
- Authority
- CN
- China
- Prior art keywords
- destination
- message
- key parameter
- module
- decision
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Processing Of Solid Wastes (AREA)
Abstract
本发明提供了一种动态反馈负载分发方法和装置,其中,该方法包括以下步骤:步骤一,通过关键参数采集模块收集多个目的端中的每个目的端的关键参数,并将关键参数发送至决策模块;步骤二,决策模块对关键参数进行分析,以确定每个目的端的处理能力;以及步骤三,当接收到来自源端的信息时,消息处理模块根据保存在消息处理模块中的关于每个目的端的处理能力来分发消息。因此,采用本发明,可以收集各目的端相关信息,通过分析比较,实时选择当前处理能力较强的目的端作为分发目标,较之轮询、根据IP或用户号码配置选择路由等静态分发方式更为灵活、主动,适应性更强。
Description
技术领域
本发明涉及通信领域,更具体地,涉及一种动态反馈负载分发方法和装置。
背景技术
多目的端负载均衡是网络系统中的常见技术,该技术提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效方法,既可加强网络数据处理能力,又可提高网络的灵活性及可用性。其主要作用有两点:保证高可靠性,一旦负载均衡的某目的端出现故障,其它目的端可以接替其工作;以及节约成本,不必额外使用热备份技术保证可靠性而增加设备成本。
常见的负载均衡技术如下:轮询(Simple Round Robin)方式和权重轮询(Weighted Round Robin)方式。
一、轮询方式
各目的端轮流处理请求消息。该方式对应用服务器的硬件环境、操作系统乃至应用软件没有要求,各目的端相对独立;无需为实现负载均衡而增加软硬件投资,是最简单、最传统的多目的端负载均衡方式,但该方式在功能和性能上存在如下问题:可靠性无法保证,当某目的端宕机,分发进程无法发现,例如在3台目的端系统中,如1台宕机,将有1/3消息无法响应,严重影响系统服务质量;以及负荷分担不一定合理,各目的端性能可有差异,在性能不同的目的端间平均分配请求,性能差的目的端可能成为系统瓶颈,而性能好的目的端资源没有被充分利用,造成投资浪费。
二、权重轮询方式
权重轮询是轮询分发的改进版本,即为各个目的端配置不同权重,请求消息按权重比例分发到各个目的端。
虽然,上述方式规避了轮询方式中因设备处理能力差异造成的“不公平”现象,但目的端的突发进程可能在某时间段内大量占用该设备的系统资源,权重轮询方式无法检测这种异常,从而影响处理性能。
发明内容
为了解决现有技术中的问题,本发明提出了一种动态反馈负载分发方法和装置,用于在多个目的端与源端之间动态分发消息。
根据本发明的动态反馈负载分发方法包括以下步骤:步骤一,通过关键参数采集模块收集多个目的端中的每个目的端的关键参数,并将关键参数发送至决策模块;步骤二,决策模块对关键参数进行分析,以确定每个目的端的处理能力;以及步骤三,当接收到来自源端的信息时,消息处理模块根据保存在消息处理模块中的关于每个目的端的处理能力来分发消息。
其中,关键参数是由CPU占用率、内存占用率、和消息队列积压长度构成的组合,或由消息队列积压长度、消息反馈时延、和超时消息个数构成的组合。
当目的端是可编程系统时,关键参数包括:CPU占用率、内存占用率、和消息队列积压长度,它们是目的端的本地数据,本地数据是通过以下方式提供给关键参数采集模块的:反馈机制、通信、或共享数据库。
当目的端是第三方系统时,关键参数包括:消息队列积压长度、消息反馈时延、和超时消息个数。
在步骤二中,执行以下处理:决策模块得到每个目的端的一个负载指数;以及决策模块根据负载指数判断目的端的处理能力。
其中,负载指数与消息队列积压长度、消息反馈时延、和超时消息个数相关联。负载指数小,则表示消息队列积压长度、消息反馈时延、或超时消息个数的延迟小,目的端的处理能力好。与消息队列积压长度相关联的负载指数所表征的延迟能力最小,与超时消息个数相关联的负载指数所表征的延迟能力最大,以及与消息反馈时延相关联的负载指数所表征的延迟能力居中。
另外,在步骤二中还执行以下处理:通过一个过载检测模块确定目的端是否过载;当目的端过载时,过载检测模块向决策模块发送一个过载处理命令,从而减少目的端的负载。
当每个目的端都过载时,则决策模块进入降级模式,限制源端发送的消息的数量。
而当过载检测模块判断每个目的端过载成断链时,目的端不接收消息。
在步骤三中执行以下处理:消息处理模块接收到来自源端的消息;消息处理模块向决策模块发出取决策指令;以及消息处理模块根据决策模块返回的关于每个目的端的处理能力来分发消息。
本发明还提供了一种动态反馈负载分发装置,用于在多个目的端与源端之间动态分发消息,该装置包括:关键参数采集模块,用于收集多个目的端中的每个目的端的关键参数,并将关键参数发送至决策模块;决策模块,用于对关键参数进行分析,以确定每个目的端的处理能力,并将处理能力发送给消息处理模块;以及消息处理模块,用于接收来自源端的信息,并根据每个目的端的处理能力来分发消息。
另外,该装置还包括:过载检测模块,用于分析关键参数,并根据关键参数配置门限来确定目的端是否过载。
其中,过载检测模块还用于当目的端过载时,启动过载机制,降低目的端的消息的数量,并且当每个目的端都过载时,启动降级机制。
关键参数是由CPU占用率、内存占用率、和消息队列积压长度构成的组合,或由消息队列积压长度、消息反馈时延、和超时消息个数构成的组合。
因此,采用本发明的方法和装置,可以收集各目的端相关信息,通过分析比较,实时选择当前处理能力较强的目的端作为分发目标,较之轮询、根据IP或用户号码配置选择路由等静态分发方式更为灵活、主动,适应性更强。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例一起用于解释本发明,并不构成对本发明的限制。在附图中:
图1是根据本发明的动态反馈负载分发方法的流程图;
图2是根据本发明的动态反馈负载分发装置的框图;
图3是根据本发明实施例的动态反馈负载分发装置的框图;以及
图4是在图3中所示装置中执行的具体消息流程图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明。
图1是根据本发明的动态反馈负载分发方法的流程图。如图1所示,包括以下步骤:
步骤S102,通过关键参数采集模块收集多个目的端中的每个目的端的关键参数,并将关键参数发送至决策模块;
步骤S104,决策模块对关键参数进行分析,以确定每个目的端的处理能力;以及
步骤S106,当接收到来自源端的信息时,消息处理模块根据保存在消息处理模块中的关于每个目的端的处理能力来分发消息。
其中,关键参数是由CPU占用率、内存占用率、和消息队列积压长度构成的组合,或由消息队列积压长度、消息反馈时延、和超时消息个数构成的组合。
当目的端是可编程系统时,关键参数包括:CPU占用率、内存占用率、和消息队列积压长度,它们是目的端的本地数据,本地数据是通过以下方式提供给关键参数采集模块的:反馈机制、通信、或共享数据库。
当目的端是第三方系统时,关键参数包括:消息队列积压长度、消息反馈时延、和超时消息个数。
在步骤S104中,执行以下处理:决策模块得到每个目的端的一个负载指数;以及决策模块根据负载指数判断目的端的处理能力。
其中,负载指数与消息队列积压长度、消息反馈时延、和超时消息个数相关联。负载指数小,则表示消息队列积压长度、消息反馈时延、或超时消息个数的延迟小,目的端的处理能力好。与消息队列积压长度相关联的负载指数所表征的延迟能力最小,与超时消息个数相关联的负载指数所表征的延迟能力最大,以及与消息反馈时延相关联的负载指数所表征的延迟能力居中。
另外,在步骤S104中还执行以下处理:通过一个过载检测模块确定目的端是否过载;当目的端过载时,过载检测模块向决策模块发送一个过载处理命令,从而减少目的端的负载。
当每个目的端都过载时,则决策模块进入降级模式,限制源端发送的消息的数量。
而当过载检测模块判断每个目的端过载成断链时,目的端不接收消息。
在步骤S106中执行以下处理:消息处理模块接收到来自源端的消息;消息处理模块向决策模块发出取决策指令;以及消息处理模块根据决策模块返回的关于每个目的端的处理能力来分发消息。
图2是根据本发明的动态反馈负载分发装置200的框图。如图2所示,该装置包括:关键参数采集模块202,用于收集多个目的端中的每个目的端的关键参数,并将关键参数发送至决策模块204;决策模块204,用于对关键参数进行分析,以确定每个目的端的处理能力,并将处理能力发送给消息处理模块206;以及消息处理模块206,用于接收来自源端的信息,并根据每个目的端的处理能力来分发消息。
另外,该装置还包括:过载检测模块,用于分析关键参数,并根据关键参数配置门限来确定目的端是否过载。
其中,过载检测模块还用于当目的端过载时,启动过载机制,降低目的端的消息的数量,并且当每个目的端都过载时,启动降级机制。
关键参数是由CPU占用率、内存占用率、和消息队列积压长度构成的组合,或由消息队列积压长度、消息反馈时延、和超时消息个数构成的组合。
应了解,本发明主要在于关键参数的选择,而设备处理能力不同,表征设备处理能力的参数很多。表征参数的选择应以普适、公平为原则。
在本发明中,CPU占用率、内存占用率、消息队列积压长度为目的端本地数据,而消息反馈时延、超时消息个数可内部收集。目的端本地数据需要某种机制才能进行反馈给该动态反馈负载分发装置,或通信,或共享数据库。
由此,产生两点问题:其一,若目的端为可编程系统,则反馈机制不难实现,若目的端为第三方系统,则反馈机制无法实现,实际上本发明在应用中恰恰属于后者,由此目的端本地数据无法获得;其二,即便目的端参数得以反馈,若目的端本身非常繁忙,以至于参数根本无法反馈,该繁忙目的端承受的消息流量反而可能更大。
采用消息反馈时延、超时消息个数作为关键参数固然可以说明问题,但略显单薄,经过论证,最终在发明中实现消息队列来为目的端负载提供参数。具体做法是缓存已发送但未收到响应的消息,以此消息个数作为第三组关键参数。综上,将消息反馈时延、超时消息个数及消息队列积压长度作为关键参数。
接下来,对已获取的关键参数的决策分析成为本发明的第二个关键问题。分发策略决策的总体思路是对每个目的端维护一个负载指数,此指数越小表征此目的端状况越好,从而加大该目的端消息流量。负载指数受消息反馈时延、超时消息个数及消息队列积压长度影响,此参数反映消息积压的严重程度有所不同。为体现各参数的综合效果,特为每种参数分配一定的权重。
当某种事件(某条消息超时、消息队列个数加一)发生时,该目的端的负载指数对应增加相应权重,当该事件消失时该目的端的负载指数对应减少相应权重。
其中,消息队列积压长度的延迟表征能力最小,权重设为1,即当一条请求消息发送到某目的端后,该目的端消息队列加入该消息,同时该目的端负载指数加1;当收到该消息响应后,该目的端消息队列删除该消息,同时该目的端负载指数减1。
超时消息个数的延迟表征能力最大,权重设定为10,即当某条消息响应超时后,该目的端负载指数加10。消息超时无法自动恢复,采取定时清零策略——每隔30秒清除负载指数中的超时成分。与此类似,消息反馈平均时延也无法自动恢复,采取同样策略清零。
消息反馈时延的延迟表征能力居中,权重设定为3。需要在系统中配置时延门限(例如2秒),每隔很短时间(例如0.1秒)检测在此时间段内平均时延是否超过门限,如果超过,则该目的端负载指数加3,由于平均时延的不可恢复性,采取超时参数恢复的相同机制,即定时清零。为灵活适应不同系统,各项权重值应可灵活配置。
当检测到目的端负荷过大时,即可认为此目的端过载,相应地启动过载处理机制,减轻其负载。具体过程如下:过载的标准需人为判定,可采取配置方式。过载又可根据严重程度分为5级。例如:消息队列积压长度达到10000认为1级过载,达到20000认为2级过载,达到50000认为5级过载;消息反馈平均时延达到2秒认为1级过载,3秒认为2级过载,6秒认为5级过载;一段时间内超时消息个数达到100认为1级过载,200认为2级过载,500认为5级过载。三组参数中取过载级别最大者作为该目的端的过载级别,当目的端过载后,将其负载指数增加一定值,使其在短时间内由于负载指数过高无法收到消息,从而达到减轻负荷的目的。若所有目的端均呈过载状态,则进入降级模式,限制上游设备发送消息数量,直到降级恢复。
应了解,过载最严重的状态即为断链,此时该目的端失去接收消息的能力,直到链路恢复并稳定。为此需要设置心跳检测消息,当连续若干次收不到心跳检测即认为断链,将该目的端置为“关闭”状态,直到其链路恢复。
在实际运行中发现,在消息流量不大时,各目的端的负载指数往往为零,即使话务量较大,负载指数相等情况时有发生。由此需引入轮询分发机制,否则无法称为负载均衡。经过测试,此优化引入后,负载均衡效果更为明显。
为防止负载指数越界,可定时将所有负载指数统一减少一定数值,此优化不影响负载能力表征。
在本发明中所谓的会话,指只能由同一目的端处理的一组相关消息,例如,通信领域中一次呼叫中的计费更新消息。在会话类消息系统中,鉴于会话类消息的单一目的端特性,可将各目的端当前会话个数作为第四个负载指数,权重设定为3,当新增一条会话时负载指数加3,结束会话时负载指数减3。
图3是本发明实施例的动态反馈负载分发装置300的框图。如图3所示,包括以下模块:消息处理模块302,负责消息发送、接收的具体实现,从决策模块获得目的端地址,从过载检测模块获取过载处理命令,通过底层平台或操作系统的相关机制完成消息发送、接收;关键参数采集模块304,采集并存储表征目的端处理能力的关键数据,以备决策模块分析,其中,关键参数的选择非常重要;决策模块306,分析若干关键参数,判断目的端的当前处理能力,为本发明的核心模块;以及过载检测模块308,定时分析关键参数,根据配置门限判断某目的端是否过载,过载则启动过载机制,降低该目的端的消息流量,若所有目的端均过载则启动降级机制。
在图3中,源端作为消息来源,将消息通过上述各个模块分发给诸目的端。而目的端作为消息的目的地,需要符合请求-响应机制,在本发明中,同时存在多个目的端,以供分担负荷。
图4是在图3中所示的动态反馈负载分发装置中执行的具体消息流程图。如图4所示,消息分发流程如下:
第一步,存在两个目的端A、B,源端开始发送消息,所有目的端权重均为0;
第二步,按照轮询方式发送消息给目的端A,将此消息加入缓存队列,同时目的端A负载指数因缓存队列增加而加1,因会话数增加而加3,负载指数为4;
第三步,收到第二条消息,A负载指数较高,消息发送给目的端B,B的负载指数为4;
第四步,收到第三条消息,由于负载指数均为4,按轮询方式消息发送给B,B的负载指数为8;
第五步,一段时间后发送给A的消息出现超时,A的负载指数加10;
第六步,上个0.1秒内B的平均处理时延超过门限2秒,B的负载指数加3;
第七步,继续根据各自负载指数分发消息,30秒后,将负载指数中超时和时延成分清零;
第八步,话务量增大,目的端A消息队列长度超过过载门限10000,达到11000,消息超时个数超过超时门限100,达到278,平均时延超过门限2秒,达到3秒,取最大值,目的端A的过载级别为3级过载,将其负载指数增加300×3,一段时间内,目的端A无法收到消息,得到休息,负载参数回落;
第九步,因同样原因目的端B与A同时过载,进入降级模式,根据降级级别屏蔽源端20%消息,并通知源端;以及
第十步,目的端A断链,将目的端A状态关闭,目的端B独自承担负载。
因此,根据若干目的端实体的处理特性,动态分析目的端处理能力,从中选出最优处理设备,既保证通信消息高效、准确得到响应,又保证目的端实体量力处理的请求消息。
综上所述,采用本发明的方法和装置,可以收集各目的端相关信息,通过分析比较,实时选择当前处理能力较强的目的端作为分发目标,较之轮询、根据IP或用户号码配置选择路由等静态分发方式更为灵活、主动,适应性更强。
本发明适用于目的端为请求-响应模式的通信系统,在若干目的端并存的情况下,通过本发明主动、动态收集目的端的关键信息,加以分析整理,计算出当前处理能力较强的目的端,将消息发给该端;同时分析出异常过载目的端,暂时减少其负荷。
以上仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (16)
1.一种动态反馈负载分发方法,用于在多个目的端与源端之间动态分发消息,其特征在于,包括以下步骤:
步骤一,通过关键参数采集模块收集所述多个目的端中的每个目的端的关键参数,并将所述关键参数发送至决策模块;
步骤二,所述决策模块对所述关键参数进行分析,以确定所述每个目的端的处理能力;以及
步骤三,当接收到来自所述源端的所述信息时,所述消息处理模块根据保存在所述消息处理模块中的关于所述每个目的端的处理能力来分发所述消息。
2.根据权利要求1所述的方法,其特征在于,所述关键参数是由CPU占用率、内存占用率、和消息队列积压长度构成的组合,或由消息队列积压长度、消息反馈时延、和超时消息个数构成的组合。
3.根据权利要求2所述的方法,其特征在于,当所述目的端是可编程系统时,所述关键参数包括:CPU占用率、内存占用率、和消息队列积压长度,它们是所述目的端的本地数据,
所述本地数据是通过以下方式提供给所述关键参数采集模块的:反馈机制、通信、或共享数据库。
4.根据权利要求2所述的方法,其特征在于,当所述目的端是第三方系统时,所述关键参数包括:消息队列积压长度、消息反馈时延、和超时消息个数。
5.根据权利要求4所述的方法,其特征在于,在所述步骤二中,执行以下处理:
所述决策模块得到所述每个目的端的一个负载指数;以及
所述决策模块根据所述负载指数判断所述目的端的处理能力。
6.根据权利要求5所述的方法,其特征在于,所述负载指数与所述消息队列积压长度、消息反馈时延、和超时消息个数相关联。
7.根据权利要求6所述的方法,其特征在于,
所述负载指数小,则表示所述消息队列积压长度、消息反馈时延、或超时消息个数的延迟小,所述目的端的处理能力好。
8.根据权利要求7所述的方法,其特征在于,
与所述消息队列积压长度相关联的负载指数所表征的延迟能力最小,
与所述超时消息个数相关联的负载指数所表征的延迟能力最大,以及
与所述消息反馈时延相关联的负载指数所表征的延迟能力居中。
9.根据权利要求5所述的方法,其特征在于,在所述步骤二中还执行以下处理:
通过一个过载检测模块确定所述目的端是否过载;
当所述目的端过载时,所述过载检测模块向所述决策模块发送一个过载处理命令,从而减少所述目的端的负载。
10.根据权利要求9所述的方法,其特征在于,在所述步骤二中,
当每个所述目的端都过载时,则所述决策模块进入降级模式,限制所述源端发送的所述消息的数量。
11.根据权利要求9所述的方法,其特征在于,在所述步骤二中,
当所述过载检测模块判断所述每个目的端过载成断链时,所述目的端不接收所述消息。
12.根据权利要求1所述的方法,其特征在于,在所述步骤三中执行以下处理:
所述消息处理模块接收到来自所述源端的所述消息;
所述消息处理模块向所述决策模块发出取决策指令;以及
所述消息处理模块根据所述决策模块返回的关于所述每个目的端的处理能力来分发所述消息。
13.一种动态反馈负载分发装置,用于在多个目的端与源端之间动态分发消息,其特征在于,包括:
关键参数采集模块,用于收集所述多个目的端中的每个目的端的关键参数,并将所述关键参数发送至决策模块;
所述决策模块,用于对所述关键参数进行分析,以确定每个所述目的端的处理能力,并将所述处理能力发送给所述消息处理模块;以及
消息处理模块,用于接收来自所述源端的所述信息,并根据每个所述目的端的处理能力来分发所述消息。
14.根据权利要求13所述的装置,其特征在于,还包括:
过载检测模块,用于分析所述关键参数,并根据所述关键参数配置门限来确定所述目的端是否过载。
15.根据权利要求13所述的装置,其特征在于,所述过载检测模块还用于当所述目的端过载时,启动过载机制,降低所述目的端的所述消息的数量,并且当每个所述目的端都过载时,启动降级机制。
16.根据权利要求13所述的装置,其特征在于,所述关键参数是由CPU占用率、内存占用率、和消息队列积压长度构成的组合,或由消息队列积压长度、消息反馈时延、和超时消息个数构成的组合。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101662574A CN101174986A (zh) | 2007-11-07 | 2007-11-07 | 动态反馈负载分发方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101662574A CN101174986A (zh) | 2007-11-07 | 2007-11-07 | 动态反馈负载分发方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101174986A true CN101174986A (zh) | 2008-05-07 |
Family
ID=39423259
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2007101662574A Pending CN101174986A (zh) | 2007-11-07 | 2007-11-07 | 动态反馈负载分发方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101174986A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102281190A (zh) * | 2011-07-01 | 2011-12-14 | 杭州斯凯网络科技有限公司 | 负载均衡装置组网方法以及服务器、客户端接入方法 |
CN102480529A (zh) * | 2010-11-24 | 2012-05-30 | 北京无线恒远科技有限公司 | 实现广域网负载均衡的域名解析方法及域名解析服务器 |
CN102761832A (zh) * | 2011-04-28 | 2012-10-31 | 中国移动通信集团河南有限公司 | 一种消息分发方法以及消息分发装置 |
CN108540557A (zh) * | 2018-04-16 | 2018-09-14 | 江苏润和软件股份有限公司 | 一种基于动态限速的云应用负载调度方法 |
CN108712494A (zh) * | 2018-05-18 | 2018-10-26 | 阿里巴巴集团控股有限公司 | 处理异步消息的方法、装置及设备 |
CN108718338A (zh) * | 2018-05-23 | 2018-10-30 | 深圳市茁壮网络股份有限公司 | 一种节点确定方法及装置 |
WO2021147304A1 (zh) * | 2020-01-20 | 2021-07-29 | 中国银联股份有限公司 | 一种基于异步应答的传输数据的方法及系统 |
-
2007
- 2007-11-07 CN CNA2007101662574A patent/CN101174986A/zh active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102480529A (zh) * | 2010-11-24 | 2012-05-30 | 北京无线恒远科技有限公司 | 实现广域网负载均衡的域名解析方法及域名解析服务器 |
CN102761832A (zh) * | 2011-04-28 | 2012-10-31 | 中国移动通信集团河南有限公司 | 一种消息分发方法以及消息分发装置 |
CN102761832B (zh) * | 2011-04-28 | 2015-05-27 | 中国移动通信集团河南有限公司 | 一种消息分发方法以及消息分发装置 |
CN102281190A (zh) * | 2011-07-01 | 2011-12-14 | 杭州斯凯网络科技有限公司 | 负载均衡装置组网方法以及服务器、客户端接入方法 |
CN102281190B (zh) * | 2011-07-01 | 2014-06-11 | 杭州斯凯网络科技有限公司 | 负载均衡装置组网方法以及服务器、客户端接入方法 |
CN108540557A (zh) * | 2018-04-16 | 2018-09-14 | 江苏润和软件股份有限公司 | 一种基于动态限速的云应用负载调度方法 |
CN108712494A (zh) * | 2018-05-18 | 2018-10-26 | 阿里巴巴集团控股有限公司 | 处理异步消息的方法、装置及设备 |
CN108718338A (zh) * | 2018-05-23 | 2018-10-30 | 深圳市茁壮网络股份有限公司 | 一种节点确定方法及装置 |
WO2021147304A1 (zh) * | 2020-01-20 | 2021-07-29 | 中国银联股份有限公司 | 一种基于异步应答的传输数据的方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
USRE49512E1 (en) | System, device, and method of media delivery optimization | |
CN101174986A (zh) | 动态反馈负载分发方法和装置 | |
CN100396016C (zh) | 在内容分发网络中保障服务水平的系统和方法 | |
US7486621B2 (en) | Method and apparatus for load sharing and overload control for packet media gateways under control of a single media gateway controller | |
EP2661020B1 (en) | Adaptive monitoring of telecommunications networks | |
US20190182351A1 (en) | Route selection method and system, network acceleration node, and network acceleration system | |
US7730269B2 (en) | Load management to reduce communication signaling latency in a virtual machine environment | |
CN101502050B (zh) | 空闲模式通知 | |
CN101188509B (zh) | 一种为网络服务提供服务质量保证的方法、系统 | |
CN101631360B (zh) | 负载均衡的实现方法、装置和系统 | |
CN103369601A (zh) | 为手机客户端提供大并发处理及流量控制的方法 | |
US8305911B2 (en) | System and method for identifying and managing service disruptions using network and systems data | |
CN101189895A (zh) | 异常检测方法和系统以及维护方法和系统 | |
CA2293468A1 (en) | A telecommunications performance management system | |
CN101321090A (zh) | 性能数据的统计方法和装置 | |
CN100542175C (zh) | 一种多处理单元负载均衡方法和多处理单元系统 | |
CN103229462A (zh) | 一种最优路径选择方法、相关设备及通信系统 | |
CN102984184A (zh) | 一种分布式系统的服务负载均衡方法及装置 | |
CN101409654B (zh) | 一种网络管理系统中处理snmp信息的方法 | |
CN111049673A (zh) | 一种服务网关中api调用统计和监控的方法及系统 | |
CN112491961A (zh) | 调度系统及方法、cdn系统 | |
CN101459924A (zh) | 一种gsm系统业务跟踪和异常管理的方法、装置及系统 | |
CN110753002B (zh) | 流量调度方法及装置 | |
CN102316483A (zh) | 一种EVDO系统中保证应用业务QoS的方法及装置 | |
US7969887B2 (en) | Station |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20080507 |