CN115421889A - 进程间的请求管理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种进程间的请求管理方法、装置、电子设备及存储介质，所述方法包括：在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，将所述长连接的请求队列中新增的超量请求推送入补发队列，并在所述补发队列中为所述超量请求分别注册对应的信号；响应于检测到处于正常工作状态的长连接释放资源，从所述补发队列中取出信号，通过所取出信号唤醒所述补发队列绑定的补发线程，并通过所唤醒补发线程发送所述超量请求。本申请实施例降低了请求丢失的可能性的同时，降低了请求处理耗时。

Description

进程间的请求管理方法、装置、电子设备及存储介质

技术领域

本申请涉及游戏领域，具体涉及一种进程间的请求管理方法、装置、电子设备及存储介质。

背景技术

在业务量较大的网络应用场景(例如游戏领域中的业务高峰场景)中，进程之间常常会存在大量需要转发的并发请求。现有技术中，一旦两个进程间之间所有的长连接处于繁忙工作状态，便很容易导致请求丢失或者导致请求处理耗时增大，不利于业务进展。

发明内容

本申请的一个目的在于提出一种进程间的请求管理方法、装置、电子设备及存储介质，降低了请求丢失的可能性的同时，降低了请求处理耗时。

根据本申请实施例的一方面，公开了一种进程间的请求管理方法，所述方法包括：

在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，为所述长连接的请求队列中新增的超量请求生成对应的请求任务；

将所述请求任务推送入补发队列，并在所述补发队列中为所述请求任务分别注册对应的信号；

响应于检测到处于正常工作状态的长连接释放资源，从所述补发队列中取出信号，通过所取出信号唤醒所述补发队列绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

根据本申请实施例的一方面，公开了一种进程间的请求管理装置，所述装置包括：

任务生成模块，配置为在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，为所述长连接的请求队列中新增的超量请求生成对应的请求任务；

任务入队模块，配置为将所述请求任务推送入补发队列，并在所述补发队列中为所述请求任务分别注册对应的信号；

任务出队模块，配置为响应于检测到处于正常工作状态的长连接释放资源，从所述补发队列中取出信号，通过所取出信号唤醒所述补发队列绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

根据本申请实施例的一方面，公开了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现以上任一项实施例。

根据本申请实施例的一方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行以上任一项实施例。

根据本申请实施例的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的方法。

本申请实施例中，在进程间的长连接数量达到该连接上限值，并且各个长连接均处于繁忙工作状态时，为超量请求生成对应的请求任务。将请求任务推送入补发队列，并在补发队列中为请求任务分别注册对应的信号。相应于监测到处于正常工作状态的长连接释放资源，从补发队列中取出信号，进而通过所取出信号唤醒补发队列绑定的补发线程，通过所唤醒补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。通过这种方式，本申请能够对超量请求暂时搁置，避免超量请求对进程间所有长连接所能处理请求上限造成威胁，降低了请求丢失的可能性；并且，无需将超量请求移出请求队列，避免了频繁地对请求出队处理的同时，也无需特别对请求队列进行加锁解锁处理，降低了请求处理耗时。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

通过参考附图详细描述其示例实施例，本申请的上述和其它目标、特征及优点将变得更加显而易见。

图1示出了根据本申请一个实施例的所应用服务器集群的部署示意图。

图2示出了根据本申请一个实施例的进程之间的长连接示意图。

图3示出了根据本申请一个实施例的进程间的请求管理方法的流程图。

图4示出了根据本申请一个实施例的请求队列和补发队列的组织示意图。

图5示出了根据本申请一个实施例的进程间的请求管理装置的框图。

图6示出了根据本申请一个实施例的电子设备硬件图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本申请的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本申请的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本申请的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本申请的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本申请提供了一种进程间的请求管理方法，主要应用于服务器集群，对服务器集群进程之间的请求进行管理，尽量避免丢失请求，尽量去维持所承载业务的正常。

图1示出了本申请一实施例的所应用服务器集群的部署示意图。图2示出了本申请一实施例的进程之间的长连接示意图。

参见图1和图2，在游戏领域中，由于用户基数大，因此游戏的网络系统需要大量的服务器组成服务器集群来承载业务。客户端的请求穿过网关先进入服务器集群A，然后服务器集群A的进程(图2所示的进程A1、A2……A100)作为请求方，向服务器集群B的进程(图2所示的进程B1、B2……B200)发起大量的并发请求。在这种情况下，服务器集群A中的请求方进程和服务器集群B中的被请求方进程之间，需要保持多个长连接来提高请求的并发效率。其中，服务器集群A中的请求方可以为游戏系统的玩家逻辑服务器，服务器集群B中的被请求方可以为游戏系统的数据库缓存服务器。

若服务器集群A中的请求方进程和服务器集群B中的被请求方进程之间的请求发生丢失，轻则影响玩家体验，重则导致玩家重要数据丢失。因此，为维持游戏业务的正常，需要对服务器集群A中的请求方进程和服务器集群B中的被请求方进程之间的请求进行管理，尽量避免丢失请求。

图3示出了本申请所提供进程间的请求管理方法的流程图，该方法的示例性执行主体为服务器，该方法包括：

步骤S110、在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，为长连接的请求队列中新增的超量请求生成对应的请求任务；

步骤S120、将请求任务推送入补发队列，并在补发队列中为请求任务分别注册对应的信号；

步骤S130、响应于检测到处于正常工作状态的长连接释放资源，从补发队列中取出信号，通过所取出信号唤醒补发队列绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

本申请实施例中，进程间建立一个或多个长连接，各个长连接维护对应的请求队列，通过对请求队列进行请求入队处理和请求出队处理，而实现进程间的请求转发。其中，进程间的长连接数量存在上限，称该上限为连接上限值，并记为N。N为大于0的整数。

在监测进程间的长连接数量的同时，监测各个长连接的工作状态，以确认各个长连接是否处于繁忙工作状态。需要说明的是，处于繁忙工作状态，代表长连接的空闲资源有限，但并不代表长连接不具备任何的空闲资源。

在进程间的长连接数量达到该连接上限值N，并且各个长连接均处于繁忙工作状态时，将在这种情况下请求队列中新增的请求作为超量请求。针对超量请求，为其生成对应的请求任务。进而将请求任务推送入补发队列，并在补发队列中为超量请求分别注册对应的信号signal。不同的超量请求，对应不同的信号signal。

本申请实施例中，还为补发队列绑定有对应的线程，称该绑定的线程为补发线程，通过该补发线程控制补发队列中请求任务的出队，进而通过请求任务的出队，控制发送对应的超量请求。不同的补发队列，绑定有不同的补发线程。

超量请求的产生，说明进程间所有长连接所能处理请求上限被突破的可能性较高。因此，本申请实施例中，在进程间的长连接数量达到该连接上限值N，并且各个长连接均处于繁忙工作状态时，通过补发队列机制将超量请求暂时搁置，只针对长连接对应的请求队列进行入队处理和出队处理。

具体的，在处于正常工作状态的长连接释放资源时，说明进程间所有长连接所能处理请求上限被突破的可能性较低，这种情况下进程间所有长连接具有一定的富余资源去处理积累的超量请求。因此，本申请实施例中，响应于监测到处于正常工作状态的长连接释放资源，从补发队列中取出信号，进而通过所取出信号唤醒补发队列绑定的补发线程出队所取出信号对应的请求任务，从而发送所取出信号对应的超量请求。

在本申请所提供补发队列机制的作用下，能够对超量请求暂时搁置，避免超量请求对进程间所有长连接所能处理请求上限造成威胁，降低了请求丢失的可能性。并且，本申请所提供补发队列机制在暂时搁置超量请求时，无需将超量请求移出请求队列，避免了频繁地对请求出队处理的同时，也无需特别对请求队列进行加锁解锁处理，降低了请求处理耗时。

综上可见，本申请实施例中，在进程间的长连接数量达到该连接上限值，并且各个长连接均处于繁忙工作状态时，为超量请求生成对应的请求任务。将请求任务推送入补发队列，并在补发队列中为请求任务分别注册对应的信号。相应于监测到处于正常工作状态的长连接释放资源，从补发队列中取出信号，进而通过所取出信号唤醒补发队列绑定的补发线程，通过所唤醒补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。通过这种方式，本申请能够对超量请求暂时搁置，避免超量请求对进程间所有长连接所能处理请求上限造成威胁，降低了请求丢失的可能性；并且，无需将超量请求移出请求队列，避免了频繁地对请求出队处理的同时，也无需特别对请求队列进行加锁解锁处理，降低了请求处理耗时。

在一实施例中，本申请所提供进程间的请求管理方法还包括：

通过各个补发队列绑定的补发线程，监测并更新对应补发队列绑定的系统信号量。

本实施例中，为各个补发队列绑定对应的补发线程的同时，还将各个补发队列绑定到系统信号量semaphore。补发线程实时监测着系统信号量，并在系统信号量发生变更时更新系统信号量。

在一实施例中，补发线程监测所绑定的补发队列中的请求任务是否超时或者是否无效，并清理超时或者无效的请求任务。

在一实施例中，本申请所提供进程间的请求管理方法还包括：

获取单个长连接在单位时间周期内的请求处理上限值，并获取预设的繁忙判定系数；

基于请求处理上限值与繁忙判定系数之间的乘积，检测长连接的工作状态。

本实施例中，通过预设的繁忙判定系数来判断长连接是否处于繁忙工作状态。

具体的，单个长连接在单位时间周期内所能正常处理的请求数量是有着对应上限的，称该上限为请求处理上限值，将其记为M。M为大于0的整数。

并且，针对长连接是否处于繁忙工作状态，预设有繁忙判定系数，将其记为Busy_rate。繁忙判定系数Busy_rate大于0小于1。

将请求处理上限值M与繁忙判定系数Busy_rate相乘，所得到的乘积描述了从请求数量的角度判断长连接繁忙与否的基准。因此，基于请求处理上限值M与繁忙判定系数Busy_rate之间的乘积M*Busy_rate，可以准确地从请求数量的角度检测长连接是否处于繁忙工作状态。

在一实施例中，基于请求数上限值与繁忙判定系数之间的乘积，检测长连接的工作状态，包括：

若在当前时间周期内处理请求的请求处理数小于或等于乘积，则确认对应长连接处于正常工作状态；

若请求处理数大于乘积并且小于请求处理上限值，则确认对应长连接处于繁忙工作状态；

若请求处理数大于或等于请求处理上限值，则确认对应长连接处于超限工作状态。

本实施例中，针对目标检测其是否处于繁忙工作状态的长连接，获取该长连接在当前时间周期内处理请求的请求数C，进而将C与请求处理上限值M与繁忙判定系数Busy_rate之间的乘积M*Busy_rate进行对比。

若C小于或等于M*Busy_rate，则确认该长连接处于正常工作状态。

若C大于M*Busy_rate，则进一步将C与M进行对比。若C大于M*Busy_rate，且小于M，则确认该长连接处于繁忙工作状态；若C不仅大于M*Busy_rate，还大于或等于M，则确认该长连接处于超限工作状态。处于超限工作状态，说明对应的长连接不具备任何的空闲资源。

在一实施例中，针对处于超限工作状态的长连接，若检测到对应请求队列中新增的超量请求的权重低于预设的权重阈值，则触发熔断，并返回请求错误信息。

本实施例中，若某一长连接处于超限工作状态，并且其请求队列中新增的超量请求的权重低于预设的权重阈值，则触发熔断，以保护进程安全，并返回请求错误信息。其中，若某一超量请求的权重低于权重阈值，说明该超量请求的重要性不高，可以被舍弃。

在一实施例中，将请求任务推送入补发队列，包括：

基于超量请求的业务类型，获取超量请求的权重；

将请求任务推送入匹配对应权重的补发队列。

本实施例中，按照权重，将超量请求推送入不同的补发队列。

具体的，检测到超量请求后，确认超量请求的业务类型，进而基于其业务类型确认其权重。

确认超量请求的权重后，将其对应的请求任务推送入与其权重相匹配的补发队列。同一权重的请求任务，被推送入同一补发队列；不同权重的请求任务，被推送入不同补发队列。

在一实施例中，响应于检测到处于正常工作状态的长连接释放资源，优先从对应权重高的补发队列中取出信号，进而通过所取出信号唤醒绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

例如：按照所匹配权重从高到低的顺序，对所有的三个补发队列进行排序后，得到的结果为——第一补发队列、第二补发队列和第三补发队列。

则响应于检测到处于正常工作状态的长连接释放资源，优先从第一补发队列中取出信号，进而通过所取出信号唤醒第一补发队列绑定的补发线程，出队第一补发队列中的请求任务，以发送所取出信号对应的超量请求。

在第一补发队列中的超量请求被清空后，响应于检测到处于正常工作状态的长连接释放资源，优先从第二补发队列中取出信号，进而通过所取出信号唤醒第二补发队列绑定的补发线程，出队第二补发队列中的请求任务，以发送所取出信号对应的超量请求。

在第二补发队列中的超量请求被清空后，响应于检测到处于正常工作状态的长连接释放资源，从第三补发队列中取出信号，进而通过所取出信号唤醒第三补发队列绑定的补发线程，出队第三补发队列中的请求任务，以发送所取出信号对应的超量请求。

在一实施例中，按照所匹配权重，为补发队列分配对应的选取概率。进而响应于检测到处于正常工作状态的长连接释放资源，按照选取概率从补发队列中取出信号，进而通过所取出信号唤醒绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

具体的，补发队列所匹配权重越高，分配得到的选取概率越大，在需要出队请求任务时越有可能被选中其中的信号，进而通过唤醒绑定的补发线程出队其中的请求任务。

例如：按照所匹配权重从高到低的顺序，对所有的三个补发队列进行排序后，得到的结果为——第一补发队列、第二补发队列和第三补发队列。为第一补发队列分配的选取概率为50％，为第二补发队列分配的选取概率为30％，为第三补发队列分配的选取概率为20％。

响应于检测到处于正常工作状态的长连接释放资源，需要取出一个信号时，根据随机数生成器，随机生成一个在0～1之间的数字rand。

若rand大于等于0，并且小于0.5，则从第一补发队列中取出一个信号，进而通过所取出信号唤醒第一补发队列绑定的补发线程，通过第一补发队列绑定的补发线程，出队第一补发队列中的请求任务，以发送所取出信号对应的超量请求。

若rand大于等于0.5，并且小于0.8，则从第二补发队列中取出一个信号，进而通过所取出信号唤醒第二补发队列绑定的补发线程，出队第二补发队列中的请求任务，以发送所取出信号对应的超量请求。

若rand大于等于0.8，并且小于1，则从第三补发队列中取出一个信号，进而通过所取出信号唤醒第三补发队列绑定的补发线程，出队第三补发队列中的请求任务，以发送所取出信号对应的超量请求。

在一实施例中，按照所匹配权重，计算补发队列的负载。进而按照负载，为补发队列分配对应的选取概率。进而响应于检测到处于正常工作状态的长连接释放资源，按照选取概率从补发队列中取出信号，进而通过所取出信号唤醒绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

具体的，可以采取将队列长度queue_len与权重pri相乘的方式，计算得到补发队列的负载load。其中，队列长度queue_len用于描述补发队列中的请求任务的个数。

并且，可以采取将单个补发队列的负载load除以所有补发队列的负载load之和的方式，计算得到补发队列对应的选取概率。补发队列的负载load越高，分配得到的选取概率越大，在需要出队请求任务时越有可能被选中其中的信号，进而通过唤醒绑定的补发线程出队其中的请求任务。

在一实施例中，若超量请求对应的权重高于预设的权重阈值，则拒绝将请求任务推送入补发队列。

本实施例中，只对权重低于权重阈值的超量请求进行暂时搁置，权重高于权重阈值的超量请求拒绝进行搁置。

具体的，考虑到对于业务而言，某些关键请求是必不可少且难以容忍拖延的，因此，本实施例中，通过预设的权重阈值来区分出这些关键请求，并在这些关键请求属于超量请求时，拒绝将其请求任务推送入补发队列，从而避免将其暂时搁置，以保证业务的实用性。

在一实施例中，权重高于预设的权重阈值的请求包括：约定的关键操作请求(例如：支付系统操作请求)、写操作请求。

权重低于权重阈值的请求包括：读操作请求、批量查询操作请求、约定的低权重操作。

图4示出了本申请一实施例的请求队列和补发队列的组织示意图。

参见图4，在一实施例中，当前进程与其他进程之间建立有长连接，各个长连接维护对应的请求队列，通过对请求队列进行请求入队处理和请求出队处理而实现请求转发。

在长连接数量达到连接上限值，并且均处于繁忙工作状态时，为新增的超量请求生成对应的请求任务。

根据超量请求的权重与预设的权重阈值进行对比。若高于预设的权重阈值，则拒绝将请求任务推送入补发队列；若低于权重阈值，则将其对应的请求任务推送入对应权重的补发队列中——第一补发队列对应的权重高于第二补发队列对应的权重，第二补发队列对应的权重高于第三补发队列对应的权重。

为各个补发队列绑定对应的补发线程thread，并绑定系统信号量semaphore，并为其中各个请求任务注册对应的信号signal。补发线程定期扫描补发队列，清理超时和无效的请求任务，并更新系统信号量。

响应于检测到处于正常工作状态的长连接释放资源，从其中一个补发队列取出队列头部的信号，判断是否超时。若超时，则清理掉；若未超时，则通过该信号唤醒补发队列绑定的补发线程出队该信号对应的请求任务，以发送该信号对应的超量请求，并更新系统信号量。

图5示出了根据本申请一实施例的进程间的请求管理装置的框图，所述装置包括：

任务生成模块210，配置为在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，为所述长连接的请求队列中新增的超量请求生成对应的请求任务；

任务入队模块220，配置为将所述请求任务推送入补发队列，并在所述补发队列中为所述请求任务分别注册对应的信号；

任务出队模块230，配置为响应于检测到处于正常工作状态的长连接释放资源，从所述补发队列中取出信号，通过所取出信号唤醒所述补发队列绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

在本申请的一示例性实施例中，所述装置配置为：

通过各个补发队列绑定的补发线程，监测并更新对应补发队列绑定的系统信号量。

在本申请的一示例性实施例中，所述装置配置为：

获取单个长连接在单位时间周期内的请求处理上限值，并获取预设的繁忙判定系数；

基于所述请求处理上限值与所述繁忙判定系数之间的乘积，检测所述长连接的工作状态。

在本申请的一示例性实施例中，所述装置配置为：

若在当前时间周期内处理请求的请求处理数小于或等于所述乘积，则确认对应长连接处于正常工作状态；

若所述请求处理数大于所述乘积并且小于所述请求处理上限值，则确认对应长连接处于繁忙工作状态；

若所述请求处理数大于或等于所述请求处理上限值，则确认对应长连接处于超限工作状态。

在本申请的一示例性实施例中，所述装置配置为：

针对处于超限工作状态的长连接，若检测到对应请求队列中新增的超量请求的权重低于预设的权重阈值，则触发熔断，并返回请求错误信息。

在本申请的一示例性实施例中，所述超量补发模块配置为：

基于所述超量请求的业务类型，获取所述超量请求的权重；

将所述请求任务推送入匹配对应权重的补发队列。

在本申请的一示例性实施例中，所述超量补发模块配置为：

若所述超量请求对应的权重高于预设的权重阈值，则拒绝将所述请求任务推送入所述补发队列。

下面参考图6来描述根据本申请实施例的电子设备30。图6显示的电子设备30仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，电子设备30以通用计算设备的形式表现。电子设备30的组件可以包括但不限于：上述处理单元310、上述存储单元320、连接不同系统组件(包括存储单元320和处理单元310)的总线330。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元310执行，使得所述处理单元310执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元310可以执行如图3中所示的各个步骤。

存储单元320可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)3201和/或高速缓存存储单元3202，还可以进一步包括只读存储单元(ROM)3203。

存储单元320还可以包括具有一组()程序模块3205的程序/实用工具3204，这样的程序模块3205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线330可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备30也可以与一个或多个外部设备400(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备30交互的设备通信，和/或与使得该电子设备30能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口350进行。输入/输出(I/O)接口350与显示单元340相连。并且，电子设备30还可以通过网络适配器360与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器360通过总线330与电子设备30的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备30使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。

在本申请的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本申请的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如JAVA、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由所附的权利要求指出。

Claims (10)

1.一种进程间的请求管理方法，其特征在于，所述方法包括：

在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，为所述长连接的请求队列中新增的超量请求生成对应的请求任务；

将所述请求任务推送入补发队列，并在所述补发队列中为所述请求任务分别注册对应的信号；

响应于检测到处于正常工作状态的长连接释放资源，从所述补发队列中取出信号，通过所取出信号唤醒所述补发队列绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

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

通过各个补发队列绑定的补发线程，监测并更新对应补发队列绑定的系统信号量。

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

获取单个长连接在单位时间周期内的请求处理上限值，并获取预设的繁忙判定系数；

基于所述请求处理上限值与所述繁忙判定系数之间的乘积，检测所述长连接的工作状态。

4.根据权利要求3所述的方法，其特征在于，基于所述请求数上限值与所述繁忙判定系数之间的乘积，检测所述长连接的工作状态，包括：

若在当前时间周期内处理请求的请求处理数小于或等于所述乘积，则确认对应长连接处于正常工作状态；

若所述请求处理数大于所述乘积并且小于所述请求处理上限值，则确认对应长连接处于繁忙工作状态；

若所述请求处理数大于或等于所述请求处理上限值，则确认对应长连接处于超限工作状态。

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

针对处于超限工作状态的长连接，若检测到对应请求队列中新增的超量请求的权重低于预设的权重阈值，则触发熔断，并返回请求错误信息。

6.根据权利要求1所述的方法，其特征在于，将所述请求任务推送入补发队列，包括：

基于所述超量请求的业务类型，获取所述超量请求的权重；

将所述请求任务推送入匹配对应权重的补发队列。

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

若所述超量请求对应的权重高于预设的权重阈值，则拒绝将所述请求任务推送入所述补发队列。

8.一种进程间的请求管理装置，其特征在于，所述装置包括：

任务生成模块，配置为在进程间的长连接数量达到连接上限值，并且进程间的长连接均处于繁忙工作状态时，为所述长连接的请求队列中新增的超量请求生成对应的请求任务；

任务入队模块，配置为将所述请求任务推送入补发队列，并在所述补发队列中为所述请求任务分别注册对应的信号；

任务出队模块，配置为响应于检测到处于正常工作状态的长连接释放资源，从所述补发队列中取出信号，通过所取出信号唤醒所述补发队列绑定的补发线程出队所取出信号对应的请求任务，以发送所取出信号对应的超量请求。

9.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1至7任一项所述的方法。

Images