CN108989369B - 对用户请求进行限流的方法及其系统 - Google Patents

Abstract

本公开提供了一种对用户请求进行限流的方法，该方法包括：获取本次对指定统一资源定位符URL进行请求的用户请求，其中，指定URL能够被请求的总次数不大于被请求次数阈值；获取被请求次数阈值和指定URL当前已被请求的次数，其中，当前已被请求的次数包含本次；以及若当前已被请求的次数大于被请求次数阈值，则禁止服务器响应用户请求。本公开还提供了一种对用户请求进行限流的系统和一种非易失性存储介质。

Description

对用户请求进行限流的方法及其系统

技术领域

本公开涉及网络技术领域，更具体地，涉及一种对用户请求进行限流的方法及其系统。

背景技术

对于任何一个web应用而言，当用户请求量过大时往往会拖垮整个服务器，因而在实际工程中一般会通过限流来保护服务器。例如，对于一些抢夺稀缺资源(如抢购、秒杀等)的应用场景，尤其需要使用限流策略来保护服务器。

在现有技术中，提供了一种限流方案，即应用服务器利用niginx服务器提供的限流策略来进行限流。Niginx可以提供limit_zone和limit_req_zone。其中，limit_zone用于配置一个客户端IP最多能够发起多少次请求，limit_req_zone用于配置一个客户端IP发送请求的最大频率。

在实现本发明构思的过程中，发明人发现现有技术中至少存在如下问题：现有技术提供的方案只能对客户端的用户请求进行限流，无法对服务器端的用户请求进行限流。

发明内容

本公开的一个方面提供了一种对用户请求进行限流的方法，包括：获取本次对指定统一资源定位符URL进行请求的用户请求，其中，上述指定URL能够被请求的总次数不大于被请求次数阈值；获取上述被请求次数阈值和上述指定URL当前已被请求的次数，其中，上述当前已被请求的次数包含本次；以及若上述当前已被请求的次数大于上述被请求次数阈值，则禁止服务器响应上述用户请求。

根据本公开实施例，获取上述被请求次数阈值包括：获取上述用户请求对应的方法体，其中，上述方法体中包含有上述服务器响应上述用户请求时需要执行的方法，且其上带有自定义注解，上述自定义注解中至少包括上述被请求次数阈值；从上述方法体上带有的上述自定义注解中获取上述被请求次数阈值，和/或，从指定存储装置中获取上述被请求次数阈值。

根据本公开实施例，上述方法还包括：对上述指定存储装置中存储的上述被请求次数阈值进行修改。

根据本公开实施例，上述方法还包括：若上述当前已被请求的次数大于上述被请求次数阈值，则进行告警。

根据本公开实施例，在获取上述被请求次数阈值和上述指定URL当前已被请求的次数之前，上述方法还包括：判断获取上述用户请求的时间是否在对上述用户请求进行限流的有效时期内，其中，若是，则获取上述被请求次数阈值和上述当前已被请求的次数。

根据本公开实施例，在获取上述被请求次数阈值和上述指定URL当前已被请求的次数之前，上述方法还包括：获取上述用户请求对应的方法体，其中，上述方法体中包含有上述服务器响应上述用户请求时需要执行的方法；以及检测上述方法体上是否带有自定义注解，其中，若检测到上述方法体上带有上述自定义注解，则获取上述被请求次数阈值和上述当前已被请求的次数。

本公开的另一方面还提供了一种对用户请求进行限流的系统，包括：第一获取模块，用于获取本次对指定统一资源定位符URL进行请求的用户请求，其中，上述指定URL能够被请求的总次数不大于被请求次数阈值；第二获取模块，用于获取上述被请求次数阈值和上述指定URL当前已被请求的次数，其中，上述当前已被请求的次数包含本次；以及处理模块，用于在上述当前已被请求的次数大于上述被请求次数阈值的情况下，禁止服务器响应上述用户请求。

根据本公开实施例，上述第二获取模块包括：第一获取单元，用于获取上述用户请求对应的方法体，其中，上述方法体中包含有上述服务器响应上述用户请求时需要执行的方法，且其上带有自定义注解，上述自定义注解中至少包括上述被请求次数阈值；第二获取单元，用于从上述方法体上带有的上述自定义注解中获取上述被请求次数阈值，和/或，第三获取单元，用于从指定存储装置中获取上述被请求次数阈值。

根据本公开实施例，上述系统还包括：修改模块，用于对上述指定存储装置中存储的上述被请求次数阈值进行修改。

根据本公开实施例，上述系统还包括：告警模块，用于在上述当前已被请求的次数大于上述被请求次数阈值的情况下，进行告警。

根据本公开实施例，上述系统还包括：判断模块，用于在获取请求次数模块之前，判断获取上述用户请求的时间是否在对上述用户请求进行限流的有效时期内，其中，上述第二获取模块还用于在是的情况下，获取上述被请求次数阈值和上述当前已被请求的次数。

根据本公开实施例，上述系统还包括：第三获取模块，用于在获取请求次数模块之前，获取上述用户请求对应的方法体，其中，上述方法体中包含有上述服务器响应上述用户请求时需要执行的方法；以及检测模块，用于检测上述方法体上是否带有自定义注解，其中，上述第二获取模块还用于在检测到上述方法体上带有上述自定义注解的情况下，获取上述被请求次数阈值和上述当前已被请求的次数。

本公开的另一方面还提供了一种非易失性存储介质，其上存储有可执行指令，上述指令被处理器执行时用于实现上述任一项所述的对用户请求进行限流的方法。

本公开的另一方面还提供了一种对用户请求进行限流的系统，包括：处理器和上述非易失性存储介质。

附图说明

为了更完整的理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开实施例的对用户请求进行限流的方法及其系统的系统架构图；

图2示意性示出了根据本公开实施例的对用户请求进行限流的方法及其系统的应用场景图；

图3示意性示出了根据本公开实施例的对用户请求进行限流的方法的流程图；

图4示意性示出了根据本公开另一实施例的用户请求进行限流的方法的流程图；

图5示意性示出了根据本公开实施例的用户请求进行限流的系统的框图；以及

图6示意性示出了根据本公开实施例的用户请求进行限流的系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。这里使用的词语“一”、“一个(种)”和“该”等也应包括“多个”、“多种”的意思，除非上下文另外明确指出。此外，在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。

因此，本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。在本公开的上下文中，计算机可读介质可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，计算机可读介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。计算机可读介质的具体示例包括：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；和/或有线/无线通信链路。

图1示意性示出了根据本公开实施例的对用户请求进行限流的方法及其系统的系统架构图。

如图1所示，系统架构100可以包括终端设备101、终端设备102、终端设备103，网络104和服务器105(此架构仅仅是示例，具体架构中包含的组建可以根据申请具体情况调整)。网络104用以在终端设备101、终端设备102、终端设备103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

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

终端设备101、终端设备102、终端设备103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、终端设备102、终端设备103所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本公开实施例所提供的对用户请求进行限流的方法及其系统可以由服务器105执行，也可以由不同于服务器105的另外一个服务器或者一个服务器集群执行。相应地，对用户请求进行限流的系统可以设置于服务器105中，也可以设置与服务器105以外的另一个服务器或者一个服务器集群中。

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

本公开实施例所提供的对用户请求进行限流的方法及其系统的应用场景可以包括多种，在此不做限定。

图2示意性示出了根据本公开实施例的对用户请求进行限流的方法及其系统的应用场景图。

如图2所示，为了请求对指定的统一资源定位符(Uniform Resource Location，简称为URL)进行访问，先由用户201通过客户端向应用服务器202发起一个请求，，为了避免应用服务器202端访问量过大，应用服务器202在响应该请求之前，需要先确定是否对其进行限流。具体地，应用服务器202需要获取该指定URL的被请求次数阈值，即该指定URL能够被请求的最大次数，被请求次数阈值可以标注在与用户请求对应的方法体的自定义注解中，还可以存储在另一个服务器中，如Redis服务器203中。因此在获取该被请求次数阈值时，至少可以从上述自定义注解中或者上述Redis服务器203中获取。当应用服务器202从Redis服务器203获取时，若发现Redis服务器203中并没有存放被请求次数阈值的相关信息，则从自定义注解中获取被请求次数阈值；若发现Redis服务器203中有该指定URL的被请求次数阈值，则直接获取。此外，管理员204可以通过配置页面修改Redis服务器203中关于被请求次数阈值的设定，实现动态配置各URL的被请求次数阈值的目的。

需要说明的是，对于一个web应用而言，当用户请求量过大时，极有可能拖垮整个服务器，因而需要对用户请求限流以保护服务器。

进一步，每个web应用可能包括一个或者多个应用于不同场景的URL，针对不同的URL，其对应的用户请求的限流次数一般也不一样。例如，对于一些需要抢夺稀缺资源的应用场景(如抢购、秒杀、申请试用商品等)，其限流次数一般与被抢购或者被秒杀的稀缺资源的数量有关。

例如，某电商网站上上线了一种可以申请试用的商品A，且当前可申请试用的商品A只有10000件，此时，如果不对用于指示申请试用商品A的用户请求限流，那么一旦请求量超过10000次，一方面，超出的用户请求肯定无法如期望的那样申请到商品A，另一方面，超大量的用户请求几乎同时要求服务器对其响应，因而极易导致服务器崩溃。

因此，为解决上述问题，最好将对应的最大用户请求量限定为10000次。具体地，可以通过设置用户请求所针对的URL的被请求次数阈值来实现对上述用户请求进行限流的目的。其中，此处用户请求所针对的URL可以是申请试用商品A需要访问的网页地址。

本领域普通技术人员可以理解，上述应用场景仅为示意，其并不对上述对用户请求进行限流的方法及其系统的应用场景造成限定。

本公开实施例提供了一种对用户请求进行限流的方法，以下结合附图对本公开进行详细阐述。

图3示意性示出了根据本公开实施例的对用户请求进行限流的方法的流程图。如图3所示，该方法可以包括如下操作：

操作S301，获取本次对指定统一资源定位符URL进行请求的用户请求，其中，该指定URL能够被请求的总次数不大于被请求次数阈值。

需要说明的是，在执行限流操作之前，需要预先设置好该指定URL的被请求次数阈值，即，该指定URL的最大被请求次数。

根据本公开实施例，操作S301可以由服务器执行，更具体地，可以由设置在服务器中的Spring MVC中的Interceptor拦截器执行。

实施时，每次有用户针对上述指定URL向服务器发送用户请求后，在服务器响应之前，先通过Interceptor拦截器拦截用户请求，以确定是否对该用户请求进行限流，再根据确认结果决定服务器是否需要响应该用户请求。

具体地，Interceptor拦截器可以采用prehandle方法获取用户对该指定URL进行请求的用户请求。

操作S302，获取被请求次数阈值和指定URL当前已被请求的次数，其中，当前已被请求的次数包含本次。

需要说明的是，获取被请求次数阈值的方式可以包括多种，在此不做限定。例如，预先设定的被请求次数阈值可以标注在与用户请求对应的方法体的自定义注解中，还可以存储在另一个服务器中，如Redis服务器中。对应的，可以通过读取对应的自定义注解来获取该被请求次数阈值，还可以从Redis服务器中获取该被请求次数阈值。

此外，获取指定URL当前已被请求的次数的方式可以包括多种，在此不做限定。例如，上述Redis服务器还可以记录指定URL之前已被请求的次数，基于此，获取指定URL当前已被请求的次数时，可以先从该Redis服务器中读取该指定URL在本次请求之前已被请求的次数，在加上本次请求即可。

根据本公开实施例，例如，Redis服务器对指定URL存储有两种key-value对，一种是被请求次数阈值的key-value对，该key-value的key为指定URL请求相对应的字符串，value为被请求次数阈值；另一种是指定URL在本次请求之前已被请求的次数的key-value对，这个key-value对的key为请求的指定URL，value是指定URL在本次请求之前已被请求的次数。

进一步，在拦截到本次请求之后，首先检查Redis服务器中是否有被请求次数阈值的key-value对，也就是key为指定URL请求相对应的字符串的key-value对，如果没有，则在Redis服务器中设置key为指定URL请求相对应的字符串，value为被请求次数阈值的key-value对，设置被请求次数阈值的key-value对可以使用Redis服务器的setNx功能，对应的，就可以通过Interceptor拦截器中的prehandle方法从Redis服务器中获取被请求次数阈值了；然后设置指定URL在本次请求之前已被请求的次数的key-value对，也就是key为指定URL请求，value为0的key-value对，如果是第一次调用指定URL请求，则将这个请求对应的URL为key的值初始化为0，调用Redis服务器自增key为指定URL在本次请求之前已被请求的次数的key-value对的值，自增返回的结果就是指定URL在本次请求之前已被请求的次数。基于此，获取指定URL当前已被请求的次数时，可以通过Interceptor拦截器中的prehandle方法先从该Redis服务器中读取该指定URL在本次请求之前已被请求的次数，在加上本次请求即可。例如，设置被请求次数阈值为1000，若当前已经执行的次数为1000，并未超过被请求次数阈值，但是加上本次请求后，请求次数就大于被请求次数阈值，此时，需要对用户请求限流；若当前已经执行的次数为998，并未超过被请求次数阈值，并且加上本次请求后，请求次数就也并不大于被请求次数阈值，此时，不需要对用户请求限流。

操作S303，若当前已被请求的次数大于被请求次数阈值，则禁止服务器响应用户请求。

在获取被请求次数阈值和指定URL当前已被请求的次数之后，比较两者之间的大小关系。若后者不大于前者，则允许服务器响应对应的用户请求；若后者大于前者，则禁止服务器响应对应的用户请求。依此，可以实现基于URL对用户请求限流的目的。

根据本公开实施例，在采用Interceptor拦截器中的prehandle方法读取被请求次数阈值和指定URL当前已被请求的次数后，将被请求次数阈值的和指定URL当前已被请求的次数进行对比，若指定URL当前已被请求的次数不大于被请求次数阈值，则prehandle方法返回true，执行用户请求相应的方法体，即，允许服务器响应该用户请求；若指定URL当前已被请求的次数大于被请求次数阈值，则prehandle方法返回false，执行Interceptor拦截器中的afterCompletion方法，并退出Interceptor拦截器，且不对用户请求进行处理，即，禁止服务器响应该用户请求。

例如，预先设置好的被请求次数阈值为5000，假设指定URL在本次请求之前已被请求的次数为4999，加上本次请求之后，该指定URL当前已被请求的次数就为5000，那么该指定URL的当前已被请求次数就不大于被请求次数阈值，则prehandle方法返回true，此时允许服务器响应该用户请求并执行该用户请求对应的方法体；假设指定URL在本次请求之前已被请求的次数为5000，加上本次请求之后，该指定URL当前已被请求的次数就为5001，那么该指定URL的当前已被请求次数就大于被请求次数阈值，则prehandle方法返回false，此时执行Interceptor拦截器中的afterCompletion方法，并退出Interceptor拦截器，且不对用户请求进行任何处理，即，禁止服务器响应该用户请求。

需要说明的是，对于一个Web应用中可能会有一个或多个针对不同场景的URL，一旦这些用户对这些URL的请求过大，极有可能拖垮服务器。而相关技术只能在客户端对指定URL的请求次数和请求频率进行限流，限流方法单一，实现效果也不理想，如不能解决服务器端用户请求会过量的问题，因而相关技术中在客户端对用户请求限流时，无法解决服务器端容易出现用户请求过量的问题。与相关技术相比，本公开实施例中提供的对用户请求进行限流的方案可以针对不同的URL请求在服务器端设置对应的被请求次数阈值，也就是最大请求次数，以实现从服务器侧限流的目的。使用本方案，一旦指定URL的当前已被请求次数超过了被请求次数阈值，则禁止服务器响应对应的用户请求，大大提高了限流的效果，降低了服务器的压力。

根据本公开实施例，获取被请求次数阈值可以包括：获取用户请求对应的方法体，其中，方法体中包含有服务器响应用户请求时需要执行的方法，且其上带有自定义注解，自定义注解中至少包括被请求次数阈值；从方法体上带有的自定义注解中获取被请求次数阈值，和/或，从指定存储装置中获取被请求次数阈值。

换言之，根据本公开实施例，获取被请求次数阈值的方式可以包括以下之一：从对应的自定义注解中获取；从指定存储装置中获取；从对应的自定义注解和指定存储装置中获取。需要说明的是，此处的存储装置可以是一个服务器，具体地，可以是一个Redis服务器。

需要说明的是，应用服务器响应用户请求需要执行的方法构成响应的方法体，方法体中预先标注有自定义注解，如Java注解。自定义注解中包含有指定URL的被请求次数阈值，除此之外，其中还可以包含有限流时间周期类型、限流时间数值以及限流发生报警人员等信息。例如，设置报警人员为空串，限流时间周期类型为天，限流时间数值为1，被请求次数阈值为1000，则表示为在1天的时间内对指定URL的最大请求次数为1000次，由于此时报警人员为空串，因此即使超出1000次，系统也不会告警。

由于用户请求与对应的方法体具有一定的映射关系，因此，在拦截到一个用户请求后，根据预设映射关系可以找到陔用户请求对应的方法体，进而从标注在该方法体中的Java注解中读取指定URL的被请求次数阈值。

需要说明的是，当针对某一URL的请求需要进行限流时，在对应的方法体中就需要标注Java注解；当针对某一URL的请求不需要进行限流时，在对应的方法体中就不需要标注Java注解。

此外，根据本公开的实施例，获取被请求次数阈值的方法还可以是从其他服务器(如Redis服务器)中获取。以Redis服务器为例，在Redis服务器中可以根据实际需要存储被请求次数阈值，因此，可以从Redis服务器中直接获取该被请求次数阈值。

通过本公开实施例，可以采用多种方式设置URL的被请求次数阈值，使得获取被请求次数阈值的途径更多、获取方式更灵活。

根据本公开实施例，对用户请求进行限流的方法还可以包括：对指定存储装置中存储的被请求次数阈值进行修改。

指定存储装置可以以多种形式存在，在此不做限定。例如，指定存储装置可以是Redis服务器。指定URL的被请求次数阈值可以以key-value对的形式存储在Redis服务器中。其中，key-value对中的key为指定URL与配置构成的字符串，value为指定URL的被请求次数阈值。

需要说明的是，被请求次数阈值设置之后是可以修改的，修改方式可以包括多种，在此不再限定，如：方式1是修改自定义注解中的设置；方式2是修改Redis服务器中的设置。其中，使用方式1修改时，必须重新发布方法体对应的程序；而使用方式2修改时，无需重新发布方法体对应的程序，实现不用上线代码就能修改被请求次数阈值的目的。对于方式2而言，可以通过配置页面修改Redis服务器中的被请求次数阈值，使得被请求次数阈值的设置方式更加灵活。

根据本公开实施例，对用户请求进行限流的方法还可以包括：若当前已被请求的次数大于被请求次数阈值，则进行告警。

由于与用户请求对应的方法体的自定义注释中包含被请求次数阈值、限流时间周期类型、限流时间数值以及限流发生报警人员等信息，因此，当Interceptor拦截器采用prehandle拦截到用户请求时，可以从对应的方法体的自定义注解中读取限流发生报警人员的相关信息，因而在当前已被请求次数大于被请求次数阈值时，就向上述限流发生报警人员的信息表示的人员发送告警信息以实现告警目的，从而使得工作人员及时采取措施以避免服务器由于被过量访问而崩溃。

根据本公开实施例，在获取被请求次数阈值和指定URL当前已被请求的次数之前，对用户请求进行限流的方法还可以包括：判断获取用户请求的时间是否在对用户请求进行限流的有效时期内，其中，若是，则获取被请求次数阈值和当前已被请求的次数。

例如，假设对用户请求的限流策略被设定在2017年05月01日～2017年05月31日，则认为该限流策略的有效期为1个月，即2017年05月，其他时期均为无效期。

在本公开实施例中，通过先判断获取用户请求的时间是否在对用户请求进行限流的有效时期内，可以避免用户请求的时间已超出对用户请求进行限流的有效时期后，还执行“获取被请求次数阈值和指定URL当前已被请求的次数”等相关操作，而导致系统不断做无用功，降低限流效率。

根据本公开实施例，在获取被请求次数阈值和指定URL当前已被请求的次数之前，对用户请求进行限流的方法还可以包括：获取用户请求对应的方法体，其中，方法体中包含有服务器响应用户请求时需要执行的方法；以及检测所述方法体上是否带有自定义注解，其中，若检测到方法体上带有自定义注解，则获取被请求次数阈值和当前已被请求的次数。

当SpringMVC的Interceptor拦截器拦截到针对指定URL的用户请求后，通过用户请求与方法体的映射关系找到对应的方法体，其中，该方法体中包含有服务器响应用户请求时需要执行的方法，然后检测该方法体中是否带有自定义注解(如Java注解)，若没有自定义注解则不需要对用户请求进行限流，若检测到方法体上带自定义注解，则需要用户请求进行限流。

通过本公开实施例，由于只对标注了自定义注解的方法体对应的用户请求执行对应的限流操作，而对其他方法体对应的用户请求不执行任何限流操作，因而可以使限流操作更具有针对性，提高对用户请求的限流效率。

以下结合附图，以一个具体实施例为例，详细阐述本公开。

图4示意性示出了根据本公开另一实施例的用户请求进行限流的方法的流程图。如图4所示，该方法包括如下操作：

操作S401，用户发出一个URL请求。

根据本公开实施例，用户针对指定URL向服务器发出用户请求，该指定URL的用户请求被服务器拦截，具体地，可以由服务器中的Spring MVC中的Interceptor拦截器对用户请求进行拦截。

操作S402，确定该URL是否带有自定义注解。

当Interceptor拦截器拦截到用户请求后，先采用prehandle方法获取该用户请求对应的方法体，再检测该方法体中是否带有自定义注解(如Java注解)，若没有自定义注解，则不需要对用户请求进行限流，若带有自定义注解，则执行操作S403。

需要说明的是，当针对某一URL的请求需要进行限流时，在对应的方法体中就需要标注自定义注解；当针对某一URL的请求不需要进行限流时，在对应的方法体中就不需要标注自定义注解。

操作S403，获取自定义注解中的被请求次数阈值，或者获取Redis服务器中的被请求次数阈值。

需要说明的是，在执行限流操作之前，需要预先设置好指定URL的被请求次数阈值，即，指定URL的最大被请求次数。

根据本公开实施例，获取被请求次数阈值的方式可以包括多种，在此不做限定。例如，预先设定的被请求次数阈值可以标注在与用户请求对应的方法体的自定义注解中，还可以存储在另一个服务器中，如Redis服务器。对应的，可以通过读取对应的自定义注解来获取该被请求次数阈值，还可以从Redis服务器中获取该被请求次数阈值。例如，Redis服务器对指定URL存储有两种key-value对，一种是被请求次数阈值的key-value对，该key-value的key为指定URL请求相对应的字符串，value为被请求次数阈值；另一种是指定URL在本次请求之前已被请求的次数的key-value对，这个key-value对的key为请求的指定URL，value是指定URL在本次请求之前已被请求的次数。

具体地，在响应用户请求之前，服务器中的prehandle方法可以通过读取用户请求对应的方法体中的自定义注解来获取该被请求次数阈值。由于该用户请求与对应的方法体具有一定的映射关系，因此，根据该映射关系可以找到该方法体，进而从标注在方法体中的自定义注解中读取被请求次数阈值。然后，服务器检查Redis服务器中是否有被请求次数阈值的key-value对，也就是key为指定URL请求相对应的字符串的key-value对，如果没有则在Redis服务器中设置key为指定URL请求相对应的字符串，value为被请求次数阈值的key-value对，设置被请求次数阈值的key-value对可以使用Redis服务器的setNx功能。

操作S404，获取自定义注解中的限流时间周期，用Redis的setNx初始化该指定URL在本次请求之前已被请求的次数为0，并且超时时间为限流时间周期。

需要说明的是，指定URL在方法体中标注的自定义注解中除了包含有被请求次数阈值之外，还可以包含有限流时间周期类型、限流时间数值以及限流发生报警人员等相关信息。

具体地，Interceptor拦截器中的prehandle方法从指定URL在方法体中标注的自定注解中获取限流时间周期类型和限流时间数值，即，限流时间周期，然后使用设置Redis服务器中的指定URL在本次请求之前已被请求的次数的key-value对，也就是key为指定URL请求，value为0的key-value对，如果是第一次调用指定URL请求则将这个请求对应的url为key的值初始化为0，设置指定URL在本次请求之前已被请求的次数的key-value对可以使用Redis服务器的setNx功能，并且陔指定URL在本次请求之前已被请求的次数的key-value对的过期时间为从自定注解中获取的限流时间周期类型和限流时间数值。

操作S405，利用Redis的Incr方法对指定URL在本次请求之前已被请求的次数的key-value对为key的值进行自增，并记录返回结果为在本次请求之前已被请求的次数。

每次用户对指定URL请求时，Redis服务器中的指定URL在本次请求之前已被请求的次数的key-value对为key对应的value值就增加1。更具体的，可以利用Redis的Incr方法对指定URL在本次请求之前已被请求的次数的key-value对为key的值进行自增处理。进一步，用户请求次数每完成一次自增计算后，Redis服务器都要记录Incr方法返回的自增后的结果，并将该自增结果作为该指定URL在本次请求之前已被请求的次数。

操作S406，获取Redis中存储的该指定URL的被请求次数阈值。

根据本公开实施例，由于可以在Redis服务器中预先设置指定URL的被请求次数阈值，因此，直接可以从Redis服务器中直接获取该指定URL的被请求次数阈值。

操作S407，将被请求次数阈值与指定URL的当前已被请求次数相比，确定被请求次数阈值是否大于指定URL的当前已被请求次数。若否，则执行操作S408；若是，则执行操作S409。

在获取被请求次数阈值和指定URL当前已被请求的次数之后，比较两者之间的大小关系。若后者不大于前者，则允许服务器响应对应的用户请求；若后者大于前者，则禁止服务器响应对应的用户请求。依此，可以实现基于URL对用户请求限流的目的。

操作S408，获取自定义注解中的人员进行报警。

根据本公开实施例，若被请求次数阈值大于指定URL的当前已被请求次时，则需要获取指定URL在方法体中标注的自定义注解中的限流发生报警人员的相关信息，然后根据该相关信息向对应的限流发生报警人员发送报警信息，同时禁止服务器响应该用户请求。

操作S409，执行与用户请求对应的方法体。

其中，执行该用户请求相应的方法体即允许服务器响应陔用户请求。

本公开的实施例还提供了一种能够应用该对用户请求进行限流的方法的对用户请求进行限流的系统。

图5示意性示出了根据本公开实施例的用户请求进行限流的系统的框图。如图5所示，该系统500包括：第一获取模块501、第二获取模块502、处理模块503。

第一获取模块501用于获取本次对指定统一资源定位符URL进行请求的用户请求，其中，指定URL能够被请求的总次数不大于被请求次数阈值。

需要说明的是，在执行限流操作之前，需要预先设置好该指定URL的被请求次数阈值，即，该指定URL的最大被请求次数。

根据本公开实施例，可以通过服务器获取本次对指定统一资源定位符URL进行请求的用户请求，更具体地，可以通过设置在服务器中的Spring MVC中的Interceptor拦截器获取。

实施时，每次有用户针对上述指定URL向服务器发送用户请求后，在服务器响应之前，先通过Interceptor拦截器拦截用户请求，以确定是否对该用户请求进行限流，再根据确认结果决定服务器是否需要响应该用户请求。

具体地，Interceptor拦截器可以采用prehandle方法获取用户对该指定URL进行请求的用户请求。

第二获取模块502用于获取被请求次数阈值和指定URL当前已被请求的次数，其中，当前已被请求的次数包含本次。

需要说明的是，获取被请求次数阈值的方式可以包括多种，在此不做限定。例如，预先设定的被请求次数阈值可以标注在与用户请求对应的方法体的自定义注解中，还可以存储在另一个服务器中，如Redis服务器中。对应的，可以通过读取对应的自定义注解来获取该被请求次数阈值，还可以从Redis服务器中获取该被请求次数阈值。

此外，获取指定URL当前已被请求的次数的方式可以包括多种，在此不做限定。例如，上述Redis服务器还可以记录指定URL之前已被请求的次数，基于此，获取指定URL当前已被请求的次数时，可以先从陔Redis服务器中读取陔指定URL在本次请求之前已被请求的次数，在加上本次请求即可。

根据本公开实施例，例如，Redis服务器对指定URL存储有两种key-value对，一种是被请求次数阈值的key-value对，该key-value的key为指定URL请求相对应的字符串，value为被请求次数阈值；另一种是指定URL在本次请求之前已被请求的次数的key-value对，这个key-value对的key为请求的指定URL，value是指定URL在本次请求之前已被请求的次数。

进一步，在拦截到本次请求之后，首先检查Redis服务器中是否有被请求次数阈值的key-value对，也就是key为指定URL请求相对应的字符串的key-value对，如果没有，则在Redis服务器中设置key为指定URL请求相对应的字符串，value为被请求次数阈值的key-value对，设置被请求次数阈值的key-value对可以使用Redis服务器的setNx功能，对应的，就可以通过Interceptor拦截器中的prehandle方法从Redis服务器中获取被请求次数阈值了；然后设置指定URL在本次请求之前已被请求的次数的key-value对，也就是key为指定URL请求，value为0的key-value对，如果是第一次调用指定URL请求，则将这个请求对应的URL为key的值初始化为0，调用Redis服务器自增key为指定URL在本次请求之前已被请求的次数的key-value对的值，自增返回的结果就是指定URL在本次请求之前已被请求的次数。基于此，获取指定URL当前已被请求的次数时，可以通过Interceptor拦截器中的prehandle方法先从该Redis服务器中读取该指定URL在本次请求之前已被请求的次数，在加上本次请求即可。例如，设置被请求次数阈值为1000，若当前已经执行的次数为1000，并未超过被请求次数阈值，但是加上本次请求后，请求次数就大于被请求次数阈值，此时，需要对用户请求限流；若当前已经执行的次数为998，并未超过被请求次数阈值，并且加上本次请求后，请求次数就也并不大于被请求次数阈值，此时，不需要对用户请求限流。

处理模块503用于若当前已被请求的次数大于被请求次数阈值，则禁止服务器响应用户请求。

在获取被请求次数阈值和指定URL当前已被请求的次数之后，比较两者之间的大小关系。若后者不大于前者，则允许服务器响应对应的用户请求；若后者大于前者，则禁止服务器响应对应的用户请求。依此，可以实现基于URL对用户请求限流的目的。

根据本公开实施例，在采用Interceptor拦截器中的prehandle方法读取被请求次数阈值和指定URL当前已被请求的次数后，将被请求次数阈值的和指定URL当前已被请求的次数进行对比，若指定URL当前已被请求的次数不大于被请求次数阈值，则prehandle方法返回true，执行用户请求相应的方法体，即，允许服务器响应该用户请求；若指定URL当前已被请求的次数大于被请求次数阈值，则prehandle方法返回false，执行Interceptor拦截器中的afterCompletion方法，并退出Interceptor拦截器，且不对用户请求进行处理，即，禁止服务器响应该用户请求。

需要说明的是，对于一个Web应用中可能会有一个或多个针对不同场景的URL，一旦这些用户对这些URL的请求过大，极有可能拖垮服务器。而相关技术只能在客户端对指定URL的请求次数和请求频率进行限流，限流方法单一，实现效果也不理想，如不能解决服务器端用户请求会过量的问题，因而相关技术中在客户端对用户请求限流时，无法解决服务器端容易出现用户请求过量的问题。与相关技术相比，本公开实施例中提供的对用户请求进行限流的方案可以针对不同的URL请求在服务器端设置对应的被请求次数阈值，也就是最大请求次数，以实现从服务器侧限流的目的。使用本方案，一旦指定URL的当前已被请求次数超过了被请求次数阈值，则禁止服务器响应对应的用户请求，大大提高了限流的效果，降低了服务器的压力。

根据本公开实施例，第二获取模块可以包括：第一获取单元，用于获取用户请求对应的方法体，其中，方法体中包含有服务器响应用户请求时需要执行的方法，且其上带有自定义注解，自定义注解中至少包括被请求次数阈值；第二获取单元，用于从方法体上带有的自定义注解中获取被请求次数阈值，和/或，第三获取单元，用于从指定存储装置中所述被请求次数阈值。

根据本公开实施例，对用户请求进行限流的系统还可以包括：修改模块，用于对指定存储装置中存储的被请求次数阈值进行修改。

根据本公开实施例，对用户请求进行限流的系统还可以包括：告警模块，用于在当前已被请求的次数大于被请求次数阈值的情况下，进行告警。

根据本公开实施例，对用户请求进行限流的系统还可以包括：判断模块，用于在获取请求次数模块之前，判断获取用户请求的时间是否在对用户请求进行限流的有效时期内，其中，第二获取模块还用于在是的情况下，获取被请求次数阈值和当前已被请求的次数。

根据本公开实施例，对用户请求进行限流的系统还可以包括：第三获取模块，用于在获取请求次数模块之前，获取用户请求对应的方法体，其中，方法体中包含有服务器响应用户请求时需要执行的方法；以及检测模块，用于检测方法体上是否带有自定义注解，其中，第二获取模块还用于在检测到方法体上带有自定义注解的情况下，获取被请求次数阈值和当前已被请求的次数。

需要说明的是，装置部分实施例中各模块/单元/子单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再赘述。

本公开的另一方面还提供了一种非易失性存储介质，其上存储有可执行指令，指令被处理器执行时用于实现上述任一项对用户请求进行限流的方法。

本公开的另一方面还提供了一种对用户请求进行限流的系统，包括：处理器和上述非易失性存储介质。

图6示意性示出了根据本公开实施例的用户请求进行限流的系统的框图。

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

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(CPU)601执行时，执行本公开的系统中限定的上述功能。

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

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

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送图片获取请求的单元”。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (12)

1.一种对用户请求进行限流的方法，包括：

获取本次对指定统一资源定位符URL进行请求的用户请求，其中，所述指定URL能够被请求的总次数不大于被请求次数阈值；

判断获取所述用户请求的时间是否在对所述用户请求进行限流的有效时期内；

响应于判断结果表征获取所述用户请求的时间是在对所述用户请求进行限流的有效时期内，获取所述被请求次数阈值和所述指定URL当前已被请求的次数，其中，所述当前已被请求的次数包含本次；以及

若所述当前已被请求的次数大于所述被请求次数阈值，则禁止服务器响应所述用户请求。

2.根据权利要求1所述的方法，其中，获取所述被请求次数阈值包括：

获取所述用户请求对应的方法体，其中，所述方法体中包含有所述服务器响应所述用户请求时需要执行的方法，且其上带有自定义注解，所述自定义注解中至少包括所述被请求次数阈值；

从所述方法体上带有的所述自定义注解中获取所述被请求次数阈值，

和/或，

从指定存储装置中获取所述被请求次数阈值。

3.根据权利要求2所述的方法，其中，所述方法还包括：对所述指定存储装置中存储的所述被请求次数阈值进行修改。

4.根据权利要求1所述的方法，其中，所述方法还包括：若所述当前已被请求的次数大于所述被请求次数阈值，则进行告警。

5.根据权利要求1所述的方法，其中，在获取所述被请求次数阈值和所述指定URL当前已被请求的次数之前，所述方法还包括：

获取所述用户请求对应的方法体，其中，所述方法体中包含有所述服务器响应所述用户请求时需要执行的方法；以及

检测所述方法体上是否带有自定义注解，

其中，若检测到所述方法体上带有所述自定义注解，则获取所述被请求次数阈值和所述当前已被请求的次数。

6.一种对用户请求进行限流的系统，包括：

第一获取模块，用于获取本次对指定统一资源定位符URL进行请求的用户请求，其中，所述指定URL能够被请求的总次数不大于被请求次数阈值；

判断模块，用于判断获取所述用户请求的时间是否在对所述用户请求进行限流的有效时期内；

第二获取模块，用于在所述判断模块判断为是的情况下，获取所述被请求次数阈值和所述指定URL当前已被请求的次数，其中，所述当前已被请求的次数包含本次；以及

处理模块，用于在所述当前已被请求的次数大于所述被请求次数阈值的情况下，禁止服务器响应所述用户请求。

7.根据权利要求6所述的系统，其中，所述第二获取模块包括：

第一获取单元，用于获取所述用户请求对应的方法体，其中，所述方法体中包含有所述服务器响应所述用户请求时需要执行的方法，且其上带有自定义注解，所述自定义注解中至少包括所述被请求次数阈值；

第二获取单元，用于从所述方法体上带有的所述自定义注解中获取所述被请求次数阈值，

和/或，

第三获取单元，用于从指定存储装置中获取所述被请求次数阈值。

8.根据权利要求7所述的系统，其中，所述系统还包括：修改模块，用于对所述指定存储装置中存储的所述被请求次数阈值进行修改。

9.根据权利要求6所述的系统，其中，所述系统还包括：告警模块，用于在所述当前已被请求的次数大于所述被请求次数阈值的情况下，进行告警。

10.根据权利要求6所述的系统，其中，所述系统还包括：

第三获取模块，用于在获取请求次数模块之前，获取所述用户请求对应的方法体，其中，所述方法体中包含有所述服务器响应所述用户请求时需要执行的方法；以及

检测模块，用于检测所述方法体上是否带有自定义注解，

其中，所述第二获取模块还用于在检测到所述方法体上带有所述自定义注解的情况下，获取所述被请求次数阈值和所述当前已被请求的次数。

11.一种非易失性存储介质，其上存储有可执行指令，所述指令被处理器执行时用于实现权利要求1至5中任一项所述的对用户请求进行限流的方法。

12.一种计算机系统，包括：

存储器；以及

耦接至所述存储器的处理器，其中，所述处理器被配置为基于存储在所述存储器中的指令，执行如权利要求1至5中任一项所述的对用户请求进行限流的方法。

Images