CN109218369A - 远程过程调用请求控制方法及装置 - Google Patents

Abstract

本申请实施例公开了远程过程调用请求控制方法及装置，其中，所述方法包括：客户端统计远程过程调用RPC请求的失败率或成功率；如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。通过本申请实施例，在保证系统可用性的同时，可以降低系统服务能力继续下降甚至不可用的发生概率。

Description

远程过程调用请求控制方法及装置

技术领域

本申请涉及远程过程调用技术领域，特别是涉及远程过程调用请求控制方法及装置。

背景技术

RPC(Remote Procedure Call Protocol，远程过程调用协议)是一种通过网络从远程计算机程序上请求服务的协议。该协议采用客户机/服务器模式，请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，客户端调用进程接收答复信息，获得进程结果。

例如，在销售平台系统中，消费者用户通过其终端设备上安装的销售平台客户端程序浏览具体的商品信息，甚至可能执行购买等操作，用户发出的具体的请求，客户端通常需要调用服务端提供的API(Application Programming Interface,应用程序编程接口)接口来获得相应的处理结果，而在API调用的内部实现中，具体就是通过RPC请求的方式与服务器进行交互。

在RPC协议中，客户端往往会为RPC请求设定一定的超时时间，也即，假设RPC请求的超时时间设定为1S，则从客户端发出RPC请求开始计时，如果在1S之内收到了服务器的答复信息，则客户端认为此次RPC请求成功，而如果已经到达1S，但一直未收到服务器的答复信息，则客户端会认为此次RPC请求失败。

通常情况下，RPC请求失败的原因，通常是由于服务器压力过大，使得服务器处理能力已经难以处理大量的RPC请求导致的。为解决上述问题，在现有技术中，客户端可以采用“退避”机制。也即，可以为API请求设定更长的超时时间，例如，如果将RPC请求的超时时间设定为1S，则可以将API请求的超时时间设定为3～5S，等等。这样，如果客户端发现API调用过程中，某次RPC请求失败，则只要API请求尚未超时，即可间隔一段时间之后，在API内部进行RPC请求的重传。并且，在同一API请求内部，随着RPC请求失败次数的增加，重试的间隔时间也可以随之呈现出指数级的增长。通过这种延长重试时间间隔的方式，可以从很大程度上降低服务器的压力。

但是，在实际应用中，还可能存在服务器压力骤增的情况。例如，对于销售平台的服务器而言，在一些大型活动期间(例如，“双11”等)，经常会出现RPC请求数量大量并发情况，使得请求的数量远远超出服务器的处理能力。此时，即使使用现有技术中的“退避”机制，即使延长了重试的时间间隔，可能也会出现无济于事的情况。

因此，如何更有效的提升系统的服务能力，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了远程过程调用请求控制方法及装置，在保证系统可用性的同时，可以降低系统服务能力继续下降甚至不可用的发生概率。

本申请提供了如下方案：

一种远程过程调用请求控制方法，包括：

客户端统计远程过程调用RPC请求的失败率或成功率；

如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

一种远程过程调用请求控制装置，应用于客户端，包括：

RPC请求统计单元，用于统计远程过程调用RPC请求的失败率或成功率；

延长调整单元，用于如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

判定单元，用于对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

统计远程过程调用RPC请求的失败率或成功率；

如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

一种远程过程调用RPC请求控制方法，包括：

统计RPC请求是否成功的比例；

对RPC请求的超时时间进行调整。

一种远程过程调用RPC请求控制装置，包括：

统计单元，用于统计RPC请求是否成功的比例；

调整单元，用于对RPC请求的超时时间进行调整。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于客户端可以统计RPC请求的失败率或成功率，并在发现失败率高于某第一阈值，或成功率低于预置的第二阈值时，如果该第一阈值/第二阈值意味着服务器的服务能力已经下降，很难在原来的RPC Timeout原始值内完成处理，则可以对RPCTimeout进行延长调整。这样，客户端可以容许服务器用更长的时间来处理一次RPC请求，从而可以使得RPC请求的成功率提高，并且有利于减少RPC请求的重传次数，在保证系统可用性的同时，可以降低系统服务能力继续下降甚至不可用的发生概率。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的应用场景示意图；

图2是现有技术中的客户端退避机制示意图；

图3是本申请实施例提供的RPC超时时间延长示意图；

图4是本申请实施例提供的方法的流程图；

图5是本申请实施例提供的装置的示意图；

图6是本申请实施例提供的计算机系统的示意图；

图7是本申请实施例提供的另一方法的流程图；

图8是本申请实施例提供的另一装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解本申请实施例，首先需要说明的是，之所以会出现采用现有技术中的“退避”机制，也无法提升系统服务能力的情况，主要是因为：对于一些高并发、低时延的服务，客户端通常会通过异步写请求来提高集群的吞吐量。也即，客户端发出一个RPC请求之后，不必等到接收到服务器的响应，即可发送其他的请求。但是，这会导致到达服务器的请求数量激增。尤其是在一些分布式的系统中，由于集群中的机器数量众多(在一些大型的销售平台中，集群中的机器数量可以达到数十万台)，在基数很大的情况下，基本每天都可能会有机器发生故障。因此，为了保障数据的安全性，一次异步写集群操作，通常需要向集群写三份同样的数据到不同的机器上。也即，客户端调用一次API，实际需要执行三次RPC请求，三台机器处理的RPC均成功，API才返回成功。这样能够提高数据的安全性，但也使得服务器需要处理的RPC请求数量成倍增长。

例如，参见图1，对于销售平台系统，在遇到一些大型促销活动等场景时，由于通常会有大量的用户101(1)至101(n)集中在同一时间段内，通过其客户端102(1)至102(n)进行访问，而每个用户101在客户端102中每执行一次点击等操作，可能都会使得客户端102产生一次API调用，并产生三次RPC请求。也就是说，假设某时刻有n个用户101通过其客户端102执行了某个操作，则至少会3n个RPC请求到达服务器端103。再加上API内部的重传机制，服务器103实际收到的RPC请求数量还会远不止于此。

虽然客户端可以将API调用的超时时间设置的相对较长，并且，如果发现某个RPC请求失败，可以采用“退避”机制，在API内部发起重传，但是，如果遇到以下情况，则即使采用“退避”机制，也可能无法提升系统的服务能力。

(1)当单台机器的系统资源达到瓶颈后，造成更多的排队等待，处理能力不能满足大部分请求的RPC超时时间(RPC Timeout)，也即，由于单台机器的处理能力已经下降，因此，对于大部分的RPC请求，单台机器都难以在客户端规定的RPC Timeout内完成处理，返回给客户端大量的超时失败。此时，即使客户端增加了重传的时间间隔，也无法让单台机器在RPC Timeout内处理完绝大部分请求。

(2)由于客户端执行的是并发的写请求，而网络发包无法保证顺序性，因此，当发生RPC乱序时，服务器会缓存先到达的实际靠后的数据，但是，在向磁盘中写数据时，又需要按照顺序执行写操作，因此，服务器需要等待全部的数据都到达后，再执行实际的写操作。例如，Data1、Data2、Data3、Data4从客户端同时异步发往服务器，但Data4最先到达服务器，则服务器内存会先缓存这部分数据，等到Data1、Data2、Data3、Data4全部到齐后，再按实际的数据顺序，写入到磁盘中。这种RPC乱序情况的存在，将占用系统大量内存。当失败率过高时，或者成功率过低时，例如，网络资源达到瓶颈，等待的乱序包不能及时到达，系统内存不能及时释放，其他新到的请求因内存不足进而失败，会加剧系统失败情况，形成恶性循环。

上述两种情况都可能会导致系统的服务能力降低，然而，在实际应用中，上述两种情况还经常同时存在，这就有可能进一步加剧系统的服务能力降低速度，导致系统资源达到瓶颈后大量失败，客户端重传后仍失败，服务器无法在原定的RPC Timeout内完成处理，甚至导致系统服务不可恢复。当然，理论上讲，如果所有客户端都进行了“退避”，存在使服务器压力降低的可能，进而使得服务器恢复服务能力，但是，一方面，可能会不断有新的客户端加入，无法控制用户的行为，另一方面，即使能够控制加入的客户端数量以及用户行为，由于服务器缓存的RPC乱序包不能及时释放，也可能会导致集群持续雪崩。再加之高时延的敏感业务类型下，常有预分配的功能，不断失败后不断重传的过程中，服务器可能会不断分配出实际没有被真实使用的磁盘空间，导致很快将集群磁盘全部写满，以至于集群彻底不可用且无法恢复。

而本申请发明人在实现本申请的过程中发现，在服务器的服务能力下降，但是，还不至于彻底不可用的状态下，经常出现以下情况：虽然服务器无法在客户端规定的RPCTimeout时间内完成处理，服务器往往能够在更长一点的时间内完成处理。例如，假设客户端设定的RPC Timeout为1S，但是，在服务器能力下降的情况下，服务器或许可以用1.2S或者更长一点的时间完成处理。但是，在现有技术中，无论服务器的能力如何，RPC Timeout都是固定不变的。在这种情况下，由于客户端只要没有在1S之内收到处理完成的答复信息，就会视为RPC请求失败，因此，即使服务器用了稍长一些的时间完成了处理，客户端也会不再接收服务器的答复信息，然后，采用隔一段时间之后重传的方式进行退避。但是，如果服务器确实已经针对上一次RPC请求完成了数据写入处理，只不过用了更长的时间，则可能已经对磁盘空间形成了占用；而重传到服务器的RPC请求，服务器可能仍然无法在1S之内完成处理，客户端仍然视为失败，但在服务器端，仍然可能会又形成了一次对磁盘空间的占用，以此类推。最终导致无法响应用户操作，同时还浪费了大量的磁盘空间。

基于上述分析，本申请实施例提供了相应的解决方案，具体的，可以由客户端对RPC请求的失败率或成功率进行实时的统计，如果某时刻发现RPC请求的失败率高于某第一阈值，或成功率低于某第二阈值，则可以对RPC请求的超时时间进行延长调整，并且，具体延长的程度，还可以根据实际的失败率或成功率来进行确定，失败率越高，或者成功率越低，延长的越多。也就是说，假设某时刻RPC请求的失败率已经高于10％，或者成功率低于90％(或者其他某数值，具体可以根据实际需求进行设定)，则证明服务器的服务能力可能已经下降，服务器处理单个RPC请求所需的时间可能会增长，因此，客户端可以主动延长RPCTimeout，也就是说，可以允许服务器的处理单个RPC请求所需的时间略有延长，客户端等待服务器返回答复信息的时间可以设置的更长一些。例如，延长为1.2S，则意味着，只要服务器能够在1.2S之内完成处理，则客户端就可以视为一次成功的RPC请求。并且，在大部分情况下，如果从服务器的服务能力刚开始出现下降的情况，就开始通过这种方式进行处理，则可以提高RPC请求的成功率，减少RPC请求的重传次数，因此，可以降低服务器的服务能力继续恶化甚至不可用的发生概率。另外，本申请实施例在对RPC Timeout进行延长时，还可以根据具体的失败率或成功率的大小，确定具体延长的值，也即，通过失败率或成功率的大小来反映服务器服务能力的下降程度，下降程度越高，延长后的RPC Timeout可以越长。

也就是说，如图2所示，其为在采用现有技术中的“退避”机制的情况下，某系统中API Timeout与RPC Timeout之间的关系示意图。从图中可以看出，一次API调用包括三个RPC请求，只有在三个RPC请求都返回成功，才意味着该API调用成功。但在具体实现时，可能只有其中两个RPC(rpc1以及rpc2)返回成功(suss)，而第三个RPC请求rpc3，客户端却没有在RPC Timeout时间内收到服务器返回的答复信息，则客户端会将其视为失败的RPC请求处理(Fail)，且失败的原因是RPC Timeout。之后，可以在间隔一段时间后，在API内部，对该RPC请求进行重传，但在重传RPC请求后，RPC Timeout不变，因此，重传的RPC请求仍然可能会失败，之后，只要API Timeout尚未结束，则还可以在API内部再次发起重传，并且，再次发起重传的时间间隔，可以比第一次发起重传的时间间隔更长。但是，服务器可能就是因为硬件性能等原因，无法在RPC Timeout内完成处理，因此，即使延长重传的时间间隔也于事无补。最终，在同一个API请求内部一共可能会发送五次甚至更多次的RPC请求，服务器对每个RPC请求都需要处理，但最终却可能在API Timeout内，都无法使得全部RPC请求均获得成功。

而在本申请实施例中，如图3所示，同样是一次API调用包括三个RPC请求，如果客户端发现RPC请求的失败率达到了某第一阈值，或成功率低于某第二阈值，可以延长RPCTimeout，例如，延长为1.2S等等。则即使第三个RPC请求rpc3发生过一次失败的情况，但在重传时，可能已经发现了RPC请求的失败率达到了某第一阈值，或成功率低于某第二阈值，此时，就可以使用延长后的RPC Timeout对RPC请求的成功与否进行判定。也就是说，客户端可以在重传RPC请求后，可以花更长的时间等待服务器返回响应，只要服务器能够在该更长的时间内返回处理成功的信息，则客户端就可以视为此次RPC请求成功，而不会再次发起重传。同时，由于rpc1以及rpc2都已经能够返回成功，因此，还可以视为整个API调用成功。可见，在本申请实施例中，在系统已经出现服务能力下降的情况下，可以减少一次API调用过程中RPC请求的重传次数，还可以提升API调用的成功率，在保证系统可用性的同时，可以降低系统服务能力继续下降甚至不可用的发生概率。

需要说明的是，在本申请实施例中，客户端是指发送RPC请求的程序，例如，可以是销售平台系统中提供给消费者用户使用的移动端App，或者，还可以是其他需要通过RPC方式进行远程调用的应用程序；而服务端是指接收RPC请求并提供具体服务的程序，例如，可以是销售平台系统中的服务端程序，等等。在实际应用中，客户端以及服务器是相对的概念，同一程序在不同的场景中也可能扮演不同的角色，因此，在本申请实施例中并不做具体的限定。

下面对具体的实现方式进行详细介绍。

参见图4，本申请实施例提供了一种远程过程调用请求控制方法，该方法具体可以包括：

S401：客户端统计远程过程调用RPC请求的失败率或成功率；

在本申请实施例中，为提高系统可用性所做的相关处理操作，可以由客户端来执行，也即发起RPC请求的一端。具体的，客户端可以对RPC请求的失败率或成功率进行统计，在优选的实现方式下，该统计的过程可以是实时进行的。也即，只要客户端处于运行状态，统计RPC请求失败率或成功率的操作就可以一直在进行。当然，所谓的实时只是一个尽可能接近实时的状态，具体实现时，可以是按照一定的周期执行统计操作，例如，每秒钟统计一次，等等。每次统计出RPC失败率或成功率后，都可以与预置的第一阈值/第二阈值进行比较。

其中，每次在统计RPC失败率或成功率时，可以有多种具体的实现方式，例如，可以统计最近一个周期(例如最近1S)内发出的RPC请求的失败次数，以及RPC请求的总发送次数，然后，利用这两个数值之间的比值，计算出该最近一个周期内的RPC请求失败率或成功率。

或者，为了避免由于数据稀疏导致的统计不准确等情况，还可以在每次统计时，获取当前统计时刻前预置数目个周期内的RPC请求失败率或成功率，然后，对所述前预置数目个周期内的RPC请求失败率或成功率进行加权平均，将计算结果确定为当前统计时刻的RPC请求失败率或成功率。例如，每个周期为1S，则每次统计时，可以取出前4S的RPC请求失败率或成功率，然后，对这4个RPC请求失败率或成功率进行加权平均。其中，在加权时，可以为距离当前统计时刻越近的周期，设定越高的权重。例如，从当前统计时刻向前数，第一秒内的RPC请求失败率或成功率的权重为40％，第二秒内的RPC请求失败率或成功率的权重为30％，第三秒内的RPC请求失败率或成功率的权重为20％，第四秒内的RPC请求失败率或成功率的权重为10％，等等。这样，假设当前时刻前1S内的RPC请求失败率或成功率为R1，前2S内的RPC请求失败率或成功率为R2，前3S内的RPC请求失败率或成功率为R3，前4S内的RPC请求失败率或成功率为R4，则可以当前时刻统计出的RPC请求失败率或成功率为：

R0＝(R1×40％+R2×30％+R3×20％+R4×10％)/4

S402：如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

在统计出RPC请求的失败率或成功率后，就可以与预置的第一阈值/第二阈值进行比较，其中，第一阈值/第二阈值可以根据实际情况而定，例如，第一阈值可以是10％，或者20％，第二阈值可以是90％，80％，等等，总之，通过该第一阈值/第二阈值，可以反映服务器的服务能力下降水平。在周期性的实时获取RPC失败率或成功率的情况下，在每次统计出RPC失败率或成功率后，都可以与该第一阈值/第二阈值进行比较。如果RPC失败率大于等于该第一阈值，或成功率低于预置的第二阈值，则证明服务器的服务能力已经下降，在本申请实施例中，可以将RPC请求的超时时间进行延长，也就是说，客户端在发出一个RPC请求后，可以允许服务器花费更长的时间来处理该RPC请求，这样，可以提高服务器处理单个RPC请求的成功率，降低RPC请求的重传次数，也可以有效的控制由于RPC请求的重传造成的服务器压力增加。

其中，具体在对RPC Timeout进行延长调整时，可以有多种方式，例如，在其中一种实现方式下，可以采用固定延长比例的方式，例如，只要发现RPC请求的失败率达到第一阈值，或成功率低于预置的第二阈值，就可以统一的将RPC Timeout从原来的1S延长至1.2S等等。

或者，在一种更为优选的实现方式下，还可以根据所述失败率或成功率对RPC请求的超时时间进行延长调整，也即，RPC Timeout的延长程度与RPC请求的失败率或成功率可以是相关联的，并且可以是成正比的关系，也即，RPC请求的失败率越高，成功率越低，则RPCTimeout的延长程度越长。这样可以实现RPC Timeout的“按需”延长。

具体实现上述按需延长的方式也可以有多种，其中一种方式下，可以按照预先设定的比例进行调整，例如，可以预先设定RPC请求的失败率或成功率的区间与调整比例之间的对应关系。具体如，可以设定RPC请求的失败率为10％至20％时，对应的调整比例是120％，也即，如果实际统计出的RPC请求的失败率落在10％到20％之间，则可以将RPCTimeout在原来的原始值基础上乘以120％，以此实现对RPC Timeout延长调整，等等。

或者，另一种实现方式下，还可以是直接利用当前时刻统计出的RPC请求的失败率或成功率，计算出一个调整值，然后，在RPC Timeout的原始值基础上加上该调整值，实现对RPC Timeout的延长调整。其中，在计算该调整值时，除了考虑当前RPC请求的失败率或成功率，RPC Timeout的原始值，还可以考虑API Timeout信息。这是因为，RPC Timeout并不能无限延长，如果延长后的RPC Timeout过长，以至于在API Timeout内无法再具有重传的机会，则也可能会使整体上的系统服务能力下降。因此，在优选的实现方式下，可以综合APITimeout、RPC Timeout原始值以及当前的RPC请求的失败率或成功率这三方面的因素，确定出RPC Timeout的调整值。例如，一种具体的实现方式下，可以首先计算API Timeout与所述RPC Timeout原始值之间的差值，然后将该差值与所述失败率之间的乘积，确定为所述调整值。也即，

调整后的RPC Timeout＝RPC Timeout原始值+(API Timeout-RPC Timeout原始值)×当前统计出的RPC请求的失败率

例如，假设RPC Timeout原始值为1S，API Timeout为3S，当前统计出的RPC请求的失败率为10％，则调整后的RPC Timeout＝1+(3-1)×10％＝1.2S。

当然，在实际应用中，还可以有其他的延长调整方式，这里不再一一介绍。

需要说明的是，如果某次统计出来的RPC请求的失败率小于第一阈值，或者成功率高与第二阈值，则可以不需要对RPC Timeout进行延长调整，也即，保持RPC Timeout原始值不变即可。

S403：对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

在根据实时的RPC请求失败率或成功率的统计结果对RPC Timeout进行延长调整后，如果再发送RPC请求，则可以利用所述调整后的超时时间，对RPC请求的成功与否进行判定。也就是说，如果已经对RPC Timeout进行了延长，则在此之后发送的RPC请求，无论是首次发送的RPC请求，还是重传的RPC请求，都可以以延长后的RPC Timeout对RPC请求的成功与否进行判定。也即，对于这些RPC请求，可以等待更长的时间，以使得服务器有更长的时间来处理RPC请求。直到下次再统计出新的RPC请求的失败率或成功率时，再根据实际的统计结果，确定是继续对RPC Timeout进行延长调整，还是不需要再调整，以此类推。

总之，通过本申请实施例提供的上述方式，由于客户端可以统计RPC请求的失败率或成功率，并在发现失败率高于某第一阈值，或成功率低于某第二阈值时，如果该第一阈值/第二阈值意味着服务器的服务能力已经下降，很难在原来的RPC Timeout原始值内完成处理，则可以对RPC Timeout进行延长调整。这样，客户端可以容许服务器用更长的时间来处理一次RPC请求，从而可以使得RPC请求的成功率提高，并且有利于减少RPC请求的重传次数，在保证系统可用性的同时，可以降低系统服务能力继续下降甚至不可用的发生概率。

需要说明的是，在具体实现时，可能会出现以下情况：通过本申请实施例提供的前述调整方式，对RPC Timeout进行了延长调整，但是，RPC请求的失败率却仍然在继续升高，或者，成功率在继续降低，这可能是由于客户端请求的数量实在过高导致的。为此，在本申请实施例中，还可以设定第三阈值或第四阈值，如果在进行了前述调整的之后，发现RPC请求的失败率继续升高，且高于该第三阈值，或者，成功率在继续降低，且低于第四阈值，则客户端还可以概率性地对收到的部分API调用请求进行丢弃处理。也即，假设销售平台客户端的用户，在浏览的过程中，点击购买了十件商品对象，此时，如果是正常情况下，客户端可能需要向服务器发送十次API调用请求，每次API调用内部都会产生3次甚至更多次的RPC请求。但是，在RPC请求的失败率高于第三阈值，或者成功率低于第四阈值的情况下，为了保证至少有部分用户请求得到有效的响应，客户端可以仅将其中的部分API调用请求发送到服务器，而其他部分则丢弃，用户可以通过刷新页面或者重新点击购买等方式，重新向客户端发起API调用请求。

其中，具体实现时，客户端丢弃API调用请求的比例，也可以是根据实际统计出的RPC请求的失败率或成功率来确定，并且，实际统计出的RPC请求的失败率越高，成功率越低，则API调用请求的丢弃比例也越高，等等。以此来降低服务器的压力，避免RPC请求的失败率进一步升高，甚至完全不可用的情况出现。

也就是说，在本申请实施例中，在通过对RPC Timeout延长的方式进行退避之后，失败率仍在增加，或者成功率仍在降低(例如：老客户端选择退避，但无法保证会有新加入进来的客户端的压力)，在发现失败率高于某第三阈值，或者成功率低于某第四阈值时，可以开始进行降级。并且可以根据失败率或成功率调整丢弃的前端请求，丢包率与失败率成正比，与成功率成反比，当客户端的失败率达到100％，成功率为0，则客户端丢弃了100％的请求，不会再给服务端施加压力。

另外，在出现RPC请求的失败率过高或成功率过低的情况下，服务器也可以执行一些措施，来保证服务的可用性。具体的，服务器可以通过一些方式获取到各客户端的RPC请求的失败率或成功率，并进行分析，如果某时刻发现各客户端的RPC请求的失败率或成功率达到某条件，例如，多数客户端的RPC请求的失败率都高于第三阈值，或成功率低于第四阈值，则证明服务器的服务性能已经严重下降，此时，可以主动关闭一些原本用于提高性能的功能，进行“服务降级”，以使得服务器获得更多可支配的硬件资源，尽量避免服务能力进一步恶化的情况发生。例如，有些服务器中可能会提供“预分配”功能，也即，预先为一些即将到来但是尚未到来的数据分配磁盘空间，以便在数据实际到来时，可以快速的进行数据存储，而不需要再等待磁盘空间的分配。该功能是为了提高性能提供的额外的功能，但是，该功能本身也会占用服务器的一些资源，而实际上，如果不采用该功能，则服务器也能够提供基本的服务。为此，在服务器的服务能力已经严重下降的情况下，服务器可以主动关闭这种额外的功能。例如，关于前述预分配功能，这样，即使RPC请求大量失败，也不会增加整集群的磁盘空间，可以避免集群磁盘空间被占满的情况。

其中，服务器获得客户端RPC请求失败率或成功率的方式可以有多种，例如，各个客户端可以主动将其统计出的RPC请求失败率或成功率数据上传到服务器，使得服务器可以掌握各客户端的情况。或者，为了避免该操作也会对服务器的服务能力造成干扰，还可以通过预置的第三方服务器来获得各客户端的RPC请求失败率或成功率情况，并判断服务器的服务能力是否已经严重下降，如果是，再向提供RPC服务的服务器发送通知消息，服务器在接收到消息后，即可执行关闭一些用于提高性能的额外功能等操作。

与前述实施例相对应，本申请实施例还提供了一种远程过程调用请求控制装置，参见图5，该装置应用于客户端，具体可以包括：

RPC请求失败率或成功率统计单元501，用于统计远程过程调用RPC请求的失败率或成功率；

延长调整单元502，用于如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

判定单元503，用于对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

具体实现时，所述RPC请求统计单元501具体可以用于：

对RPC请求的失败率或成功率进行周期性的实时统计；

相应的，所述延长调整单元502具体可以用于：

每次确定出所述失败率达到所述第一阈值，或成功率低于所述第二阈值时，均对RPC请求的超时时间进行延长调整。

其中，每次进行失败率或成功率统计时，所述RPC请求统计单元501可以包括：

获取子单元，用于获取当前统计时刻前预置数目个周期内的RPC请求失败率或成功率；

计算子单元，用于对所述前预置数目个周期内的RPC请求失败率或成功率进行加权平均，将计算结果确定为当前统计时刻的RPC请求失败率或成功率。

其中，距离当前统计时刻越近的周期，权重越高。

具体实现时，所述延长调整单元502具体可以用于

根据所述失败率或成功率对RPC请求的超时时间进行延长调整。

更为具体的，所述延长调整单元502可以用于：

在RPC请求的超时时间原始值基础上，根据所述失败率或成功率增加调整值；

其中，所述调整值通过以下方式确定：

计算API请求的超时时间与所述RPC请求的超时时间原始值之间的差值，并将该差值与所述失败率之间的乘积，确定为所述调整值。

在实际应用中，该装置还可以包括：

丢弃处理单元，用于如果所述失败率达到预置的第三阈值，或成功率低于预置的第四阈值，则对收到的部分API调用请求进行丢弃处理。

在优选的实现方式中，API调用请求的丢弃比例可以根据所述RPC请求的失败率或成功率进行确定。

另外，该装置还可以包括：

信息提交单元，用于将所述统计的RPC请求的失败率或成功率提供给预置的第三方服务器，由所述第三方服务器对各客户端的RPC请求的失败率或成功率进行分析，如果达到预置的条件，则通知提供RPC服务的服务器对预置的用于提高性能的额外功能关闭。

与前述实施例相对应，本申请实施例还提供了一种计算机系统，参见图6，该计算机系统可以包括：

一个或多个处理器601；以及

与所述一个或多个处理器601关联的存储器602，所述存储器602用于存储程序指令,所述程序指令在被所述一个或多个处理器601读取执行时,执行如下操作:

统计远程过程调用RPC请求的失败率或成功率；

如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值时，则对RPC请求的超时时间进行延长调整；

对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

具体实现时，除了上述处理器601、存储器602，系统中还可以包括输入/输出接口603、通信接口604和总线605。其中处理器601、存储器602、输入/输出接口603和通信接口604通过总线605实现彼此之间在设备内部的通信连接。

处理器601可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器602可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器602可以存储操作系统和其他应用程序，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器602中，并由处理器601来调用执行。

输入/输出接口603用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口604用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线605包括一通路，在设备的各个组件(例如处理器601、存储器602、输入/输出接口603和通信接口604)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器601、存储器602、输入/输出接口603、通信接口604以及总线605，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

总之，通过本申请实施例，由于客户端可以统计RPC请求的失败率或成功率，并在发现失败率高于某第一阈值或成功率低于预置的第二阈值时，如果该第一阈值/第二阈值意味着服务器的服务能力已经下降，很难在原来的RPC Timeout原始值内完成处理，则可以对RPC Timeout进行延长调整。这样，客户端可以容许服务器用更长的时间来处理一次RPC请求，从而可以使得RPC请求的成功率提高，并且有利于减少RPC请求的重传次数，在保证系统可用性的同时，可以降低系统服务能力继续下降甚至不可用的发生概率。

实施例二

与前述实施例一相对应，本申请实施例还提供了一种远程过程调用RPC请求控制方法，参见图7，该方法可以包括：

S701：统计RPC请求是否成功的比例；

具体的，是否成功的比例，可以包括失败率、成功率等等。具体实现时，可以统计预设周期内RPC请求是否成功的比例。

S702：对RPC请求的超时时间进行调整。

具体实现时，可以基于所述比例与预设阈值的关系，对RPC请求的超时时间进行调整。例如，如果失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则可以对RPC请求的超时时间进行延长调整。当然，在其他实现方式下，如果失败率低于预置的第一阈值，或成功率高于预置的第二阈值，还可以对RPC请求的超时时间进行缩短调整，等等。

与该实施例二相对应，本申请实施例还提供了一种远程过程调用RPC请求控制装置，参见图8，该装置可以包括：

统计单元801，用于统计RPC请求是否成功的比例；

调整单元802，用于对RPC请求的超时时间进行调整。

具体实现时，所述统计单元801具体可以用于统计预设周期内RPC请求是否成功的比例。

调整单元802具体可以用于：基于所述比例与预设阈值的关系，对RPC请求的超时时间进行调整。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的远程过程调用请求控制方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种远程过程调用请求控制方法，其特征在于，包括：

客户端统计远程过程调用RPC请求的失败率或成功率；

如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

2.根据权利要求1所述的方法，其特征在于，所述统计RPC请求的失败率或成功率，包括：

对RPC请求的失败率或成功率进行周期性的实时统计；

所述对RPC请求的超时时间进行延长调整，包括：

每次确定出所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值时，均对RPC请求的超时时间进行延长调整。

3.根据权利要求2所述的方法，其特征在于，每次进行失败率或成功率统计时，通过以下方式进行：

获取当前统计时刻前预置数目个周期内的RPC请求失败率或成功率；

对所述前预置数目个周期内的RPC请求失败率或成功率进行加权平均，将计算结果确定为当前统计时刻的RPC请求失败率或成功率。

4.根据权利要求3所述的方法，其特征在于，距离当前统计时刻越近的周期，权重越高。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述对RPC请求的超时时间进行延长调整，包括：

根据所述失败率或成功率对RPC请求的超时时间进行延长调整。

6.根据权利要求5所述的方法，其特征在于，所述根据所述失败率或成功率对RPC请求的超时时间进行延长调整，包括：

在RPC请求的超时时间原始值基础上，根据所述失败率或成功率增加调整值；

其中，所述调整值通过以下方式确定：

计算API请求的超时时间与所述RPC请求的超时时间原始值之间的差值，并将该差值与所述失败率之间的乘积，确定为所述调整值。

7.根据权利要求1至4任一项所述的方法，其特征在于，还包括：

如果所述失败率达到预置的第三阈值，或成功率低于预置的第四阈值，则对收到的部分API调用请求进行丢弃处理。

8.根据权利要求7所述的方法，其特征在于，API调用请求的丢弃比例根据所述RPC请求的失败率或成功率进行确定。

9.根据权利要求1至4任一项所述的方法，其特征在于，还包括：

将所述统计的RPC请求的失败率或成功率提供给预置的第三方服务器，由所述第三方服务器对各客户端的RPC请求的失败率或成功率进行分析，如果达到预置的条件，则通知提供RPC服务的服务器对预置的用于提高性能的额外功能关闭。

10.一种远程过程调用请求控制装置，其特征在于，应用于客户端，包括：

RPC请求统计单元，用于统计远程过程调用RPC请求的失败率或成功率；

延长调整单元，用于如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

判定单元，用于对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

11.一种计算机系统，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

统计远程过程调用RPC请求的失败率或成功率；

如果所述失败率达到预置的第一阈值，或成功率低于预置的第二阈值，则对RPC请求的超时时间进行延长调整；

对于在所述调整完成后发送的RPC请求，利用所述调整后的超时时间，对RPC请求的成功与否进行判定。

12.一种远程过程调用RPC请求控制方法，其特征在于，包括：

统计RPC请求是否成功的比例；

对RPC请求的超时时间进行调整。

13.根据权利要求12所述方法，其特征在于，所述统计RPC请求是否成功的比例进一步包括：

统计预设周期内RPC请求是否成功的比例。

14.根据权利要求12所述方法，其特征在于，对RPC请求的超时时间进行调整进一步包括：

基于所述比例与预设阈值的关系，对RPC请求的超时时间进行调整。

15.一种远程过程调用RPC请求控制装置，其特征在于，包括：

统计单元，用于统计RPC请求是否成功的比例；

调整单元，用于对RPC请求的超时时间进行调整。