一种资源请求处理方法、装置及服务器

技术领域

本申请涉及游戏技术领域，尤其涉及一种资源请求处理方法、装置及服务器。

背景技术

在网络游戏中，例如大型多人在线角色扮演游戏(Massively MultiplayerOnline Role-Playing Game，MMORPG)，为了应对大规模玩法的性能压力，通常采用分区分服的游戏架构，即将玩家分散在不同的游戏服务器中，从而实现性能压力的分摊效果。这种方案一方面如果玩家数量庞大，需要配备较多的游戏服务器，不仅有较高的硬件成本，也有较大的维护成本；另一方面由于不同游戏服务器中的玩家通常不会发生交集，致使某个玩家只能与部分其他玩家进行游戏交互。

为了提高玩家游戏体验，在某些游戏玩法中，例如帮派玩法等，玩法复杂以及玩家数量众多，通常采用将位于不同游戏服务器的游戏玩家汇聚在一个专门的跨服服务器中的方式，让不同的玩家共同体验游戏。那么，由于大规模玩家同屏体验游戏，该跨服服务器同样会存在性能压力，导致卡顿、无响应等问题，影响玩家游戏体验。

发明内容

本申请提供一种资源请求处理方法、装置及服务器，能够减少游戏服务器处理游戏客户端资源请求的次数，从而降低游戏服务器的性能压力，缓解卡顿及无响应的问题。

一方面，本申请提供了一种资源请求处理方法，所述方法包括：

对预设性能压力指标进行监控，并根据所述监控结果对资源池中各请求类型对应的请求额度进行调节；

当接收到资源请求时，根据所述资源请求对应的请求类型，确定所述资源请求是否为热点请求；

若所述资源请求为所述热点请求，则判断所述资源池中所述请求类型对应的请求额度是否大于所述请求类型对应的预设额度阈值；

若所述请求类型对应的请求额度大于所述请求类型对应的预设额度阈值，则允许处理所述资源请求，并将所述请求类型对应的请求额度减第一预设数值；

若所述请求类型对应的请求额度小于或等于所述请求类型对应的预设额度阈值，则拒绝处理所述资源请求。

另一方面提供了一种资源请求处理装置，所述装置包括：

性能监控模块，用于对预设性能压力指标进行监控，并根据所述监控结果对资源池中各请求类型对应的请求额度进行调节；

请求接收模块，用于接收资源请求；

热点请求确定模块，用于根据所述资源请求对应的请求类型，确定所述资源请求是否为热点请求；

额度确定模块，用于在所述资源请求为所述热点请求的情况下，判断所述资源池中所述请求类型对应的请求额度是否大于所述请求类型对应的预设额度阈值；

请求处理模块，用于在所述请求类型对应的请求额度大于所述请求类型对应的预设额度阈值的情况下，允许处理所述资源请求，并将所述请求类型对应的请求额度减第一预设数值；在所述请求类型对应的请求额度小于或等于所述请求类型对应的预设额度阈值的情况下，拒绝处理所述资源请求。

另一方面提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由所述处理器加载并执行如上所述的资源请求处理方法。

本申请通过预设性能压力指标实时监控游戏服务器的性能压力，动态调节各请求类型对应的请求额度；在接收到游戏客户端的资源请求后，先确定该资源请求是否是热点请求，若不是热点请求则允许处理该资源请求；若是热点请求，只有在该热点请求具有一定请求额度时才允许处理该热点请求。通过这种调整游戏服务器对游戏客户端热点请求的响应，达到降低游戏服务器的性能压力的目的，不仅可以缓解卡顿以及无响应问题，也可以节省硬件成本和维护成本。

附图说明

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

图1是本申请实施例提供的现有技术性能压力分摊示意图。

图2是本申请实施例提供的一种资源请求处理方法的流程示意图。

图3是本申请实施例提供的对请求额度进行调节的流程示意图。

图4是本申请实施例提供的对请求额度进行调节的示例图。

图5是本申请实施例提供的另一种资源请求处理方法的流程示意图。

图6是本申请实施例提供的区域划分的示例图。

图7是本申请实施例提供的对区域进行扩大处理的流程示意图。

图8是本申请实施例提供的对区域进行扩大处理的一个示例图。

图9是本申请实施例提供的对区域进行扩大处理的另一个示例图。

图10是本申请实施例提供的资源请求处理方法的一个示例流程图。

图11是本申请实施例提供的一种资源请求处理装置的结构示意图。

图12是本申请实施例提供的另一种资源请求处理装置的结构示意图。

图13是本申请实施例提供的另一种资源请求处理装置的结构示意图。

图14是本申请实施例提供的一种用于实现本申请实施例所提供的资源请求处理方法的服务器的硬件结构框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先对本说明书实施例中涉及的相关名词做以下解释：

网络游戏(Online Game)：也称在线游戏，一般指多名玩家透过计算机互联网进行交互娱乐的电子游戏。

大型多人在线角色扮演游戏(Massively Multiplayer Online Role-PlayingGame，MMORPG)：网络游戏的一种，在MMORPG中，玩家可扮演一个或多个角色，并控制该角色在游戏虚拟世界中的活动参与。

游戏客户端(Game Client)：指为客户提供本地服务的程序，一般安装在普通的用户电脑上，需要与游戏服务器互相配合运行。当然，游戏客户端还可以安装在智能手机、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备、监控设备及语音交互设备等类型的设备上。

游戏服务器(Game Server)：为游戏客户端提供数据计算、校验、存储和转发等功能的服务软件程序，需游戏开发商保证其稳定运作和正常的服务功能。

游戏跨服：指不同游戏服务器的玩家，可以汇聚在特定的跨服服务器上进行对战，比如跨服对战，用于打通服务器边界，给玩家更自由的游戏体验。

帮派：指游戏中多名玩家组成的一个团体。

帮派玩法：指帮派一起参与具有玩家聚集特性的玩法，帮派玩法具有人群聚集、游戏服务器的CPU以及网络性能消耗大等特点。

为了应对帮派玩法的性能压力，现有技术通过采用分布式部署的方式，将玩家分布在不同的游戏地图实例中，这些游戏地图实例装在不同游戏服务器上，从而实现性能压力的分摊效果。如图1所示，如果总玩家数为5000，可将其中3000的玩家分布在游戏服务器1上，将另2000的玩家分布在游戏服务器2上。可以理解的，在玩家数众多的情况下，需要使用更多的游戏服务器才能达到压力的分摊效果。而在一些帮派玩法中，需要不同游戏服务器上的玩家聚集在同一跨服服务器上，该跨服服务器需要支持大规模玩家的同屏体验，跨服服务器仍然存在性能压力，致使卡顿以及无响应问题影响玩家游戏体验。

为了降低游戏服务器的性能压力，防止卡顿以及无响应问题影响玩家游戏体验，同时节省硬件成本和维护成本，本申请实施例提供了一种资源请求处理方法。

以下以游戏服务器为执行主体对本申请实施例的资源请求处理方法进行阐述。图2是本申请实施例提供的一种资源请求处理方法的流程示意图，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，所述方法可以包括：

S201，对预设性能压力指标进行监控，并根据所述监控结果对资源池中各请求类型对应的请求额度进行调节。

本申请实施例中，预设性能压力指标用于衡量游戏服务器的性能压力，性能压力包括CPU压力和/或网络压力。通常，可以通过CPU使用率来衡量游戏服务器的CPU压力，通过网络丢包率来衡量游戏服务器的网络压力。但由于网络专线的使用，网络压力往往并不是主要因素，因此CPU压力将会是影响游戏服务器的性能压力的一个重要因子，而网络压力可以作为性能压力的辅助参考。比如，如果CPU压力占性能压力的80％，网络压力则占性能压力的20％，即性能压力＝80％*CPU压力+20％*网络压力。当然，这个比例值根据场景的不同而有所不同。

每个请求类型对应的请求额度，为在第一预设时间内，允许游戏客户端发送的与该请求类型对应的资源请求的数量。游戏服务器通过实时监控CPU使用率和/或网络丢包率，每间隔第一预设时间，动态调节资源池中各请求类型对应的请求额度。其中，请求类型用于指示游戏客户端发送的资源请求的类型，例如，技能、移动、修改角色信息以及查询角色信息等等。

如图3所示，所述根据所述监控结果对资源池中各请求类型对应的请求额度进行调节，可以包括：

S2011，根据所述监控结果确定所述预设性能压力指标是否达到预设瓶颈值。

若所述预设性能压力指标未到达所述预设瓶颈值，则执行步骤S2012；若所述预设性能压力指标达到所述预设瓶颈值，则执行步骤S2013。

S2012，对于所述资源池中每个请求类型，按照预设方式增加所述请求类型对应的请求额度。

S2013，对于所述资源池中每个请求类型，将所述请求类型对应的请求额度设置为所述请求类型对应的预设初始额度值。

本申请实施例中，预设瓶颈值是指用于指示性能压力异常的值，每个请求类型对应的预设初始额度值，是指游戏服务器为该请求类型设置的请求额度的初始值。每种请求类型对应的初始值可以根据该请求类型对性能压力的影响程度进行设置。通常而言，初始值可以设置为不对性能压力产生影响的值，或者将初始值设置为允许该请求类型对应的资源请求的最小数量。

如果监控结果指示预设性能压力指标未达到预设瓶颈值，即CPU压力和/或网络压力正常，则增加每个请求类型对应的请求额度；一旦预设性能压力指标达到预设瓶颈值，即CPU压力和/或网络压力异常/过大，则将每个请求类型对应的请求额度均调整为对应的初始值；当CPU压力和/或网络压力下降后，再增加每个请求类型对应的请求额度，并一直重复整个动态调节过程。

本申请实施例中，预设方式可以包括指数方式、线性方式以及固定值方式中任意一种或任意组合。相应的，指数方式增加是指请求额度按照指数速度增加，线性方式增加是指请求额度按照线性速度增加，固定值方式增加是指将请求额度设置为固定额度，即请求额度保持不变。

由于在不同时间段，游戏服务器的性能压力有不同，指数速度过快，将会对游戏服务器产生的较大的冲击力；而固定额度不能适应不同性能压力的变化，因而通常采用这几种方式的组合对每个请求类型对应的请求额度进行调节。

具体而言，步骤S2012可以包括：当所述请求类型对应的请求额度小于预设指数阈值时，以指数方式增加所述请求类型对应的请求额度；当所述请求类型对应的请求额度大于或等于所述预设指数阈值，且所述请求类型对应的请求额度小于预设额度上限时，以线性方式增加所述请求类型对应的请求额度；当所述请求类型对应的请求额度大于或等于所述预设额度上限时，将所述请求类型对应的请求额度设置为所述请求类型对应的预设固定额度值。

对于每种请求类型，除预设初始额度值外，游戏服务器还为每种请求类型设置了三个用于调节对应请求额度的值，分别为预设指数阈值、预设额度上限以及预设固定额度值。其中，预设指数阈值是指该请求类型对应的请求额度按照指数速度增加时，所允许的最大额度值；预设额度上限是是指该请求类型对应的请求额度按照线性速度增加时，所允许的最大额度值。在具体实施时，也可以将预设额度上限作为请求额度的上限。

举例说明，若用t表示时间，用x表示预设初始额度值，用p表示预设指数阈值，则在t时刻，按照指数方式增加所得到的请求额度可以用x

如图4所示，其为本申请实施例提供的请求额度调节机制的一个示例。在图4中，游戏服务器每秒为技能投放一定的请求额度，资源池一开始为技能对应的请求额度设置的初始值较低。如果性能压力正常，则请求额度指数速度增加，保证请求额度的快速提升；在t1时刻，请求额度达到预设指数阈值之后，改为线性增加，防止过度增加；在t2时刻，请求额度达到预设额度上限之后，改为固定额度，保证性能压力平稳；在t3时刻监控到性能压力过大，触发惩罚机制，请求额度下降为初始值；经过一段时间，在t4时刻监控到性能压力下降之后，再指数速度增加。如此，按照指数-线性-固定的调节方式重复前面的过程，实现对请求额度的动态调节。可以理解的，图4中示出的预设固定额度值与预设额度上限相等，实际应用中两者也可以设置为不同，在此不做具体限定。

需要说明的是，对于预设初始额度值、预设指数阈值、预设额度上限以及预设固定额度值额等预设值，可以根据具体应用场景进行设置。经过验证，若仅考虑CPU压力，在x86_64主频2300MHZ的12核CPU下，对于单体伤害技能，当预设初始额度值设置为23500次/秒时，CPU使用率为12％；当预设指数阈值设置为87100次/秒时，CPU使用率为48％；当预设额度上限设置为125000次/秒时，CPU使用率为80％；当CPU使用率达到90％，性能达到瓶颈即预设瓶颈值设置为90％。

另外，不同玩法中不同请求类型对性能压力产生影响程度不同，因而在实际应用中，可以通过玩法来限定各请求类型对应的请求额度。例如在聚集玩法中，技能的释放会消耗比较多的资源，而移动会影响其他玩家的视野信息，这两种请求类型都是使用比较频繁，可以为这两种请求类型限制请求额度。但在其他玩法中，如果移动不会影响其他玩家的视野信息，游戏服务器也不需要通知周围玩家，那么就不需要限制移动对应的请求额度。

S202，当接收到资源请求时，根据所述资源请求对应的请求类型，确定所述资源请求是否为热点请求。

在网络游戏中，当虚拟对象需要请求资源时，例如释放技能、移动，触发资源请求，游戏服务器在接收到虚拟对象的资源请求后，根据资源请求对应的请求类型，对该资源请求进行处理。其中，虚拟对象是指在网络游戏中虚拟的对象，为游戏虚拟世界中的虚拟游戏角色。游戏服务器中存储有热点请求列表，该热点请求列表中存储有热点请求类型，如果资源请求对应的请求类型属于热点请求类型，则判定该资源请求为热点请求。

需要说明的是，本申请实施例中的资源请求包括了任何来自游戏客户端的请求，而并不局限于上述的技能、移动等资源。游戏服务器也可以只对热点请求类型对应的请求额度进行限制，而不是对所有请求类型。

考虑到不同玩法中不同请求类型消耗的资源不同，在一些实施例中，热点请求列表中存储的热点请求类型也可以根据玩法进行配置。游戏服务器还可以获取当前玩法类型，根据当前玩法类型和资源请求对应的请求类型，联合确定该资源请求是否为热点请求。

若所述资源请求为所述热点请求，则执行步骤S203；若所述资源请求不是所述热点请求，则允许处理所述资源请求。

S203，判断所述资源池中所述请求类型对应的请求额度是否大于所述请求类型对应的预设额度阈值。

若所述请求类型对应的请求额度大于所述请求类型对应的预设额度阈值，则执行步骤S204；若所述请求类型对应的请求额度小于或等于所述请求类型对应的预设额度阈值，则执行步骤S205。

只有在请求类型对应的请求额度还足够时，游戏服务器才对该资源请求做处理，每个请求类型对应的预设额度阈值可以相同也可以不同。在具体实施时，通常将该预设额度阈值设置为零，也就是说，只要资源池中该请求类型还有请求额度，就可以对该资源请求进行处理。

S204，允许处理所述资源请求，并将所述请求类型对应的请求额度减第一预设数值。

可以理解的，处理一次资源请求就会消耗掉对应的请求额度，第一预设数值可以设置为1。当然，也可以按照其他递减方式进行处理。

S205，拒绝处理所述资源请求。

网络游戏的特点是所有数据的处理都在游戏服务器完成，而影响游戏服务器能否支持大规模玩家同屏的一个重要因素，是游戏服务器能否及时对玩家的资源请求进行处理。尤其是帮派玩法，大量来自游戏客户端的请求冲击游戏服务器，比如角色移动、角色技能等请求。除此之外，游戏服务器还需要计算玩家各种属性变化，比如血量、功力以及能量条等，然后广播给其他玩家，整个玩法过程消耗大量的CPU和网络性能。本申请实施例通过调整游戏服务器对来自游戏客户端的资源请求的响应机制，从而降低性能压力，实现在不同性能压力下的不同玩法表现。

在实际应用中，诸如帮派这种玩法还有区域聚集性的特点，同一张游戏地图中不同区域，玩家的聚集程度差异性很大。一张游戏地图中其他区域可能还存在其他玩法，比如挖宝玩法，因此游戏服务器还尽可能保证具有区域聚集性特点的玩法不影响这些普通玩法。

例如，在同一张游戏地图中，区域1中是帮派玩法，玩家数量多，可以将区域1看作是热点区域；区域2中是挖宝玩法，玩家数量少，可以将区域2看作是非热点区域。当在区域1中的玩家A向游戏服务器发送一个资源请求后，该资源请求是热点请求，由于没有对应的请求额度，游戏服务器拒绝处理该资源请求，并提示玩家A“当前玩家数量众多，稍后再试”，玩家A很容易接受这种提示。而当区域2中的玩家B向游戏服务器发送一个资源请求后，该资源请求也是热点请求，由于没有对应的请求额度，游戏服务器拒绝处理该资源请求，并提示玩家A“当前玩家数量众多，稍后再试”，但此时区域2中的玩家并不多，如果仍拒绝处理该资源请求，会给玩家B带来很不好的游戏体验。

基于以上描述，在一些实施例中，如图5所示，在步骤S203之前，所述方法还可以包括：

S501，判断触发所述资源请求的虚拟对象是否在热点区域内。

若所述虚拟对象在所述热点区域内，则执行步骤S203，继续根据请求额度确定是否处理该资源请求；若所述虚拟对象不在所述热点区域内，则执行步骤S204，允许处理所述资源请求。

本申请实施例中，对于热点区域的识别可以有两种方式：一是通过游戏玩法确定，如果该虚拟对象对应的游戏玩法是具有区域聚集性特点的玩法，可以直接判定属于热点区域；二是通过虚拟对象的位置来确定。具体的，获取所述虚拟对象的地图标识，根据所述地图标识确定所述虚拟对象是否在热点区域内。其中，所述地图标识用于指示所述虚拟对象在游戏地图中的位置。

为了更好的根据地图标识来确定虚拟对象是否在热点区域，本申请实施例的资源请求处理方法还可以包括：将地图划分为预设个数区域；针对每个所述区域，当所述区域的第一聚集指标达到第一指标阈值时，将所述区域标记为热点区域。通过将一张游戏地图划分为不同区域，并将每个区域标记为热点区域和非热点区域，就很容易根据地图标识来确定出虚拟对象是否在热点区域了。

其中，每个区域的第一聚集指标用于指示该区域的聚集程度，游戏服务器可以通过该区域中虚拟对象数量和/或该区域中资源请求数量，来衡量该区域的聚集程度。在实际应用中，这种方式至少可以囊括一个区域中大量玩家每人发送适量资源请求，以及少数玩家发送大量资源请求等情况。

在网络游戏架构中，一张游戏地图就是一个游戏地图实例，如图6所示，其为一张游戏地图中区域划分的示例图。在图6中，将每个区域采用矩形表示，每个区域的大小是固定的。但在实际应用中，游戏玩法种类复杂，例如MMORPG玩法，固定的区域划分是无法准确表示虚拟对象的聚集程度的，因此本申请实施例在所述将所述区域标记为热点区域之后，还对所述区域进行扩大处理。通过采用地图区域反馈机制，来动态调整区域的大小。可以理解的，在实际应用中，每个区域也可以采用圆形等规则形状或其他不规则形状表示。

具体参照图7中所示，所述对所述区域进行扩大处理，可以包括：

S701，将所述区域作为待处理区域，将所述区域的第一聚集指标作为参考指标。

S702，将所述待处理区域的中心点保持不变，将所述待处理区域的边界按照预设尺度系数延伸，得到第一区域。

S703，对所述第一区域的第一聚集指标进行统计，得到当前指标。

S704，根据所述当前指标与所述参考指标，得到指标变化速率。

游戏服务器将当前指标与参考指标的差值，除以两次指标统计的时间差，得到指标变化速率。

S705，判断所述第一区域的边界是否达到所述区域对应的预设边界，并且，所述指标变化速率是否大于预设速率阈值。

当所述第一区域的边界未达到所述区域对应的预设边界，并且，所述指标变化速率大于预设速率阈值时，执行步骤S706；当所述第一区域的边界达到所述区域对应的预设边界，或者，所述指标变化速率小于或等于所述预设速率阈值时，执行步骤707。

S706，将所述第一区域作为所述待处理区域，将所述当前指标作为所述参考指标。然后返回步骤S702。

S707，将所述第一区域确定为所述区域。

以矩形区域为例，如图8所示，当游戏服务器统计到某个区域出现了大量玩家和/或大量游戏客户端请求，首先将该区域标记为热点区域，然后动态调整区域的大小，并统计玩家数量和/或请求数量的变化。每次对区域的动态扩大过程，即将该区域的中心点位置保持不变，将该区域的边界框的长和宽延伸，延伸至原来长的预设尺度系数倍，以及延伸至原来宽的预设尺度系数倍。每次扩大后，统计聚集指标的变化速率，当指标变化速率低于预设速率阈值，或者区域扩大至预设边界时，停止区域扩张。游戏服务器为游戏地图中的每个区域设置对应的预设边界，每个区域在扩大过程中，只能扩张至对应的预设边界，以确保整个扩大过程的性能消耗。

对于扩张后的区域，如果该区域的玩家数和/或游戏客户端请求数都在下降，可以将该区域恢复至初始区域，以确保区域能合理的反馈聚集程度。因此，在一些实施例中，在所述对所述区域进行扩大处理之后，所述方法还包括：当所述区域的第二聚集指标小于或等于第二指标阈值时，将所述区域的大小恢复为所述对所述区域进行扩大处理之前所述区域的大小。其中，第二聚集指标的设置可以与第一聚集指标相同，也可以不同。

如图9中所示，初始区域在经过两次扩大处理后，该区域的大小变为第二次扩大后区域的大小。在保持第二次扩大后区域大小后，游戏客户端若检测到第二次扩大后区域中的玩家数在急剧下降，那么可以将该区域的大小恢复为初始区域的大小，以确保游戏服务器确定热点区域的合理性。

通过基于区域的动态反馈，确定出玩家的聚集程度后，对于该区域中的一些特定资源请求，将根据该资源请求对应的请求额度被动态限制，使得游戏服务器在一定的性能压力下，即使聚集程度较高的区域即热点区域中的玩家也有较好的游戏体验。

游戏服务器在处理每次资源请求时，如果该资源请求不是热点请求，或者是热点请求但不在热点区域中，将允许处理该资源请求。但当该资源请求次数过多时，也可以将该资源请求当做热点请求处理。

因而，在一些实施例中，在每次允许处理资源请求之后，所述方法还包括：将所述请求类型对应的请求次数加第二预设数值；判断所述请求类型对应的请求次数是否达到预设请求次数阈值；若达到，则检测所述请求类型是否在热点请求列表中；若否，则将所述请求类型加入到所述热点请求列表中。

下面以释放热点技能为例，对本申请实施例的资源请求处理方法进行详细说明。如图10中所示，游戏服务器在处理释放技能时，主要包括如下过程：

(1)游戏服务器先判断释放的技能是否是热点请求类型，对于非热点请求类型，允许直接释放，并统计释放次数，超过阈值则将该释放的技能加入热点请求列表中。

(2)在热点请求列表中的热点请求类型，判断玩家是否在热点区域中释放该技能，对于非热点区域，允许直接释放技能。

(3)对于热点区域中的释放技能请求，会判断资源池中该技能是否还有额度，没有额度则禁止释放，有额度允许释放，并统计技能释放次数。资源池每秒都会为技能投放一定额度，通过每秒额度限制，保证游戏服务器不会被大量游戏客户端的释放技能请求冲垮。

由上述本申请提供的实施例可见，本申请通过预设性能压力指标实时监控游戏服务器的性能压力，动态调节各请求类型对应的请求额度；在接收到游戏客户端的资源请求后，先确定该资源请求是否是热点请求，若不是热点请求则允许处理该资源请求；若是热点请求，只有在该热点请求具有一定请求额度时才允许处理该热点请求。通过这种调整游戏服务器对游戏客户端热点请求的响应，达到降低游戏服务器的性能压力的目的，不仅可以缓解卡顿以及无响应问题，也可以节省硬件成本和维护成本。通过为不同玩法设置不同的热点请求列表，可以实现在不同性能压力下的不同玩法表现。

本申请实施例还提供了一种资源请求处理装置，如图11所示，所述装置包括：

性能监控模块1110，用于对预设性能压力指标进行监控，并根据所述监控结果对资源池中各请求类型对应的请求额度进行调节；

请求接收模块1120，用于接收资源请求；

热点请求确定模块1130，用于根据所述资源请求对应的请求类型，确定所述资源请求是否为热点请求；

额度确定模块1140，用于在所述资源请求为所述热点请求的情况下，判断所述资源池中所述请求类型对应的请求额度是否大于所述请求类型对应的预设额度阈值；

请求处理模块1150，用于在所述请求类型对应的请求额度大于所述请求类型对应的预设额度阈值的情况下，允许处理所述资源请求，并将所述请求类型对应的请求额度减第一预设数值；在所述请求类型对应的请求额度小于或等于所述请求类型对应的预设额度阈值的情况下，拒绝处理所述资源请求。

具体的，所述性能监控模块1110可以包括：

性能瓶颈确定单元，用于根据所述监控结果确定所述预设性能压力指标是否达到预设瓶颈值；

额度增加单元，用于在所述预设性能压力指标未到达所述预设瓶颈值的情况下，对于所述资源池中每个请求类型，按照预设方式增加所述请求类型对应的请求额度；

额度恢复单元，用于在所述预设性能压力指标达到所述预设瓶颈值的情况下，对于所述资源池中每个请求类型，将所述请求类型对应的请求额度设置为所述请求类型对应的预设初始额度值。

具体的，所述额度增加单元可以包括：

指数增加单元，用于当所述请求类型对应的请求额度小于预设指数阈值时，以指数方式增加所述请求类型对应的请求额度；

线性增加单元，用于当所述请求类型对应的请求额度大于或等于所述预设指数阈值，且所述请求类型对应的请求额度小于预设额度上限时，以线性方式增加所述请求类型对应的请求额度；

固定增加单元，用于当所述请求类型对应的请求额度大于或等于所述预设额度上限时，将所述请求类型对应的请求额度设置为所述请求类型对应的预设固定额度值。

在一些实施例中，如图12所示，所述装置还可以包括：

热点区域确定模块1160，用于判断触发所述资源请求的虚拟对象是否在热点区域内。

该装置在具体实施时，通过热点区域确定模块1160确定虚拟对象不在热点区域内，则允许处理该资源请求；如果不在热点区域内，则通过额度确定模块1140继续检测是否有对应的请求额度。

具体的，热点区域确定模块1160可以包括：

地图标识获取单元，用于获取所述虚拟对象的地图标识，所述地图标识用于指示所述虚拟对象在游戏地图中的位置；

热点区域确定单元，用于根据所述地图标识确定所述虚拟对象是否在热点区域内。

在一些实施例中，如图13所示，所述装置还可以包括：

区域划分模块1170，用于将游戏地图划分为预设个数区域；

区域标记模块1180，用于针对每个所述区域，当所述区域的第一聚集指标达到第一指标阈值时，将所述区域标记为热点区域。

具体的，所述区域标记模块1180可以包括：

区域扩大单元，用于在将所述区域标记为热点区域后，对所述区域进行扩大处理。

区域恢复单元，用于当所述区域的第二聚集指标小于或等于第二指标阈值时，将所述区域的大小恢复为所述对所述区域进行扩大处理之前所述区域的大小。

具体的，所述区域扩大单元可以包括：

第一预处理单元，用于将所述区域作为待处理区域，将所述区域的第一聚集指标作为参考指标；

延伸单元，用于将所述待处理区域的中心点保持不变，将所述待处理区域的边界按照预设尺度系数延伸，得到第一区域；

第一指标统计单元，用于对所述第一区域的第一聚集指标进行统计，得到当前指标；

第二指标统计单元，用于根据所述当前指标与所述参考指标，得到指标变化速率；

第二预处理单元，用于当所述第一区域的边界未达到所述区域对应的预设边界，并且，所述指标变化速率大于预设速率阈值时，将所述第一区域作为所述待处理区域，将所述当前指标作为所述参考指标；

区域确定单元，用于当所述第一区域的边界达到所述区域对应的预设边界，或者，所述指标变化速率小于或等于所述预设速率阈值时，将所述第一区域确定为所述区域。

在具体实施时，该装置通过延伸单元不断对当前处理区域进行延伸，当延伸得到的区域不满足条件时，经过第二预处理单元处理后，重复延伸单元的处理过程。

在一些实施例中，所述装置还包括热点请求类型确定模块，所述热点请求类型确定模块用于：将所述请求类型对应的请求次数加第二预设数值；判断所述请求类型对应的请求次数是否达到预设请求次数阈值；若达到，则检测所述请求类型是否在热点请求列表中；若否，则将所述请求类型加入到所述热点请求列表中。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本申请实施例还提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由所述处理器加载并执行上述方法实施例所提供的资源请求处理方法。

存储器可用于存储软件程序以及模块，处理器通过运行存储在存储器的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、功能所需的应用程序等；存储数据区可存储根据所述设备的使用所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器还可以包括存储器控制器，以提供处理器对存储器的访问。

服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

进一步地，图14是本申请实施例提供的一种用于实现本申请实施例提供的资源请求处理方法的服务器的硬件结构框图。如图14所示，该服务器1400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，CPU)1410(处理器1410可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1430，一个或一个以上存储应用程序1423或数据1422的存储介质1420(例如一个或一个以上海量存储设备)。其中，存储器1430和存储介质1420可以是短暂存储或持久存储。存储在存储介质1420的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1410可以设置为与存储介质1420通信，在服务器1400上执行存储介质1420中的一系列指令操作。服务器1400还可以包括一个或一个以上电源1460，一个或一个以上有线或无线网络接口1450，一个或一个以上输入输出接口1440，和/或，一个或一个以上操作系统1421，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

本领域普通技术人员可以理解，图14所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器1400还可包括比图14中所示更多或者更少的组件，或者具有与图14所示不同的配置。

本申请实施例还提供了一种计算机存储介质，该计算机存储介质中存储有至少一条指令或至少一段程序，该至少一条指令或至少一段程序由处理器加载并执行以实现上述方法实施例提供的资源请求处理方法。

可选地，在本实施例中，上述计算机存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。服务器的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得服务器执行上述的方法实施例提供的资源请求处理方法。

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

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

上述说明已经充分揭露了本申请的具体实施方式。需要指出的是，熟悉该领域的技术人员对本申请的具体实施方式所做的任何改动均不脱离本申请的权利要求书的范围。相应地，本申请的权利要求的范围也并不仅仅局限于前述具体实施方式。