CN110008050A - 用于处理信息的方法和装置 - Google Patents

Abstract

本公开的实施例公开了用于处理信息的方法和装置。该方法的一具体实施方式包括：接收客户端发送的请求，其中，该请求包括：所请求的资源类别、与资源类别对应的需求配额；响应于需求配额大于本地的与资源类别对应的限额值，向总服务器发送全局可用配额请求；确定数据访问是否处于异常状态，其中，异常状态为未在预设响应时段内接收到总服务器针对全局可用配额请求进行反馈的反馈信息的状态；响应于数据访问处于异常状态，确定异常状态的次数；响应于异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。该实施方式实现了提高服务器处理请求的性能。

Description

用于处理信息的方法和装置

技术领域

本公开的实施例涉及计算机技术领域，具体涉及用于处理信息的方法和装置。

背景技术

计算机领域中，配额(quota)是一种用于跟踪和控制节点上的各个实体对资源的消耗的机制，以防止资源的过度消耗、同时进行资源分配的统计和汇报。该资源例如可以包括磁盘空间、存储器、CPU等。该实体例如可以包括个体用户、组织、进程等。

对于分布式的资源配额分配方法，如果数据访问异常，目前常用的容灾方法为：一、直接判定系统异常。即接口调用的时候如果发生连接、访问等异常，则直接判定系统异常。二、直接拦截请求或者直接通过请求。即在接口处于异常状态时，采用直接拦截该请求的方式或者采用直接通过该请求的方式。三、重试后进行拦截或通过。即在数据访问异常时进行重试访问，若重试成功则进行后续处理，若不成功则按上述方案一或者方案二的方法执行。

发明内容

本公开的实施例提出了用于处理信息的方法和装置。

第一方面，本公开的实施例提供了一种用于处理信息的方法，该方法包括：接收客户端发送的请求，其中，该请求包括：所请求的资源类别、与资源类别对应的需求配额；响应于需求配额大于本地的与资源类别对应的限额值，向总服务器发送全局可用配额请求；确定数据访问是否处于异常状态，其中，异常状态为未在预设响应时段内接收到总服务器针对全局可用配额请求进行反馈的反馈信息的状态；响应于数据访问处于异常状态，确定异常状态的次数；响应于异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

在一些实施例中，在接收客户端发送的请求之后，该方法还包括：累加记录每次接收到的请求的与资源类别对应的需求配额，以及进行记录周期计时。

在一些实施例中，该方法还包括：响应于异常状态的次数大于次数阈值，确定当前异常状态时记录的、与资源类别对应的需求配额的总量；对资源类别对应的全局可用配额和限额值进行求和，得到可用配额总量；确定接收当前请求的子服务器组中的子服务器数量，以及基于可用配额总量和子服务器数量，得到可用配额阈值；基于需求配额的总量和可用配额阈值的比较，对当前请求进行拦截或者通过的处理操作。

在一些实施例中，基于需求配额的总量和可用配额阈值的比较，对当前请求进行拦截或者通过的处理操作，包括：响应于需求配额的总量大于可用配额阈值，生成用于表征拦截当前请求的第一指示信息；响应于需求配额的总量小于或者等于可用配额阈值，生成用于表征通过当前请求的第二指示信息，以及从本地分配需求配额对应的资源量。

在一些实施例中，该方法还包括：响应于记录周期达到预设时长，将记录的需求配额的总量清零，以及再次进行记录周期计时的步骤。

在一些实施例中，该方法还包括：响应于异常状态的次数不超过次数阈值，从本地分配需求配额对应的资源量，以及继续执行第一方面或第一方面任一实施例的用于处理信息的方法。

在一些实施例中，从本地分配需求配额对应的资源量之后，该方法还包括：将每次请求的需求配额进行本地记录；定时向总服务器发送全局可用配额请求；响应于接收到总服务器的针对全局可用配额请求的反馈信息，将本地记录的需求配额的总量发送至总服务器，以及将本地记录的需求配额清零，其中，总服务器接收到本地记录的需求配额的总量，从与资源类别对应的全局可用配额中扣除与本地记录的需求配额的总量对应的配额量。

第二方面，本公开的实施例提供了一种用于处理信息的装置，包括：请求接收单元，被配置成接收客户端发送的请求，其中，请求包括：所请求的资源类别、与资源类别对应的需求配额；请求发送单元，被配置成响应于需求配额大于本地的与资源类别对应的限额值，向总服务器发送全局可用配额请求；异常状态确定单元，被配置成确定数据访问是否处于异常状态，其中，异常状态为未在预设响应时段内接收到总服务器针对全局可用配额请求进行反馈的反馈信息的状态；次数判断单元，被配置成响应于数据访问处于异常状态，确定异常状态的次数；通过指示信息生成单元，被配置成响应于异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

在一些实施例中，该装置还包括：记录单元，被配置成累加记录每次接收到的请求的与资源类别对应的需求配额，以及进行记录周期计时。

在一些实施例中，该装置还包括：需求配额总量获取单元，被配置成响应于异常状态的次数大于次数阈值，确定当前异常状态时记录的、与资源类别对应的需求配额的总量；可用配额总量获取单元，被配置成对资源类别对应的全局可用配额和限额值进行求和，得到可用配额总量；可用配额阈值确定单元，被配置成确定接收当前请求的子服务器组中的子服务器数量，以及基于可用配额总量和子服务器数量，得到可用配额阈值；第一处理单元，被配置成基于需求配额的总量和可用配额阈值的比较，对当前请求进行拦截或者通过的处理操作。

在一些实施例中，第一处理单元包括：第一指示信息生成模块，被配置成响应于需求配额的总量大于可用配额阈值，生成用于表征拦截当前请求的第一指示信息；第二指示信息生成模块，被配置成响应于需求配额的总量小于或者等于可用配额阈值，生成用于表征通过当前请求的第二指示信息，以及从本地分配需求配额对应的资源量。

在一些实施例中，该装置还包括：第二处理单元，被配置成响应于记录周期达到预设时长，将记录的需求配额的总量清零，以及再次执行记录单元中的方法。

在一些实施例中，该装置还包括：第三处理单元，被配置成响应于异常状态的次数不超过次数阈值，从本地分配需求配额对应的资源量，以及继续执行第一方面或第一方面任一实施例的方法。

在一些实施例中，该装置还包括：本地记录单元，被配置成将每次请求的需求配额进行本地记录；全局可用配额请求发送单元，被配置成定时向总服务器发送全局可用配额请求；第四处理单元，被配置成响应于接收到总服务器的针对全局可用配额请求的反馈信息，将本地记录的需求配额的总量发送至总服务器，以及将本地记录的需求配额清零，其中，总服务器接收到本地记录的需求配额的总量，从与资源类别对应的全局可用配额中扣除与本地记录的需求配额的总量对应的配额量。

第三方面，本公开的实施例提供了一种电子设备，该电子设备包括：一个或多个处理器；存储装置，其上存储有一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面中任一实现方式描述的方法。

第四方面，本公开的实施例提供了一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面中任一实现方式描述的方法。

本公开的实施例提供的用于处理信息的方法和装置，通过接收客户端发送的请求，其中在该请求中包括所请求的资源类别、与该资源类别对应的需求配额。之后，响应于该需求配额大于本地的与该资源类别对应的限额值，向总服务器发送全局可用配额请求。然后，确定数据访问是否处于异常状态。其中该异常状态为未在预设响应时段内接收到总服务器针对该全局可用配额请求进行反馈的反馈信息的状态。之后，响应于数据访问处于异常状态，确定异常状态的次数。最后，当异常状态的次数不超过预先设置的次数阈值时，生成用于表征通过当前请求的指示信息。由于在异常向总服务器发送全局可用配额请求时可能会出现数据访问异常的情况，此时可以先确定异常状态的次数。在异常状态的次数不超过次数阈值的情况下，生成表征通过当前请求的指示信息。这样就能够避免现有技术中在网络抖动等偶尔的异常情况发生时，依然直接拦截请求，造成对请求的处理不合理的问题。从而实现了提高服务器处理请求的性能。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：

图1是本公开的一个实施例可以应用于其中的示例性系统架构图；

图2是根据本公开的用于处理信息的方法的一个实施例的流程图；

图3是根据本公开的实施例的用于处理信息的方法的一个应用场景的示意图；

图4是根据本公开的用于处理信息的方法的又一个实施例的流程图；

图5是根据本公开的用于处理信息的装置的一个实施例的结构示意图；

图6是适于用来实现本公开的实施例的电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。

图1示出了可以应用本公开的用于处理信息的方法或用于处理信息的装置的示例性架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104、服务器105和总服务器106。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件、文本编辑类应用、浏览器类应用、阅读类应用等。

终端设备101、102、103可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具有显示屏并且支持与服务器通信的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio LayerIV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中。其可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块。在此不做具体限定。

服务器105和总服务器106可以是提供各种服务的服务器。服务器105例如是可以对终端设备101、102、103发生的请求进行接收的后台服务器。后台服务器可以对客户端发送的请求进行接收和分析等处理，并生成处理结果发送至总服务器106。

需要说明的是，服务器可以是硬件，也可以是软件。当服务器为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当服务器为软件时，可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块。在此不做具体限定。

需要说明的是，本公开的实施例所提供的用于处理信息的方法一般由服务器105执行，相应地，用于处理信息的装置一般设置于服务器105中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了根据本公开的用于处理信息的方法的一个实施例的流程200。该用于处理信息的方法包括以下步骤：

步骤201，接收客户端发送的请求。

在本实施例中，用于处理信息的方法的执行主体(如图1所示的服务器105)可以接收客户端发送的请求。这里，该请求可以包括所请求的资源类别、与该资源类别对应的需求配额。

在本实施例中，资源例如可以是磁盘空间，还可以是存储器，还可以是CPU。这里的资源类别指的是某一种资源，例如磁盘空间。在分布式环境下，对应于某一请求，可能需要多台子服务器来接收该请求，然后配合完成该请求。与该资源类别对应的需求配额，例如可以是与资源类别—磁盘空间在一台子服务器上对应的需求配额2MB，即该请求需要磁盘空间在该子服务器上的资源配额量是2MB。应该可以理解，上述举例只是为了更好地解释本实施例的用于处理信息的方法，不应作为对本实施例的限定。

步骤202，响应于该需求配额大于本地的与该资源类别对应的限额值，向总服务器发送全局可用配额请求。

在本实施例中，响应于该需求配额大于本地的与该资源类别对应的限额值，上述执行主体可以向总服务器(例如图1所示的总服务器106)发送全局可用配额请求。作为示例，客户端发送的请求中，可能需要三台子服务器的内存资源。为了避免资源过度占用，因此总服务器预先给每台子服务器设置有该内存资源的限额值。这里的限额值可以理解为该资源类别的资源所指定的可用容量，即该资源在该子服务器(即本实施例的执行主体)中最多超额的限度。

当该请求中该资源类别的需求限额超过本地的限额值时，此时说明本地资源配额不够，需要向总服务器中的全局可用配额申请资源配额。此时，上述执行主体可以向总服务器发送全局可用配额请求。显然，这里的全局可用配额请求即指申请全局可用配额中资源配额的请求。

步骤203，确定数据访问是否处于异常状态。

在本实施例中，上述执行主体可以在向总服务器发送全局可用配额请求之后，确定数据访问是否处于异常状态。这里的异常状态为未在预设响应时间段内接收到总服务器针对该全局可用配额请求进行反馈的反馈信息的状态。

在本实施例中，在正常状态下，总服务器会针对该全局可用配额请求进行反馈。例如总服务器可以发送一个反馈信息至上述执行主体。当上述执行主体接收不到该反馈信息时，可以确定此时为异常状态。这里的异常状态的原因例如可以包括连接异常、访问异常等，本实施例不以此为限制。

步骤204，响应于数据访问处于异常状态，确定异常状态的次数。

在本实施例中，响应于数据访问处于异常状态，上述执行主体可以确定异常状态的次数。由于对于服务器来说，在一段时间内可能接收到很多次请求。从第一次向总服务器发送全局可用配额请求，确定数据访问处于异常状态时，可以进行异常状态计数。然后，在当前请求期间，若数据访问还是异常状态，则可以获取记录的异常状态的次数。

步骤205，响应于该异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

在本实施例中，在异常状态的次数不超过预先设置的次数阈值时，上述执行主体可以生成用于表征通过当前请求的指示信息。这里，上述执行主体可以预先设置一个次数阈值。之后，将该异常状态的次数和该次数阈值进行比较，当该异常状态的次数不超过该次数阈值时，上述执行主体可以允许当前请求通过，即生成用于表征通过当前请求的指示信息。

作为示例，例如当前异常状态的次数为3，预先设置的次数阈值是5，由于当前异常状态的次数小于5，因此上述执行主体可以生成表征通过当前请求的指示信息。例如生成信息“Yes”。这样，在网络抖动等偶发异常时，就能够通过该次数阈值的判断，来避免这样的偶尔异常现象被服务器错误判定为长期异常而直接拒绝请求，影响服务器使用性能。

在本实施例的一些可选的实现方式中，响应于该异常状态的次数不超过该次数阈值，上述执行主体还可以从本地分配上述当前请求中的资源类别对应的需求配额对应的资源量，以供该请求使用。作为示例，例如当前请求中需要使用内存资源5GB，则上述执行主体可以先从本地分配GB的内存资源以供该请求使用。之后，服务器继续执行上述用于处理信息的方法。即服务器可以继续接收客户端发送的请求，执行步骤201-205所示的方法。

在本实施例的一些可选的实现方式中，上述执行主体在从本地分配该需求配额对应的资源量之后，还可以将每次请求的需求配额进行本地记录。并且，上述执行主体还可以定时向总服务器发送全局可用配额请求。在接收到总服务器的针对该全局可用配额请求的反馈信息之后，上述执行主体可以将本地记录的需求配额的总量发送至总服务器，以及将本地记录的需求配额清零。

需要说明的是，不论数据访问处于异常状态还是正常状态，上述执行主体都可以将每次请求的需求配额进行本地记录。在数据访问处于正常状态的情况下，上述执行主体可以在接收到下一次请求时或者每隔预设时间，将本地记录的需求配额上报至总服务器，以使总服务器进行全局配额同步。这里，总服务器在接收到上述执行主体上报的本地记录的需求配额之后，从全局可用配额中扣除该需求配额对应的配额，从而做到全局配额同步。

在本实现方式中，由于此时数据访问处于异常状态，上述执行主体可以定时向总服务器发送全局可用配额请求。这样就能够及时获知数据访问是否恢复。当接收到总服务器针对全局可用配额请求的反馈信息时，此时说明数据访问恢复为正常状态。在异常状态的次数未达到次数阈值之前，每次请求的需求配额都会被上述执行主体记录在本地。则上述执行主体可以在数据访问恢复时，将本地记录的需求配额的总量发送至总服务器，即上报本地计数至全局。

之后，上述执行主体可以将本地记录的需求配额清零。这样，就不会出现下一次上报本地计数至全局时出现重复计数的情况。总服务器在接收到本地记录的需求配额的总量之后，从与该资源类别对应的全局可用配额中扣除与该需求配额的总量匹对应的配额量。从而做到在异常恢复时，将本地使用的资源配额同步至全局可用配额，避免出现现有技术中在异常恢复时没有将本地消耗的资源配额上报至全局进行同步，造成资源配额过度消耗的问题。

继续参见图3，图3是根据本公开的实施例的用于处理信息的方法的应用场景的一个示意图。在图3的应用场景中，服务器302接收客户端301发送的请求303。该请求303中包括内存资源3031和与该内存资源3031对应的需求配额30GB(需求配额3032)。

之后，服务器302将该需求配额30GB与本地的该内存资源的限额值20GB(限额值304)进行比较。由于该需求配额30GB大于该限额值20GB，因此，服务器302的本地资源不够用。服务器302可以向总服务器305发送“申请全局可用配额”(全局可用配额请求306)。

这里，服务器302需要确定数据访问是否处于异常状态。由于此时数据访问处于异常状态，服务器302需要确定异常状态的次数。此时，异常状态的次数(如附图标记307所示)为3，小于预先设置的次数阈值(如附图标记308所示)的数值5。说明此次异常可能是偶发现象，服务器302可以先生成信息“Yes”(用于表征通过当前请求的指示信息309)。

目前，现有技术之一通常是在数据访问异常时，直接拦截请求或者直接让请求通过，这样若只是偶尔出现的网络抖动等造成的短暂数据访问异常，而后数据访问又会很快恢复，如此处理请求显然是不合理的，从而造成资源分配不合理。而本公开的上述实施例提供的方法，通过在数据访问异常时，确定异常状态的次数。在异常状态的次数小于次数阈值时，生成用于表征通过当前请求的指示信息。从而避免现有技术中在网络抖动等偶尔的异常情况发生时，依然直接拦截请求，造成对请求的处理不合理的问题。从而实现了提高服务器处理请求的性能。

进一步参考图4，其示出了用于处理信息的方法的又一个实施例的流程400。该用于处理信息的方法的流程400，包括以下步骤：

步骤401，接收客户端发送的请求。

在本实施例中，用于处理信息的方法的执行主体(如图1所示的服务器)可以接收客户端发送的请求。

步骤402，累加记录每次接收到的请求的与该资源类别对应的需求配额，以及进行记录周期计时。

在本实施例中，上述执行主体可以累加记录每次接收到的请求与该资源类别对应的需求配额，以及进行记录周期计时。这里需要说明的是，服务器可能不断接收客户端发送的请求。那么，服务器可以进行一个记录周期的设置，记录每个周期接收到的请求中的与该资源类别对应的需求配额。

例如在该记录周期内(这里不需要确定数据访问是否异常)，服务器接收到了3次请求，3次请求中需要的内存资源的需求配额分别是5GB、2GB、10GB。服务器将该记录周期内的上述需求配额进行累加记录，即第一次记录内存资源需求配额5GB，第二次记录的需求配额为5GB+2GB＝7GB，第三次(当前请求时)记录的需求配额为7GB+10GB＝17GB。在本实施例中，可以将该记录周期内记录的需求配额称为本地全局计数。

需要说明的是，这里的本地全局计数和上述图2所示的实施例中的本地计数不同。这里的本地全局计数是按周期进行记录每次请求中与该资源类别对应的需求配额，与数据访问异常无关，也不需要上报至总服务器。而上述图2所示的实施例中的本地计数，是每次请求的需求配额，然后在接收到下一次请求之后，立即上报至总服务器，进行全局可用配额同步。

在本实施例的一些可选的实现方式中，在该累加记录的记录周期达到预设时长时，上述执行主体可以将记录的需求配额总量清零。之后，再次进行记录周期计时的步骤，即再次执行该步骤402。

这里的记录周期例如可以是以分钟为单位，也可以是以天为单位进行统计。例如以分钟为单位，在达到一分钟的记录周期时，则将上一分钟累加记录的所有接收到的请求中的内存资源的需求配额的总量清零。下一分钟继续记录。这样的目的是为了保证在后续的需求配额总量与可用配额阈值进行比较的过程中，不受上一记录周期的本地全局计数影响。

步骤403，响应于该需求配额大于本地的与该资源类别对应的限额值，向总服务器发送全局可用配额请求。

步骤404，确定数据访问是否处于异常状态。

步骤405，响应于数据访问处于异常状态，确定异常状态的次数。

上述步骤401、步骤403、步骤404和步骤405可以分别采用与前述实施例中的步骤201、步骤202、步骤203和步骤204类似的方式执行，并且，上文针对步骤201、步骤202、步骤203和步骤204的描述也适用于步骤401、步骤403、步骤404和步骤405，此处不再赘述。

步骤406，响应于该异常状态的次数大于次数阈值，确定当前异常状态时记录的、与该资源类别对应的需求配额的总量。

在本实施例中，在异常状态的次数大于次数阈值时，上述执行主体可以确定当前异常状态时记录的、与该资源类别对应的需求配额的总量。作为示例，假设此时异常状态的次数为6，而次数阈值为5，那么异常状态的次数大于次数阈值。说明该数据访问异常可能不是偶发现象，而可能是确实存在长时间连接异常或者其他异常情况，导致数据不能正常访问。此时，上述执行主体可以获取记录的与该资源类别对应的需求配额的总量。例如，对于内存资源，此时记录的本地全局计数为17GB。

步骤407，对该资源类别对应的全局可用配额和限额值进行求和，得到可用配额总量。

在本实施例中，上述执行主体在获取到与该资源类别对应的全局可用配额和限额值时，可以将该全局可用配额和限额值进行求和。作为示例，例如总服务器设定的与内存资源对应的全局可用配额是100GB。在该执行主体中对于该内存资源的限额值是20GB。那么，上述执行主体可以将该全局可用配额与该限额值进行求和，得到该内存资源的可用配额总量是100GB+20GB＝120GB。

步骤408，确定接收当前请求的子服务器组中的子服务器数量，以及基于该可用配额总量和子服务器数量，得到可用配额阈值。

在本实施例中，上述执行主体还可以确定接收当前请求的子服务器组中的子服务器数量。例如，该分布式系统中接收该请求的子服务器有3台。那么，该子服务器数量就为3。之后，上述执行主体可以基于该可用配额总量和该子服务器数量，得到该执行主体的可用配额阈值。例如，作为一个示例，内存资源的可用配额总量是120GB，子服务器数量是3，那么该可用配额阈值可以为120GB/3＝40GB。作为另一个示例，内存资源的可用配额总量是100GB，子服务器数量是3，那么该可用配额阈值可以是100GB/3，取整得到33GB。

步骤409，基于需求配额的总量和可用配额阈值的比较，对当前请求进行拦截或者通过的处理操作。

在本实施例中，上述执行主体可以将该需求配额的总量和该可用配额阈值进行比较，得到比较结果。然后，基于比较结果对当前请求进行拦截或者通过的处理操作。

在本实施例的一些可选的实现方式中，响应于该需求配额的总量大于该可用配额阈值，上述执行主体可以生成用于表征拦截当前请求的第一指示信息。

作为示例，例如内存资源对应的需求配额的总量为47GB，可用配额阈值为40GB。需求配额的总量大于该可用配额阈值，说明在该异常状态下，该请求中内存资源在所有子服务器上的需求配额的总量可能会超出总服务器为其设置的最大可用资源配额。因此，为了保证服务器分配资源的性能，上述执行主体可以生成用于表征拦截当前请求的第一指示信息。该第一指示信息例如可以是“Fail”。

在本实施例的一些可选的实现方式中，响应于该需求配额的总量小于或者等于该可用配额阈值，上述执行主体可以生成用于表征通过当前请求的第二指示信息。之后，上述执行主体可以从本地分配该需求配额对应的资源量。

作为示例，例如内存资源对应的需求配额的总量为17GB，可用配额阈值为40GB。需求配额的总量小于该可用配额阈值，说明在此异常状态下，该请求中内存资源在所有子服务器上的需求配额的总量可能不会超过总服务器为其设置的最大可用资源配额。此时，上述执行主体可以生成用于表征通过当前请求的第二指示信息。该第二指示信息例如可以是“Yes”。之后，为了满足客户端的该请求，上述执行主体可以从本地分配该内存资源的需求配额17GB。从而保证服务器处理请求的性能，以及最大程度上不影响客户端的资源使用。

从图4中可以看出，与图2对应的实施例相比，本实施例中的用于处理信息的方法的流程400体现了在数据访问异常的异常状态的次数大于次数阈值的情况下，将记录周期内的需求配额的总量与得到的本地可用配额阈值进行比较，从而来确定该请求中的资源类别对应的需求配额是否会超过总服务器为其设定的最大资源可用配额限值。然后基于该比较结果来对请求进行信息处理。由此，本实施例描述的方案可以在分布式全局可用配额不可用时，自动切换到本地的判断机制，然后对请求进行处理，保证服务器处理请求的性能，以及最大程度上不影响客户端的资源使用。

进一步参考图5，作为对上述各图所示方法的实现，本公开提供了用于处理信息的装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图5所示，本实施例提供的用于处理信息的装置500包括请求接收单元501、请求发送单元502、异常状态确定单元503、次数判断单元504和通过指示信息生成单元505。其中，请求接收单元501被配置成接收客户端发送的请求，其中，请求包括：所请求的资源类别、与资源类别对应的需求配额；请求发送单元502被配置成响应于需求配额大于本地的与资源类别对应的限额值，向总服务器发送全局可用配额请求；异常状态确定单元503被配置成确定数据访问是否处于异常状态，其中，异常状态为未在预设响应时段内接收到总服务器针对全局可用配额请求进行反馈的反馈信息的状态；次数判断单元504被配置成响应于数据访问处于异常状态，确定异常状态的次数；通过指示信息生成单元505被配置成响应于异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

在本实施例中，用于处理信息的装置500中：请求接收单元501、请求发送单元502、异常状态确定单元503、次数判断单元504和通过指示信息生成单元505的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201、步骤202、步骤203、步骤204和步骤205的相关说明，在此不再赘述。

在本实施例的一些可选的实现方式中，用于处理信息的装置500还可以包括记录单元(图中未示出)。其中，该记录单元可以被配置成累加记录每次接收到的请求的与资源类别对应的需求配额，以及进行记录周期计时。

在本实施例的一些可选的实现方式中，用于处理信息的装置500还可以包括需求配额总量获取单元、可用配额总量获取单元、可用配额阈值确定单元和第一处理单元(图中未示出)。其中，需求配额总量获取单元可以被配置成响应于异常状态的次数大于次数阈值，确定当前异常状态时记录的、与资源类别对应的需求配额的总量；可用配额总量获取单元可以被配置成对资源类别对应的全局可用配额和限额值进行求和，得到可用配额总量；可用配额阈值确定单元可以被配置成确定接收当前请求的子服务器组中的子服务器数量，以及基于可用配额总量和子服务器数量，得到可用配额阈值；第一处理单元可以被配置成基于需求配额的总量和可用配额阈值的比较，对当前请求进行拦截或者通过的处理操作。

在本实施例的一些可选的实现方式中，上述第一处理单元可以包括第一指示信息生成模块、第二指示信息生成模块(图中未示出)。其中，第一指示信息生成模块可以被配置成响应于需求配额的总量大于可用配额阈值，生成用于表征拦截当前请求的第一指示信息；第二指示信息生成模块可以被配置成响应于需求配额的总量小于或者等于可用配额阈值，生成用于表征通过当前请求的第二指示信息，以及从本地分配需求配额对应的资源量。

在本实施例的一些可选的实现方式中，用于处理信息的装置500还可以包括第二处理单元(图中未示出)。其中，该第二处理单元可以被配置成响应于记录周期达到预设时长，将记录的需求配额的总量清零，以及再次执行记录单元中的方法。

在本实施例的一些可选的实现方式中，用于处理信息的装置500还可以包括第三处理单元(图中未示出)。其中，该第三处理单元可以被配置成响应于异常状态的次数不超过次数阈值，从本地分配需求配额对应的资源量，以及继续执行第一方面或第一方面任一实施例的方法。

在本实施例的一些可选的实现方式中，用于处理信息的装置500还可以包括本地记录单元、全局可用配额请求发送单元、第四处理单元(图中未示出)。其中，本地记录单元可以被配置成将每次请求的需求配额进行本地记录；全局可用配额请求发送单元可以被配置成定时向总服务器发送全局可用配额请求；第四处理单元可以被配置成响应于接收到总服务器的针对全局可用配额请求的反馈信息，将本地记录的需求配额的总量发送至总服务器，以及将本地记录的需求配额清零，其中，总服务器接收到本地记录的需求配额的总量，从与资源类别对应的全局可用配额中扣除与本地记录的需求配额的总量对应的配额量。

本公开的上述实施例提供的装置，通过次数判断单元504在数据访问异常时，确定异常状态的次数。通过指示信息生成单元505在异常状态的次数小于次数阈值时，生成用于表征通过当前请求的指示信息。从而避免现有技术中在网络抖动等偶尔的异常情况发生时，依然直接拦截请求，造成对请求的处理不合理的问题。从而实现了提高服务器处理请求的性能。

下面参考图6，下面参考图6，其示出了适于用来实现本公开的实施例的电子设备(例如图1中的服务器)600的结构示意图。图6示出的服务器仅仅是一个示例，不应对本公开的实施例的功能和使用范围带来任何限制。

如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD，LiquidCrystal Display)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。图6中示出的每个方框可以代表一个装置，也可以根据需要代表多个装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本公开的实施例的方法中限定的上述功能。

需要说明的是，本公开的实施例所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开的实施例中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(Radio Frequency，射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该服务器中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该服务器执行时，使得该服务器：接收客户端发送的请求，其中，该请求包括：所请求的资源类别、与资源类别对应的需求配额；响应于需求配额大于本地的与资源类别对应的限额值，向总服务器发送全局可用配额请求；确定数据访问是否处于异常状态，其中，异常状态为未在预设响应时段内接收到总服务器针对全局可用配额请求进行反馈的反馈信息的状态；响应于数据访问处于异常状态，确定异常状态的次数；响应于异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

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

附图中的流程图和框图，图示了按照本公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开的实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器，包括：请求接收单元、请求发送单元、异常状态确定单元、次数判断单元和通过指示信息生成单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，请求接收单元还可以被描述为“用于接收请求的单元”。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开的实施例中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (16)

1.一种用于处理信息的方法，包括：

接收客户端发送的请求，其中，所述请求包括：所请求的资源类别、与所述资源类别对应的需求配额；

响应于所述需求配额大于本地的与所述资源类别对应的限额值，向总服务器发送全局可用配额请求；

确定数据访问是否处于异常状态，其中，所述异常状态为未在预设响应时段内接收到总服务器针对所述全局可用配额请求进行反馈的反馈信息的状态；

响应于所述数据访问处于异常状态，确定异常状态的次数；

响应于所述异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

2.根据权利要求1所述的方法，其中，在所述接收客户端发送的请求之后，所述方法还包括：

累加记录每次接收到的请求的与所述资源类别对应的需求配额，以及进行记录周期计时。

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

响应于所述异常状态的次数大于所述次数阈值，确定当前异常状态时记录的、与所述资源类别对应的需求配额的总量；

对所述资源类别对应的全局可用配额和所述限额值进行求和，得到可用配额总量；

确定接收所述当前请求的子服务器组中的子服务器数量，以及基于所述可用配额总量和所述子服务器数量，得到可用配额阈值；

基于所述需求配额的总量和所述可用配额阈值的比较，对所述当前请求进行拦截或者通过的处理操作。

4.根据权利要求3所述的方法，其中，所述基于所述需求配额的总量和所述可用配额阈值的比较，对所述当前请求进行拦截或者通过的处理操作，包括：

响应于所述需求配额的总量大于所述可用配额阈值，生成用于表征拦截所述当前请求的第一指示信息；

响应于所述需求配额的总量小于或者等于所述可用配额阈值，生成用于表征通过所述当前请求的第二指示信息，以及从本地分配所述需求配额对应的资源量。

5.根据权利要求2所述的方法，其中，所述方法还包括：

响应于所述记录周期达到预设时长，将记录的需求配额的总量清零，以及再次进行记录周期计时的步骤。

6.根据权利要求1所述的方法，其中，所述方法还包括：

响应于所述异常状态的次数不超过所述次数阈值，从本地分配所述需求配额对应的资源量，以及继续执行权利要求1所述的用于处理信息的方法。

7.根据权利要求4或6所述的方法，其中，所述从本地分配所述需求配额对应的资源量之后，所述方法还包括：

将每次请求的所述需求配额进行本地记录；

定时向所述总服务器发送全局可用配额请求；

响应于接收到所述总服务器的针对所述全局可用配额请求的反馈信息，将本地记录的需求配额的总量发送至所述总服务器，以及将本地记录的需求配额清零，其中，所述总服务器接收到所述本地记录的需求配额的总量，从与所述资源类别对应的全局可用配额中扣除与所述本地记录的需求配额的总量对应的配额量。

8.一种用于处理信息的装置，包括：

请求接收单元，被配置成接收客户端发送的请求，其中，所述请求包括：所请求的资源类别、与所述资源类别对应的需求配额；

请求发送单元，被配置成响应于所述需求配额大于本地的与所述资源类别对应的限额值，向总服务器发送全局可用配额请求；

异常状态确定单元，被配置成确定数据访问是否处于异常状态，其中，所述异常状态为未在预设响应时段内接收到总服务器针对所述全局可用配额请求进行反馈的反馈信息的状态；

次数判断单元，被配置成响应于所述数据访问处于异常状态，确定异常状态的次数；

通过指示信息生成单元，被配置成响应于所述异常状态的次数不超过预先设置的次数阈值，生成用于表征通过当前请求的指示信息。

9.根据权利要求8所述的装置，其中，所述装置还包括：

记录单元，被配置成累加记录每次接收到的请求的与所述资源类别对应的需求配额，以及进行记录周期计时。

10.根据权利要求9所述的装置，其中，所述装置还包括：

需求配额总量获取单元，被配置成响应于所述异常状态的次数大于所述次数阈值，确定当前异常状态时记录的、与所述资源类别对应的需求配额的总量；

可用配额总量获取单元，被配置成对所述资源类别对应的全局可用配额和所述限额值进行求和，得到可用配额总量；

可用配额阈值确定单元，被配置成确定接收所述当前请求的子服务器组中的子服务器数量，以及基于所述可用配额总量和所述子服务器数量，得到可用配额阈值；

第一处理单元，被配置成基于所述需求配额的总量和所述可用配额阈值的比较，对所述当前请求进行拦截或者通过的处理操作。

11.根据权利要求10所述的装置，其中，所述第一处理单元包括：

第一指示信息生成模块，被配置成响应于所述需求配额的总量大于所述可用配额阈值，生成用于表征拦截所述当前请求的第一指示信息；

第二指示信息生成模块，被配置成响应于所述需求配额的总量小于或者等于所述可用配额阈值，生成用于表征通过所述当前请求的第二指示信息，以及从本地分配所述需求配额对应的资源量。

12.根据权利要求9所述的装置，其中，所述装置还包括：

第二处理单元，被配置成响应于所述记录周期达到预设时长，将记录的需求配额的总量清零，以及再次执行记录单元中所述的方法。

13.根据权利要求8所述的装置，其中，所述装置还包括：

第三处理单元，被配置成响应于所述异常状态的次数不超过所述次数阈值，从本地分配所述需求配额对应的资源量，以及继续执行权利要求8所述的装置。

14.根据权利要求11或13所述的装置，其中，所述装置还包括：

本地记录单元，被配置成将每次请求的所述需求配额进行本地记录；

全局可用配额请求发送单元，被配置成定时向所述总服务器发送全局可用配额请求；

第四处理单元，被配置成响应于接收到所述总服务器的针对所述全局可用配额请求的反馈信息，将本地记录的需求配额的总量发送至所述总服务器，以及将本地记录的需求配额清零，其中，所述总服务器接收到所述本地记录的需求配额的总量，从与所述资源类别对应的全局可用配额中扣除与所述本地记录的需求配额的总量对应的配额量。

15.一种电子设备，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7中任一所述的方法。

16.一种计算机可读介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如权利要求1-7中任一所述的方法。