CN110971561A - 一种访问请求处理方法、装置及设备 - Google Patents

Abstract

本申请公开了一种访问请求处理方法、装置及设备。该方法包括：在服务器的访问请求数超限导致客户端的访问请求被加入等待队列时，客户端确定该访问请求对应的优先级相关特征并发起重试请求，以供服务器基于优先级相关特征确定该访问请求的优先级，进而确定对该访问请求的处理方式。

Description

一种访问请求处理方法、装置及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种访问请求处理方法、装置及设备。

背景技术

请求流量超限，是指服务器需要承载的请求流量超出了服务器的承载能力。

对于此情况，目前一般是通过过载保护的方式，以防止服务器被流量洪峰压垮。

因此，需要更加可靠的访问请求处理方案。

发明内容

本说明书实施例提供一种访问请求处理方法，用于供服务器灵活处理流量超限的访问请求。

第一方面，本说明书实施例还提供一种访问请求处理方法，包括：

接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

基于所述优先级相关特征，确定所述访问请求的处理优先级；

基于所述处理优先级，确定对所述访问请求的处理方式。

第二方面，本说明书实施例还提供一种访问请求处理方法，包括：

向服务器发送访问请求；

确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。

第三方面，本说明书实施例还提供一种访问请求处理方法，包括：

向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

接收所述服务器处理所述访问请求返回的数据。

第四方面，本说明书实施例还提供一种访问请求处理装置，包括：

接收模块，用于接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

确定模块，用于基于所述优先级相关特征，确定所述访问请求的处理优先级；

处理模块，用于基于所述处理优先级，确定对所述访问请求的处理方式。

第五方面，本说明书实施例还提供一种访问请求处理装置，包括：

发送模块，用于向服务器发送访问请求；

接确定模块，用于确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

重试模块，用于向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。

第六方面，本说明书实施例还提供一种访问请求处理装置，包括：

发送模块，用于向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

接收模块，用于接收所述服务器处理所述访问请求返回的数据。

第七方面，本说明书实施例还提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如第一方面至第三方面中任一项所述的方法的步骤。

第八方面，本说明书实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面至第三方面中任一项所述的方法的步骤。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过在服务器需要处理的请求数超限导致客户端的访问请求被加入等待队列时，客户端发起重试请求，以使服务器确定该访问请求的优先级相关特征，并基于优先级相关特征，确定该访问请求的处理优先级，进而确定对该访问请求的处理方式。与现有技术中服务器发生限流，访问请求被堵塞在服务器的方案相比，能够在服务器需要处理的请求数超限时，自动发起重试请求，以供服务器确定访问请求的处理优先级，保障处理优先级较高的访问请求，进而有效提高访问请求的处理灵活性，降低限流对用户的影响。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本说明书提供的一种应用场景的示意图；

图2为本说明书一实施例提供的一种访问请求处理方法的流程示意图；

图3为本说明书一实施例提供的步骤240的一种实现方式的流程示意图；

图4为本说明书一实施例提供的步骤260的一种实现方式的流程示意图；

图5为本说明书另一实施例提供的一种访问请求处理方法的流程示意图；

图6为本说明书又一实施例提供的一种访问请求处理方法的流程示意图；

图7为本说明书一实施例提供的服务器和客户端的交互过程的流程示意图；

图8为本说明书一实施例提供的流量控制模块的优先级等待机制的示意图；

图9为本说明书一实施例提供的用户终端和交易服务器的交互过程的流程示意图；

图10为本说明书一实施例提供的用户界面的示意图；

图11为本说明书一实施例提供的用户终端整体决策的流程示意图；

图12为本说明书一实施例提供的一种访问请求处理装置的结构示意图；

图13为本说明书另一实施例提供的一种访问请求处理装置的结构示意图；

图14为本说明书又一实施例提供的一种访问请求处理装置的结构示意图；

图15为本说明书一实施例提供的一种电子设备的结构示意图；

图16为本说明书另一实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

正如背景技术部分陈述的，在一些场景中可能出现服务器流量超限的情况，例如：电子商务网站在促销活动时需要面对比平时多几十甚至上百倍的流量，同样，核心交易系统也需要承载突发流量洪峰的压力。因此，为了防止电子商务网站、核心交易系统被瞬间上涨的流量压垮，往往会对流量设置限流阈值，即过载保护，以通过挡掉和牺牲一部分外部请求来防止系统被整体压垮，进而能保证即使外来流量远远超过自身能力也能保障部分服务能力。

虽然通过过载保护的做法保护了系统，但其缺点是牺牲了用户体验和权益。比如：在促销活动期间，由于交易系统大量限流导致用户无法下单、打开页面提示系统繁忙等不好的体验，也影响了部分用户本该获得的优惠权益，比如：很多卖家往往会给促销活动最早下单的订单特殊的优惠折扣，但在该最早的时间段，系统流量峰值往往是最高的、最容易引起限流的，进而导致越早下单的用户无法以更优惠的价格购买到所需的商品。

而且，其另一个问题是限流后用户的行为可能导致前置系统的额外开销，比如：用户正常的购物路径之一是从购物车->下单页->提交订单，而在用户提交的订单被限流后需要重复进行从购物车->下单页->提交订单的行为，导致购物车、下单等系统的额外开销。

针对上述问题，目前的处理方案一般是准备足够的机器和系统容量来保证用户体验，确保没有限流发生。但是为了支撑很短的一段流量峰值，而准备成倍的机器容量，成本和预算会非常高。

基于此，本发明提供一种访问请求处理方法，通过在服务器的访问请求数超限导致客户端的访问请求被加入等待队列时，由客户端确定该访问请求对应的优先级相关特征并自动发起重试请求，以供服务器基于优先级相关特征确定该访问请求的优先级，进而确定对该访问请求的处理方式。与现有技术相比，能够在请求数超限时，自动发起重试请求，以保障处理优先级较高的访问请求，进而有效提高访问请求的处理灵活性，降低限流对用户的影响。

下面参见图1对本发明的应用场景进行示例性说明。

该应用场景中包括：服务器110和多个客户端120，所述服务器110包括：优先级确定模块111和处理器112，其中：

客户端120，用于向服务器110发起访问请求；以及，确定该访问请求被加入服务器110的等待队列时，向服务器110发起重试请求；

优先级确定模块111，用于检测服务器110当前需要处理的请求数是否超限；若是，则确定超限部分的访问请求的处理优先级，并将处理优先级发送至处理器112，否则，直接将需要处理的访问请求转发给处理器112；

处理器112，用于在请求数超限时，基于处理优先级处理各访问请求；在请求数未超限时，正常处理各访问请求。

其中，客户端或称为用户端，是指与服务器相对应，为客户提供本地服务的程序，例如：安装在用户终端上的应用；用户终端可以为PC端，也可以为移动终端，移动终端或者叫移动通信终端是指可以在移动中使用的计算机设备，广义的讲包括手机、笔记本、平板电脑、POS机甚至包括车载电脑。但是大部分情况下是指手机或者具有多种应用功能的智能手机以及平板电脑。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图2为本说明书一实施例提供的一种访问请求处理方法的流程示意图，该方法可由图1中的服务器执行，参见图2，具体可以包括如下步骤：

步骤220、接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

其中，访问请求包括：读访问请求、写访问请求等，访问请求中可携带客户端标识，例如：用户的账号信息等等；所述优先级相关特征包括：用户的身份特征信息、访问请求的等待响应的时长和重试次数中至少一个；服务器的等待队列用于保存超限部分的访问请求。

不难理解的是，在步骤220之前，还包括：预处理步骤，该步骤具体可以包括：

接收客户端的访问请求；确定所述服务器需要处理的请求数超限时，将所述访问请求加入等待队列。即，客户端的访问请求排在服务器当前处理周期可处理的访问请求上限之外。

其中，请求数超限是指服务器当前需要处理的请求数超出限流阈值要求的数量，也可以是指请求对应的访问流量超出限流阈值要求的流量，所述限流阈值取决于服务器的数据处理能力；例如：服务器一个处理周期可处理的访问请求数上限为50k，若当前需要处理的访问请求数已达50k，则后续接收到的访问请求作为超限部分的访问请求被加入等待队列中；服务器的一个处理周期可以为约定的访问请求的重试周期，也可以为基于服务器能力设定的时间长度。

另外，触发客户端发起第一重试请求的方案包括：

向所述客户端发送重试指示，以指示所述客户端发送第一重试请求；或者，

客户端自行监控访问请求的状态，当监控到访问请求的等待响应时长超限时或者从服务器查询到访问请求被加入到等待队列时，自行发起第一重试请求。

步骤240、基于所述优先级相关特征，确定所述访问请求的处理优先级；

其中，处理优先级是指服务器处理访问请求的优先级，优先级高的访问请求优先被服务器处理。

需要说明的是，所述优先级相关特征为访问请求的等待响应的时长时，步骤240的第一种实现方式可以为：

基于所述访问请求等待响应的时长，确定所述访问请求的处理优先级。具体可以示例为：

当请求数超限时，拦截所有的访问请求并将请求加入到等待队列中；基于等待响应时长越大，处理优先级越高的规则，为各访问请求配置一处理优先级；例如：处理优先级与等待响应时长成正比；又例如：预构建多个处理优先级，每个处理优先级对于一个等待响应时长范围，进而可将等待响应时长与各等待响应时长范围进行匹配，得到访问请求对应的处理优先级。

所述优先级相关特征为用户的身份特征信息时，由于不同用户的重要程度不同，因此，需要对不同用户的访问请求配置不同的处理优先级，以优先保证重要用户的体验。相应地，步骤240的第二种实现方式可以为：

基于所述身份特征信息，确定所述访问请求的处理优先级。结合图3，其具体可以示例为：

步骤320、确定用户的身份信息和历史访问数据；

其中，身份信息可以示例为：是否为会员等等，历史访问数据可以示例为：预定时间段内的访问频率、频次，下单数，订单价值等等。

步骤340、基于所述身份信息和历史访问数据，为所述用户配置身份特征信息；具体可以示例为：

若用户为会员，则为用户配置会员的特征；

若最近的预定时间段内的访问频次、频率达到预定阈值，则为用户配置常客的特征；

若下单数和/或订单价值的累计达到预定条件，则为用户配置优质用户的特征。

当然不难理解的是，基于实际业务的需要，还可获取用户相关的其他数据，并为用户配置其他特征。

步骤360、确定所述身份特征信息关联的处理优先级，作为所述用户发起的访问请求的处理优先级。

其中，身份特征和处理优先级的关联关系可以是灵活配置的，例如：单一特征的对比中，会员关联的处理优先级＞优质用户关联的处理优先级＞常客关联的处理优先级＞普通用户关联的处理优先级。

对于具有多个特征的用户，可通过对每个特征配置权重的方式，计算用户所有特征的权重值，以为每个用户的身份特征配置一权重。进一步地，可遵循权重越大，处理优先级越高的规则，为每个用户的身份特征关联一处理优先级。

步骤260、基于所述处理优先级，确定对所述访问请求的处理方式。

需要说明的是，步骤260的一种实现方式可以为：

确定目标访问请求的数量未超限时，响应访问请求在下一处理周期向所述客户端发送访问请求对应的数据，否则发送限流提示或重试指示；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级，限流提示是指客户端和服务器之间约定的协议码，例如：FAIL_SYS_TRAFFIC_LIMIT，当客户端接收到该协议码，代表服务器对该访问请求进行了限流，用户终端显示系统繁忙的结果。

结合图4，本实现方式具体可以示例为：

步骤402、基于服务器的限流阈值，确定当前周期内服务器可处理的访问请求数量；

其中，限流阈值可以为基于服务器的数据处理能力动态配置的。

步骤404、从等待队列中选出与可处理的访问请求数量相同数量的处理优先级最高的访问请求；

即，若访问请求位于选出的访问请求中，则确定目标访问请求的数量未超限，否则确定目标访问请求的数量超限。

步骤406、在本处理周期处理选出的访问请求以返回访问请求对应的数据；

步骤408、确定等待队列中是否存在剩余的访问请求；

若是，则执行步骤410；若否，则本周期处理流程结束。

步骤410、向剩余访问请求对应的客户端发送限流提示或重试指示；具体可以示例为：

确定剩余访问请求等待响应的时长；对于等待响应的时长未超限的访问请求，服务器向客户端发送重试指示，以指示客户端发送重试请求；对于等待响应的时长超限的访问请求，服务器向客户端发送限流提示。或者，

确定剩余访问请求的剩余重发次数；对于剩余重试次数大于或等于1(或者重试次数未超限)的访问请求，服务器向客户端发送重试指示，以指示客户端重发访问请求；对于剩余重试次数小于1(或者重试次数超限)的访问请求，服务器向客户端发送限流提示。

基于此，步骤240的第三种实现方式可以为：

确定所述访问请求的重发次数；基于所述重发次数，确定所述访问请求的处理优先级。即，重发次数越多，访问请求的处理优先级越高。

其中，用户的访问请求的重发次数可以不同，例如：会员用户的重发次数大于普通用户的重发次数。

可选的，在接收到服务器的重试指示，客户端展示‘正在重试’的用户界面，并发送重试请求；若客户端检测到用户点击用户界面中的取消选项，则向服务器发送取消重试请求；若服务器在接收到重试请求之前，接收取消重试请求，则向所述客户端发送限流提示；若服务器在接收到重试请求且确定了该访问请求的处理优先级后，接收到取消重试请求，则需要进一步确定目标访问请求的数量是否超限，若否，则在下一处理周期向所述客户端发送请求访问的数据，否则发送限流提示。

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

可见，本实施例通过在服务器需要处理的请求数超限导致客户端的访问请求被加入等待队列时，客户端发起重试请求，以使服务器确定该访问请求的优先级相关特征，并基于优先级相关特征，确定该访问请求的处理优先级，进而确定对该访问请求的处理方式。与现有技术中服务器发生限流，访问请求被堵塞在服务器的方案相比，能够在服务器需要处理的请求数超限时，自动发起重试请求，以供服务器确定访问请求的处理优先级，保障处理优先级较高的访问请求，进而有效提高访问请求的处理灵活性，降低限流对用户的影响。

图5为本说明书另一实施例提供的一种访问请求处理方法的流程示意图，该方法可由图1中的客户端执行，参见图5，具体可以包括如下步骤：

步骤520、向服务器发送访问请求；

步骤540、确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

需要说明的是，步骤540的一种实现方式可以为：

接收所述服务器返回的重试指示；

基于所述重试指示，确定所述访问请求被加入所述服务器的等待队列。

其中，重试指示为服务器需要处理的请求数超限时生成的，用于指示该访问请求被加入等待队列。

步骤540的另一种实现方式可以为：

确定所述访问请求的等待响应时长超限时，确定所述访问请求被加入所述服务器的等待队列。具体可以示例为：

客户端监控访问请求从发出到当前时间点之间的时间长度，并将该时间长度与预设时长阈值进行对比，若前者大于后者，则确定超限。

进一步地，客户端确定所述访问请求被加入所述服务器的等待队列时还会展示‘正在重试’的界面，以使用户看起来不是限流而是重试的状态。

若检测到用户点击‘正在重试’的界面上的‘取消重试’选项，则判断是否已经向服务器发起重试请求；若‘取消重试’发生在发起重试请求之前，则客户端展示限流界面，或者，客户端向服务器发送取消重试请求，以使服务器返回限流提示，以指示客户端基于限流提示展示限流界面；若在‘取消重试’之前客户端已将重试请求发送给服务器，且服务器已确定访问请求的优先级，则需要服务器进一步确定对访问请求的处理方式，该部分已在图2对应的实施例进行了详述，故，此处不再赘述。

步骤560、向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。其一种实现方式可以为：

基于预设延时规则，向所述服务器延时发送携带所述优先级相关特征的第一重试请求。例如：客户端可延时N秒后，再发起第一重试请求；

其中，N的取值可基于预设延时规则动态设定。

进一步地，在步骤560之后，方法还包括：再次重试步骤，具体可以为：

确定所述服务器需要处理的目标访问请求的数量超限时，向所述服务器发送第二重试请求；其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

即，重试之后，若处理优先级大于访问请求的优先级的请求数依然超限，则需要继续重试。

另外，在继续重试之前，还包括：监测访问请求的重试次数，当重试次数超限或者剩余重试次数小于1时，停止重试，并等待限流。

其中，访问请求的重试次数可以为一固定值，也可以为一动态值。

图6为本说明书又一实施例提供的一种访问请求处理方法的流程示意图，该方法可由图1中的客户端执行，参见图6，具体可以包括如下步骤：

步骤620、向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

步骤640、接收所述服务器处理所述访问请求返回的数据。

相对于图5对应的实施例，本实施例中，客户端发送的访问请求中携带用户的身份特征信息；若服务器需要处理的请求数未超限，则正常处理该访问请求；若服务器需要处理的请求数超限，则进一步地基于访问请求携带的用户的身份特征信息，确定各访问请求的处理优先级，进而基于处理优先级确定对各访问请求的处理方式。

另外，对于图5和图6对应的客户端侧的实施例，由于其与图2对应的服务器侧的实施例相对应，其实现方式也对应相似，故，此处不再对图5和图6对应的实施例中的步骤进行详细说明。

而且，图5和图6对应的实施例通过在限流发生时，用户终端自动重试，以便服务端根据重试请求优先级权重标识给予优先通过，让用户实际感受不到限流的结果；而且，限流后在当前页面自动发起重试请求，能够避免重走购物等业务处理路径，减少前置系统的开销；当用户第一次发起的访问请求被限流后，再次发起的重试请求会相对于其他请求有优先级、会被优先处理，以实现倡导先买先得的原则，引入排队优先级的概念；而且，能对用户身份及优先级做精细化控制、比如超级会员的下单请求会被优先通过。

图7为本说明书一实施例提供的服务器和客户端的交互过程的流程示意图，参见图7，具体可以包括如下步骤：

步骤702、客户端向服务器发送普通访问请求，或者，带优先级标识的访问请求；

其中，普通访问请求是指未携带优先级标识的请求；优先级标识与上述的优先级相关特征相对应，可以是用户的身份特征信息、客户端的唯一标识码等等，也可以是服务器基于用户的身份特征等信息为各用户颁发的优先级级别的标签。

步骤704、服务器将访问请求转由服务器的流量控制模块处理；

步骤706、流量控制模块将访问请求加入流量区块中，并确定请求数是否超限，并向服务器返回超限/不超限指示；

其中，流量区块包括服务器可支持的整体容量区块V0，用于代表流量控制模块整体限流阀值，V0中包括至少一个优先级对应的子区块；例如：第一个优先级对应的滑动窗口子区块V1、第二个优先级对应的子区块V2。为便于描述，此处示例性地划分出两个优先级：低优先级和高优先级，低优先级对应于普通访问请求以及V0-V1部分的子区块；高优先级对应与携带优先级标识的访问请求以及V1部分的子区块，且高V1中的请求总是会被优先通过，而且，V1区块的请求至多等待一个滑动窗口的时间(当前设定为N＝5毫秒、可动态调整)，然后就会作为最高优先级被处理。

其中，V1/V0、N数值和比例可动态调整、通过实际流量请求可调优到最佳值；滑动窗口：基于分段的统计思想、将1秒的时间切分成10段、每段叫一个滑动窗口(或者叫Bucket、分桶)，每段100毫秒；在第一个100ms内，写入第一个滑动窗口中进行计数，在第二个100ms内，写入第二个段中进行计数，这样如果要统计当前时间的每秒查询率qps，可以通过统计当前时间前1s(共10段)的计数总和值。

相应地，若是普通访问请求，则可判断V0中的请求数是否超限；若是带优先级标识的访问请求，则可判断V1中的请求数是否超限。

步骤708、若确定超限，则服务器进一步确定是否需要重试，若是，则返回重试指示，否则返回限流提示；

其中，确定是否需要重试的规则可以为以下任一一个：

对于首发的访问请求，确定需要重试；

对于已重发的普通访问请求，确定不需要重试，直接限流处理；

对于已重发的普通访问请求，进一步确定其重发次数，当重发次数未超限时，确定需要重试；当重发次数超限时，确定不需要重试。

步骤710、客户端向服务器重发带优先级标识的访问请求(或者，发送重试请求)；

步骤712、服务器将访问请求转由服务器的流量控制模块处理；

步骤714、流量控制模块将访问请求加入流量区块中，并确定当前请求数是否超限，并向服务器返回超限/不超限指示；

其中，超限/不超限的情况有如下几种：

第一种：整体未超限，则服务器响应访问请求返回请求访问的数据；

第二种：整体超限但高优先级请求未超限，则服务器同样响应访问请求返回请求访问的数据；

第三种：整体和高优先级请求均超限，则返回步骤708以确定是否需要再次重试，若是，则发送重试指示，否则返回限流提示。

具体可以示例为：

访问请求进入高优先级滑动窗口区域、该区域请求的等待时间为N：0<N<＝5(毫秒)，在下一个滑动窗口(对应于上述的一个处理周期)滑过之后，该区块请求是所有请求中优先级最高的，会第一时间被优先通过、进入正常的业务处理流程；1、在5毫秒的滑动窗口等待时间内、请求被优先通过、则直接进入正常的业务处理流程后返回(未限流)；2、极限情况下、当前请求全部为高优先级请求、且在5毫秒的滑动窗口时间内、前面的请求无法被全部处理完成；直接进入步骤2再次重试。

另外，针对第2种的极限情况，服务器还可选的配置了自我保护机制；这个机制可以通过动态控制打开和关闭；这个机制的作用是防止在极限情况下导致用户终端无限重试；那么在这个机制打开时、整体的流程和场景二是类似的、区别是在步骤5的第2步情况下、不再返回让用户终端重试的标识、而是直接返回限流、中断当前的重试。

可选的，结合图8，下面对流量控制模块的优先级等待机制进行示例性说明：

首先，图8中的M代表正常未限流的请求量；N代表原本被限流现在返回用户终端进行重试的请求量；S代表用户终端等待N秒后重新提交带优先级的请求量；

其次，从流量控制模块的视角、用户终端的请求量分布有以下几种情况：

情况1、用户终端的请求量持续小于系统容量；

情况2、用户终端的请求量持续大于系统容量且用户终端的请求量保持恒定值；

情况3、用户终端的请求量持续大于系统容量但用户终端的请求量处于一个波动范围；

情况4、用户终端的请求量在一定的时间范围内既有大于系统容量、又有小于系统容量；

由于此处只考虑限流后的场景分析。情况1属于正常情况，无需展开分析；情况4可以认为是情况1、情况2、情况3在多个时间区间的合集，情况2和情况3对于流量控制模块来说、在一定的阈值内处理方式是一样的；

因此，此处只需要分析情况2的场景，在这个场景下；

N＝＝S；且M的值保持恒定；用户终端的请求量＝M+N

上图是3秒内整个流量模块的请求情况，分析如下：

1、M容量的请求正常通过、N容量的请求(超出系统能力、本应被限流)返回用户终端做排队重试；

2、用户终端等待T秒(这里等待T秒是为了在不影响用户体验的前提下请求延迟发送到服务端、达到某种程度上削峰的效果)后重新发送带优先级权重的请求；

3、带优先级的请求到服务端后、如果当前流量<M；则直接通过；

4、带优先级请求到服务端后、如果当前流量大于系统容量；则会预定下一秒的请求份额；等到时间窗口(设定为5毫秒)滑过之后，直接优先于所有其他普通请求、优先通过；(如果在极限情况下、当前请求全部为带优先级请求且大于系统容量、则重复进行第一步的流程；在这种情况下系统本身处于满负荷状态)。

下面结合图7，对上述处理流程的场景进行简要说明：

场景一：系统容量V0未达到上限，即当前请求流量未超过限流阈值：

1、用户终端发起普通请求，当前请求未超过系统限流阈值；请求被正常处理并返回用户终端请求访问的数据；

2、用户终端直接发起带有优先级标识的请求，当前请求未超过系统限流阈值；请求被正常处理并返回用户终端请求访问的数据。

场景二：系统容量V0达到上限，即当前流量已达到上限时：

步骤1.1:用户终端发起普通请求(未带权重标识)、流量控制模块判断当前请求已超出系统容量上限，进入步骤2；

步骤1.2：用户终端直接发起带有优先级标识的请求(带有权重)，流量控制模块判断当前请求已超出系统容量上限，直接进入步骤5

步骤2:服务端不返回限流(系统繁忙)的结果，而是返回需要客户端自动重试的结果码(FAIL_SYS_TRAFFIC_QUEUE，该结果码为客户端和服务端之间交互协议的)，进入步骤3；

步骤3：用户终端N秒后(N值可动态设定)，在当前界面自动重新发起带有优先级标识的重试请求(带有权重)，进入步骤4；

步骤4：请求再次到服务端；

1、流量控制模块判断当前请求未超出系统容量上限(因系统流量是动态变化的，用户终端第二次请求，即重试请求时系统容量有可能已未到上限)、直接返回成功(未限流)；

2、流量控制模块判断当前请求还是超出系统容量上限，进入步骤5

步骤5：请求进入高优先级滑动窗口区域，该区域请求的等待时间为N：0<N<＝5(毫秒)，在下一个滑动窗口滑过之后、该区块请求是所有请求中优先级最高的、会第一时间被优先通过、进入正常的业务处理流程：

1、在5毫秒的滑动窗口等待时间内、请求被优先通过、则直接进入正常的业务处理流程后返回(未限流)；

2、极限情况下、当前请求全部为高优先级请求、且在5毫秒的滑动窗口时间内、前面的请求无法被全部处理完成；直接进入步骤2再次重试；

场景三：系统容量V0达到上限且系统触发自我保护

该场景的流程和场景二是类似的，区别在于触发了系统的自我保护机制；该机制可以通过动态控制打开和关闭；这个机制的作用是防止在极限情况下导致用户终端无限重试。那么在这个机制打开时，整体的流程和场景二是类似的，区别在于：

在步骤5的第2种情况下，不再返回让用户终端重试的指示，而是中断当前的重试直接返回限流；或者

为各访问请求配置重发次数，并在访问请求的剩余重发次数大于1时返回重试指示，否则中断当前的重试直接返回限流；或者，

为各访问请求配置的处理的等待总时长，在等待总时长未超限时返回重试指示，否则中断当前的重试直接返回限流。

其中，处理的等待总时长是指服务器首次接收到某访问请求至服务器处理该访问请求以返回请求访问的数据之间的时间长度。

可见，本实施例在服务端有限的资源条件下：

1、通过用户终端后台重试+服务端基于无锁滑动窗口排队结合方式；即使服务端已超出自身能力原本需要限流并拒绝服务；用户终端上看起来仍然是不限流、而是重试的方式；

2、服务端发生限流后，给用户终端发出排队重试的指令(而非直接返回系统繁忙)、用户终端在当前的页面上自动发起重试，而不是跳转到系统繁忙页面让用户重新进入购物路径

3、通过滑动窗口偏移+环形桶数组排队的方式优化现有技术中服务端阻塞队列的方式、节省排队自身对服务端的资源开销。

图9为本说明书一实施例提供的用户终端和交易服务器的交互过程的流程示意图，参见图9，该交互过程具体可以为：

步骤902、用户终端的业务处理模块发起标准API请求；

其中，标准API请求中携带Api版本号、Api的名字、请求头、请求数据主体以及优先级请求数据；优先级请求数据存放在请求头中，包含两种类型具有优先级的请求数据：1、具有某种优先级身份特征(如超级会员)的用户请求，2、限流后排队重试的请求；

步骤904、用户终端请求经过接入层到后端交易系统；

其中，接入层为交易系统针对用户终端请求的同一流量入口；

步骤906、后端交易系统及内部流量控制模块判断当前请求流量大于系统容量时，返回排队重发指令；

步骤908、用户终端的定制处理模块接收到交易系统返回结果、解析结果；判断当前终端需要进入到排队流程，通知业务处理模块进入到排队流程；相应的弹出排队重试等待的用户界面，例如：图10；

步骤910、用户终端在用户界面后台重新发起API请求，在请求头中设置优先级标记及优先级权重相关的数据；

步骤912、API调用模块将携带加签后的优先级标记及优先级数据透传到交易系统

其中，API调用模块为用户终端调用交易系统的API的通用处理模块；

步骤914、交易系统响应访问请求返回用户终端请求访问的数据。

可见，本实施例通过在服务器需要处理的请求数超限时，为访问请求配置处理优先级，并依据处理优先级处理访问请求。与现有技术相比，能够在请求数超限时保障处理优先级较高的访问请求，进而有效提高访问请求的处理灵活性。而且，本实施例通过后台重试的方式，以在发生服务器超限并拒绝处理访问请求的情况，用户终端看到的仍然是不限流、而是重试的状态，以避免影响用户体验。

图11为本说明书一实施例体用的用户终端整体决策的流程示意图，下面参见图11以下单-付款的具体应用场景对用户终端的整体决策进行说明：

步骤1102、当前服务器的请求量超过上限容量时，新的访问请求被限流(未限流场景不再重复描述)；

步骤1104、系统判定访问请求是限流还是排队重试；若是普通限流，则进入步骤1108；否则进入步骤1106；

步骤1106、返回系统繁忙，进入访问失败页面；

步骤1108、用户终端弹出新的等待的用户界面(见图10)，用户界面提示帮用户自动抢；

步骤1110、用户终端后台先等待N秒，这里等待N秒是为了保护后端交易系统、将峰值削平；

步骤1112、用户是否自己取消：在弹出用户界面的过程中、允许用户自己关闭(相当于取消用户终端自动重试)；如果此时用户自己取消、则重新进入步骤1106；否则进入步骤1114；

步骤1114、用户终端后台自动发起带优先级权重的重试请求；

步骤1116、当请求发出后、用户是否点了取消；如果是则进入步骤1118；否则进入步骤1124；

步骤1118、因用户虽然取消、但是请求已发出，故直接进入提交等待流程；

步骤1120、步骤1118的请求发出后，服务端判断请求是否再次被限流；如果是则直接进入步骤1106(因用户已取消且重新被限流、则直接请求失败)否则进入步骤1122；

步骤1122、请求未被限流、走正常的业务处理流程并返回相应的结果；针对交易系统订单创建成功后直接进入收银台付款界面；请求处理正常终止；

步骤1124、用户终端请求重试后、服务端判断请求是否被再次限流；如果否则正常进入步骤1122、否则进入步骤1126；

步骤1126、请求再次被限流后、用户终端判断当前请求是否需要再次重试(系统开关动态配置、主要为了防止无限重试、实际业务场景下不会出现)；如果是则重新进入步骤1114、否则进入步骤1122。

可见，本实施例通过用户终端后台重试+服务端基于无锁滑动窗口排队结合方式；即使服务端已超出自身能力原本需要限流并拒绝服务；用户终端上看起来仍然是不限流、而是重试的方式；而且，服务端发生限流后、给用户终端发出排队重试的指令(而非直接返回系统繁忙)、用户终端在当前的页面上自动发起重试、而不是跳转到系统繁忙页面让用户重新进入购物路径。

另外，对于上述方法实施方式，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施方式并不受所描述的动作顺序的限制，因为依据本发明实施方式，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施方式均属于优选实施方式，所涉及的动作并不一定是本发明实施方式所必须的。

图12为本说明书一实施例提供的一种访问请求处理装置的结构示意图，该装置可以作为图1中的服务器的部分，参见图12，具体可以包括：接收模块121、确定模块122和处理模块123，其中：

接收模块121，用于接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

确定模块122，用于基于所述优先级相关特征，确定所述访问请求的处理优先级；

处理模块123，用于基于所述处理优先级，确定对所述访问请求的处理方式。

可选的，接收模块121，还用于：

接收客户端的访问请求；

确定所述服务器需要处理的请求数超限时，将所述访问请求加入等待队列。

可选的，装置还包括：

发送模块，用于向所述客户端发送重试指示，以指示所述客户端发送第一重试请求。

可选的，所述优先级相关特征包括：用户的身份特征信息、访问请求的等待响应的时长和重试次数中至少一个。

可选的，处理模块123，还用于：

在接收客户端发送的第一重试请求之前，若接收所述客户端发送的取消重试请求，则向所述客户端发送限流提示。

可选的，处理模块123，还用于：

若接收到所述客户端发送的取消重试请求，则确定下一处理周期需要处理的目标访问请求的数量是否超限；若否，则向所述客户端发送所述请求访问对应的数据，否则发送限流提示；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

可选的，处理模块123，具体用于：

确定目标访问请求的数量未超限时，在下一处理周期向所述客户端发送所述访问请求对应的数据，否则发送限流提示或重试指示；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

可选的，处理模块123，还用于：

确定所述访问请求等待响应的时长或重试次数未超限时，向所述客户端发送重试指示，以指示所述客户端发起第二重试请求，否则发送限流提示。

图13为本说明书另一实施例提供的一种访问请求处理装置的结构示意图，该装可以作为图1中客户端的部分，参见图13，具体可以包括：发送模块131、确定模块132和重试模块133，其中：

发送模块131，用于向服务器发送访问请求；

确定模块132，用于确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

重试模块133，用于向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。

可选的，确定模块132，具体用于：

接收所述服务器返回的重试指示；

基于所述重试指示，确定所述访问请求被加入所述服务器的等待队列。

可选的，确定模块132，具体用于：

确定所述访问请求的等待响应时长超限时，确定所述访问请求被加入所述服务器的等待队列。

可选的，重试模块133，还用于：

确定所述服务器需要处理的目标访问请求的数量超限时，向所述服务器发送第二重试请求；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

可选的，重试模块133，还用于：

确定所述访问请求的重试次数超限时，停止重试。

可选的，重试模块133，具体用于：

基于预设延时规则，向所述服务器延时发送携带所述优先级相关特征的第一重试请求。

可选的，发送模块131，还用于：

基于用户操作，在延时时间段内向所述服务器发送取消重试请求。

可选的，发送模块131，还用于：

向所述服务器发送携带所述优先级相关特征的第一重试请求之后或同时，基于用户操作，向所述服务器发送取消重试请求。

可选的，装置还包括：

接收模块，用于接收所述服务器发送的所述访问请求对应的数据或限流提示，并展示。

图14为本说明书又一实施例提供的一种访问请求处理装置的结构示意图，该装置可以作为图1中的客户端的部分，具体可以包括：发送模块141和接收模块142，其中：

发送模块141，用于向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

接收模块142，用于接收所述服务器处理所述访问请求返回的数据。

可见，对于图12-图14对应的实施例，通过在服务器需要处理的请求数超限导致客户端的访问请求被加入等待队列时，客户端发起重试请求，以使服务器确定该访问请求的优先级相关特征，并基于优先级相关特征，确定该访问请求的处理优先级，进而确定对该访问请求的处理方式。与现有技术中服务器发生限流，访问请求被堵塞在服务器的方案相比，能够在服务器需要处理的请求数超限时，自动发起重试请求，以供服务器确定访问请求的处理优先级，保障处理优先级较高的访问请求，进而有效提高访问请求的处理灵活性，降低限流对用户的影响。

而且，通过通过在限流发生时，用户终端自动重试，以便服务端根据重试请求优先级权重标识给予优先通过，让用户实际感受不到限流的结果；而且，限流后在当前页面自动发起请求，能够避免重走购物等业务处理路径，减少前置系统的开销；当用户第一次请求被限流后下次重试请求会相对于其他请求有优先级、会被优先处理，以实现倡导先买先得的原则，引入排队优先级的概念；而且，能对用户身份及优先级做精细化控制、比如超级会员的下单请求会被优先通过。

另外，对于上述装置实施方式而言，由于其与方法实施方式基本相似，所以描述的比较简单，相关之处参见方法实施方式的部分说明即可。而且，应当注意的是，在本发明的装置的各个部件中，根据其要实现的功能而对其中的部件进行了逻辑划分，但是，本发明不受限于此，可以根据需要对各个部件进行重新划分或者组合。

图15为本说明书一实施例提供的一种电子设备的结构示意图，参见图15，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成访问请求处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

网络接口、处理器和存储器可以通过总线系统相互连接。总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器可能包含高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器。

处理器，用于执行所述存储器存放的程序，并具体执行：

接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

基于所述优先级相关特征，确定所述访问请求的处理优先级；

基于所述处理优先级，确定对所述访问请求的处理方式。

上述如本申请图12所示实施例揭示的访问请求处理装置或管理者(Master)节点执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

访问请求处理装置还可执行图2-4，7,9的方法，并实现管理者节点执行的方法。

基于相同的发明创造，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行图2-4，7,9对应的实施例提供的访问请求处理方法。

图16为本说明书一实施例提供的另一种电子设备的结构示意图，参见图16，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成访问请求处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

网络接口、处理器和存储器可以通过总线系统相互连接。总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图16中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器可能包含高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器。

处理器，用于执行所述存储器存放的程序，并具体执行：

向服务器发送访问请求；

确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。

或者，

向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

接收所述服务器处理所述访问请求返回的数据。

上述如本申请图13-14所示实施例揭示的访问请求处理装置或管理者(Master)节点执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

访问请求处理装置还可执行图5-7，9的方法，并实现管理者节点执行的方法。

基于相同的发明创造，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行图5-7，9对应的实施例提供的访问请求处理方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (21)

1.一种访问请求处理方法，其特征在于，包括：

接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

基于所述优先级相关特征，确定所述访问请求的处理优先级；

基于所述处理优先级，确定对所述访问请求的处理方式。

2.根据权利要求1所述的方法，其特征在于，接收客户端发送的第一重试请求之前，还包括：

接收客户端的访问请求；

确定所述服务器需要处理的请求数超限时，将所述访问请求加入等待队列。

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

向所述客户端发送重试指示，以指示所述客户端发送第一重试请求。

4.根据权利要求1所述的方法，其特征在于，所述优先级相关特征包括：用户的身份特征信息、访问请求的等待响应的时长和重试次数中至少一个。

5.根据权利要求1的方法，其特征在于，接收客户端发送的第一重试请求之前，还包括：

若接收所述客户端发送的取消重试请求，则向所述客户端发送限流提示。

6.根据权利要求1的方法，其特征在于，确定所述访问请求的处理优先级之后，还包括：

若接收到所述客户端发送的取消重试请求，则确定下一处理周期需要处理的目标访问请求的数量是否超限；

若否，则向所述客户端发送所述请求访问对应的数据，否则发送限流提示；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

7.根据权利要求1-6中任一项所述的方法，其特征在于，基于所述处理优先级，确定对所述访问请求的处理方式包括：

确定目标访问请求的数量未超限时，在下一处理周期向所述客户端发送所述访问请求对应的数据，否则发送限流提示或重试指示；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

8.根据权利要求7所述的方法，其特征在于，所述发送限流提示或重试指示包括：

确定所述访问请求等待响应的时长或重试次数未超限时，向所述客户端发送重试指示，以指示所述客户端发起第二重试请求，否则发送限流提示。

9.一种访问请求处理方法，其特征在于，包括：

向服务器发送访问请求；

确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。

10.根据权利要求9所述的方法，其特征在于，确定所述访问请求被加入所述服务器的等待队列包括：

接收所述服务器返回的重试指示；

基于所述重试指示，确定所述访问请求被加入所述服务器的等待队列。

11.根据权利要求9所述的方法，其特征在于，确定所述访问请求被加入所述服务器的等待队列包括：

确定所述访问请求的等待响应时长超限时，确定所述访问请求被加入所述服务器的等待队列。

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

确定所述服务器需要处理的目标访问请求的数量超限时，向所述服务器发送第二重试请求；

其中，所述目标访问请求的处理优先级大于或等于所述访问请求的处理优先级。

13.根据权利要求12所述的方法，其特征在于，在向所述服务器发送第二重试请求之前，还包括：

确定所述访问请求的重试次数超限时，停止重试。

14.根据权利要求9所述的方法，其特征在于，向所述服务器发送携带所述优先级相关特征的第一重试请求包括：

基于预设延时规则，向所述服务器延时发送携带所述优先级相关特征的第一重试请求。

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

基于用户操作，在延时时间段内向所述服务器发送取消重试请求。

16.根据权利要求9所述的方法，其特征在于，向所述服务器发送携带所述优先级相关特征的第一重试请求之后或同时，还包括：

基于用户操作，向所述服务器发送取消重试请求。

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

接收所述服务器发送的所述访问请求对应的数据或限流提示，并展示。

18.一种访问请求处理方法，其特征在于，包括：

向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

接收所述服务器处理所述访问请求返回的数据。

19.一种访问请求处理装置，其特征在于，包括：

接收模块，用于接收客户端发送的第一重试请求，所述第一重试请求为所述客户端确定发送至服务器的访问请求被加入所述服务器的等待队列时发送的，所述第一重试请求携带所述访问请求对应的优先级相关特征；

确定模块，用于基于所述优先级相关特征，确定所述访问请求的处理优先级；

处理模块，用于基于所述处理优先级，确定对所述访问请求的处理方式。

20.一种访问请求处理装置，其特征在于，包括：

发送模块，用于向服务器发送访问请求；

确定模块，用于确定所述访问请求被加入所述服务器的等待队列时，确定所述访问请求对应的优先级相关特征；

重试模块，用于向所述服务器发送携带所述优先级相关特征的第一重试请求，以供所述服务器确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式。

21.一种访问请求处理装置，其特征在于，包括：

发送模块，用于向服务器发送访问请求，所述访问请求携带用户的身份特征信息，以供所述服务器确定需要处理的请求数超限时，基于所述身份特征信息确定所述访问请求的处理优先级，并基于所述处理优先级确定对所述访问请求的处理方式；

接收模块，用于接收所述服务器处理所述访问请求返回的数据。

Images