CN112953945A - 访问请求处理方法和系统 - Google Patents

Abstract

本公开提供了一种访问请求处理方法和系统，方法包括：接收用户提交的m个访问请求，m为大于等于2的整数；以及基于预定限流策略，依次在n个请求处理层对m个访问请求进行限流处理，以使n个请求处理层中的访问请求的数量逐层递减，其中，n个请求处理层包括终端层、接入层和服务层，n为大于等于2的整数。

Description

访问请求处理方法和系统

技术领域

本公开涉及互联网技术领域，更具体地，涉及一种访问请求处理方法和系统。

背景技术

在访问量很大的场景中，例如一些秒杀业务场景中(例如纪念币预约)，大量互联网用户在短时内密集发起业务请求，瞬时逼近或超出系统的最大性能容量，导致业务系统崩溃而无法提供服务。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题：

现有方案通过增加机器部署应对短时间的高访问需求，但是投入设备机器量大，造成成本增加且造成大量设备浪费。

发明内容

有鉴于此，本公开提供了一种访问请求处理方法和系统。

本公开的一个方面提供了一种访问请求处理方法，包括：接收用户提交的m个访问请求，m为大于等于2的整数；以及基于预定限流策略，依次在n个请求处理层对所述m个访问请求进行限流处理，以使所述n个请求处理层中的访问请求的数量逐层递减，其中，所述n个请求处理层包括终端层、接入层和服务层，n为大于等于2的整数。

根据本公开的实施例，所述依次在n个请求处理层对所述m个访问请求进行限流处理包括：在所述终端层进行第一次限流处理，所述第一次限流处理包括以下处理中的至少一种：针对提交访问请求的频率超过第一频率阈值的用户，执行限制请求处理；接收所述接入层反馈的提交访问请求的频率超过第二频率阈值的用户或者IP地址，并针对所述用户或者所述IP地址执行限制请求处理。

根据本公开的实施例，所述依次在n个请求处理层对所述m个访问请求进行限流处理还包括：在所述接入层进行第二次限流处理，所述第二次限流处理包括以下处理中的至少一种：针对提交访问请求的数量排名前p位并且不属于白名单的用户或者IP地址，执行拒绝请求处理，p为大于等于1的整数；在所述接入层的待处理访问请求数量超过第一数量阈值的情况下，将超出所述第一数量阈值的部分访问请求重定向至静态页面缓存设备。

根据本公开的实施例，所述依次在n个请求处理层对所述m个访问请求进行限流处理还包括：在所述服务层进行第三次限流处理，所述第三次限流处理包括以下处理中的至少一种：在所述服务层的待处理访问请求数量超过第二数量阈值的情况下，将超出所述第二数量阈值的部分防问请求重定向至静态页面缓存设备；针对提交动态访问请求的频率超过第三频率阈值的用户或者IP地址，执行拒绝请求处理；针对不具备用户操作特征的访问请求，执行拒绝请求处理。

根据本公开的实施例，所述方法还包括：针对动态页面的访问请求，从所述静态页面缓存设备获取静态数据，并从所述服务层获取动态数据，以基于所述静态数据和所述动态数据得到动态页面。

根据本公开的实施例，所述方法还包括：按照预定分库策略，在数据层将用户数据拆分存储至多个节点数据库；在所述服务层缓存部分用户数据。

本公开的另一个方面提供了一种访问请求处理系统，包括：n个请求处理层，用于依次对m个访问请求进行限流处理，以使所述n个请求处理层中的访问请求的数量逐层递减，m和n均为大于等于2的整数；其中，所述n个请求处理层包括终端层、接入层和服务层。

根据本公开的实施例，所述终端层用于进行第一次限流处理，所述第一次限流处理包括以下处理中的至少一种：针对提交访问请求的频率超过第一频率阈值的用户，执行限制请求处理；接收所述接入层反馈的提交访问请求的频率超过第二频率阈值的用户或者IP地址，并针对所述用户或者所述IP地址执行限制请求处理。

根据本公开的实施例，所述接入层用于进行第二次限流处理，所述第二次限流处理包括以下处理中的至少一种：针对提交访问请求的数量排名前p位并且不属于白名单的用户或者IP地址，执行拒绝请求处理，p为大于等于1的整数；在所述接入层的待处理访问请求数量超过第一数量阈值的情况下，将超出所述第一数量阈值的部分访问请求重定向至静态页面缓存设备。

根据本公开的实施例，所述服务层用于进行第三次限流处理，所述第三次限流处理包括以下处理中的至少一种：在所述服务层的待处理访问请求数量超过第二数量阈值的情况下，将超出所述第二数量阈值的部分访问请求重定向至静态页面缓存设备；针对提交动态访问请求的频率超过第三频率阈值的用户或者IP地址，执行拒绝请求处理；针对不具备用户操作特征的访问请求，执行拒绝请求处理。

根据本公开的实施例，控制请求量逐层递减，既可以应对本层的访问压力，又同时对下一层做限流保护，较大程度上减轻访问压力，足以应对短时内用户密集发起业务请求的场景，又可以避免投入过多设备造成成本增大和设备浪费的问题。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用访问请求处理方法的示例性系统架构；

图2示意性示出了根据本公开实施例的访问请求处理方法的流程图；

图3示意性示出了根据本公开实施例的请求重定向的示意图；

图4示意性示出了根据本公开另一实施例的请求重定向的示意图；以及

图5示意性示出了根据本公开实施例的数据传输的示意图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

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

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的实施例提供了一种访问请求处理方法，包括：接收用户提交的m个访问请求，m为大于等于2的整数；以及依次在n个请求处理层对m个访问请求进行限流处理，以使n个请求处理层中的访问请求的数量逐层递减，其中，n个请求处理层包括终端层、接入层和服务层，n为大于等于2的整数。

图1示意性示出了根据本公开实施例的可以应用访问请求处理方法的示例性系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构可以包括多个请求处理层，多个请求处理层可以包括终端层101、接入层102和服务层103。

终端层101可以用于页面用户交互、提交客户请求等，终端层101可以是指终端设备或者是指安装于终端设备上的终端程序，以下内容中终端也可称为浏览器端。其中，终端设备上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端和/或社交平台软件等(仅为示例)。终端设备可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

接入层102可以用于接收来自终端层的访问请求并将访问请求分发至服务层的多个服务器，接入层102可以包括负载均衡服务器和/或节点缓存服务器等，或者包括安装于负载均衡服务器和/或节点缓存服务器的处理程序等。

服务层103可以用于响应访问请求，可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给用户。服务层103可以包括应用服务器和/或WEB服务器等，或者包括安装于应用服务器和/或WEB服务器的处理程序等。

此外，系统架构还可以包括数据层，数据层可以包括数据库，用于存储数据。服务层103可以从数据层获取数据。

终端层101、接入层102和服务层103之间通过网络连接，网络用以在请求处理层之间提供通信链路的介质。网络可以包括各种连接类型，例如有线和/或无线通信链路等等。

图2示意性示出了根据本公开实施例的访问请求处理方法的流程图。

如图2所示，该方法包括操作S210～S220。

在操作S210，接收用户提交的m个访问请求，m为大于等于2的整数。

在操作S220，依次在n个请求处理层对m个访问请求进行限流处理，以使n个请求处理层中的访问请求的数量逐层递减，其中，n个请求处理层包括终端层、接入层和服务层，n为大于等于2的整数。

本公开实施例的访问请求处理方法例如可以应用于秒杀场景、抢号场景等短时内用户密集发起业务请求的场景中。

结合图1和图2所示，终端层101可以接收第一数量的访问请求，例如可以在终端层对第一数量的访问请求进行第一次限流处理，过滤掉部分访问请求，剩余第二数量的访问请求。然后在接入层对第二数量的访问请求进行第二次限流处理，再次过滤掉部分访问请求，剩余第三数量的访问请求。第三数量的访问请求进入服务层之后，在服务层对第三数量的访问请求进行第三次限流处理，剩余第四数量的访问请求，服务层响应该第四数量的访问请求，反馈请求数据。因此，请求量逐层递减，既可以应对本层的访问压力，又同时对下一层做限流保护，较大程度上减轻访问压力，足以应对短时内用户密集发起业务请求的场景，又可以避免投入过多设备造成成本增大和设备浪费的问题。

根据本公开的实施例，依次在n个请求处理层对m个访问请求进行限流处理包括：在终端层进行第一次限流处理，第一次限流处理包括以下处理(1)～(2)中的至少一种：

(1)针对提交访问请求的频率超过第一频率阈值的用户，执行限制请求处理。

(2)接收接入层反馈的提交访问请求的频率超过第二频率阈值的用户或者IP地址，并针对用户或者IP地址执行限制请求处理。

例如，终端层可以控制请求提交频度，限制单位时间内请求的次数。例如可控制每分钟每用户只能发起N个请求，超过阈值N则利用终端代码拒绝用户发出请求，其中N为大于等于1的整数。

再例如，可以将用户提交的请求均发送至接入层，由接入层统计每个用户或者每个IP发起请求的频率，若用户或者IP发起请求泰国频繁，则可以通过cookie技术反馈到浏览器端，再由浏览器端通过前端代码控制拒绝用户发出请求。

在本公开的实施例中，还可以利用浏览器端缓存部分页面数据，以减少数据传输，提高请求响应速度。可对HTTP请求头中的缓存控制字段(Cache-control、Last-Modifified、Expires、E-tag等)做精细化管理，在不影响交易功能的前提下充分利用浏览器本地缓存。

根据本公开的实施例，依次在n个请求处理层对m个访问请求进行限流处理还包括：在接入层进行第二次限流处理，第二次限流处理包括以下处理(3)～(4)中的至少一种：

(3)针对提交访问请求的数量排名前p位并且不属于白名单的用户或者IP地址，执行拒绝请求处理，p为大于等于1的整数。

(4)在接入层的待处理访问请求数量超过第一数量阈值的情况下，将超出第一数量阈值的部分访问请求重定向至静态页面缓存设备。

例如，接入层可利用互联网专线入口网络设备侧配置拦截操作，识别频繁攻击行为。接入层可对系统访问流量排名靠前(例如前10位)的IP地址，进行IP地址封禁，接入层拒绝被封禁IP地址提交的请求。或者，可对系统访问次数排名靠前(例如前10位)的用户，进行用户封禁，接入层拒绝被封禁用户提交的请求。同时可以采用白名单机制，不对白名单中的IP地址或者用户封禁，白名单支持手工配置，避免误拦操作。

在本公开的实施例中，接入层可以包括CDN(Content Delivery Network)节点的缓存服务器(也可称为静态页面缓存设备)，CDN节点缓存服务器可以是指在各地区部署的静态存储服务器，可缓存源站的HTML、图片、JS、CSS等静态资源。用户访问请求提交至接入层时，若用户请求的是静态数据，则可以将用户请求指向离用户所在位置最近CDN节点，节点缓存服务器可以直接响应用户请求，将静态页面返回终端设备，实现就近接入。

图3示意性示出了根据本公开实施例的请求重定向的示意图。

如图3所示，用户通过终端层310的终端设备311发起访问请求，终端设备311将访问请求340提交至接入层的服务器321，服务器321可以将访问请求发送至服务层330或者在预定情况下拒绝该访问请求。当用户请求被拒绝后，服务器321可以将用户请求重定向至就近的CDN节点缓存服务器322，利用缓存服务器322向用户反馈静态页面数据350，以在请求无法被动态响应时也尽可能为用户带来良好的用户体验。

在本公开的实施例中，接入层还可以包括负载均衡服务器，负载均衡服务器可以将用户请求均匀分发至服务层的各服务器，可通过使用负载均衡器产品如F5或采用应用方式实现负载均衡。负载均衡服务器可利用F5或软负载实现限流，可通过配置规则实现用户请求的限流，例如，在当前待处理的访问请求总量超过接入层设备可处理的最大请求量时，可以将超出部分的用户请求重定向到CDN节点以提供静态友好提示页面。

在本公开的实施例中，接入层可采用双层软负载架构，首层由LVS(Linux VirtualServer)实现四层(协议层)负载均衡，转发HTTP、HTTPS请求；二层由HAProxy集群实现七层(应用层)负载均衡，承担SSL(Secure Socket Layer)证书卸载，实现应用层的复杂调度策略。

在本公开的实施例中，终端与服务器通过接入层建立会话，会话连接超过默认时长并且在该段时间内用户没有发出任何请求，则可以断开连接。可在接入层配置连接超时时间优化规则，在秒杀等场景中，可调低F5上的连接超时时间默认值(默认1005秒，如调低为60秒)，加速F5的空闲连接释放，从而减少设备资源占用。

根据本公开的实施例，依次在n个请求处理层对m个访问请求进行限流处理还包括：在服务层进行第三次限流处理，第三次限流处理包括以下处理(5)～(7)中的至少一种：

(5)在服务层的待处理访问请求数量超过第二数量阈值的情况下，将超出第二数量阈值的部分访问请求重定向至静态页面缓存设备。

(6)针对提交动态访问请求的频率超过第三频率阈值的用户或者IP地址，执行拒绝请求处理。

(7)针对不具备用户操作特征的访问请求，执行拒绝请求处理。

例如，服务器限流可选择单节点级限流，针对单台应用服务器在HTTP请求维度增加并发计数器，监控HTTP请求的并发量是否超过阈值，该阈值例如可以是单台应用服务器可处理的最大并发量。超过阈值后应用服务器可拒绝超出阈值的部分请求，并将请求重定向到CDN的静态交易提示页面。

再例如，可检测该用户单位时间内提交的动态请求的总数，判断动态请求的总数是否超过一定阈值，以判断用户的请求操作是否过于频繁。若是，则将用户请求重定向到CDN的静态页面。其中，动态请求是指对动态页面的请求。

再例如，可检测用户请求是否具备浏览器特征，如UA(UserAgent)信息、JS(JavaScript)和CSS(Cascading Style Sheets)执行情况(能否执行、窗口大小、键盘鼠标动作、页面生存时间等)。无浏览器特征的访问请求认为不是通过浏览器提交的请求，是恶意的请求，因此针对无浏览器特征的访问请求，可自动拒绝或重定向至提示页面，并记录相关日志作后续分析处理(恶意IP可手工导入DDOS防护设备侧作为黑名单)。

图4示意性示出了根据本公开另一实施例的请求重定向的示意图。

如图4所示，用户通过终端层410的终端设备411发起访问请求，终端设备411将访问请求440提交至接入层的服务器421，服务器421可以将访问请求发送至服务层430的应用服务器431，应用服务器431可以响应访问请求生成页面或者可以在预定情况下拒绝该访问请求。当用户请求被拒绝后，应用服务器431可以将用户请求重定向至接入层中的CDN节点缓存服务器422，利用缓存服务器422向用户反馈静态页面数据450。

根据本公开的实施例，访问请求处理方法还可以包括：针对动态页面的访问请求，从静态页面缓存设备获取静态数据，并从服务层获取动态数据，以基于静态数据和动态数据得到动态页面。

图5示意性示出了根据本公开实施例的数据传输的示意图。

如图5所示，接入层520的CDN节点缓存服务器521可以缓存动态页面的部分静态数据，服务层530的服务器531可以提供动态页面的用户动态数据，服务器531例如可以从数据层的数据库获取用户动态数据或者可以在服务器中缓存部分用户动态数据。当用户通过终端层510的终端设备511提交访问请求时，可以由CDN节点缓存服务器521向终端设备511提供与请求对应的静态数据540，并由服务层的服务器531向终端设备511提供与请求对应的动态数据550，终端设备511接收到页面的静态数据540和动态数据550之后，可以将数据组成生成相应的动态页面并展示给用户。基于这一方案，可以减少服务层的数据传输量，提高传输速度，提高由请求到页面展示的速度。

根据本公开的实施例，为应对秒杀等场景，可以将用户页面简化设计。页面设计可以尽量精减，减少页面引用和外围系统的交互，同时可以引导用户减少刷新操作。

根据本公开的实施例，为防止恶意攻击，可以为页面设置验证码。服务层可以设置多套验证码，以防止简单验证码被黑客通过OCR等技术手段攻破。可支持多套验证码选择使用，同时可在后台提供验证码切换维护功能，实现无需重启服务即可生效。还可以合理控制验证码的有效性，例如验证码超过有效期后作废和/或用过后作废，以防止黑客提前获取验证码之后发起集中请求。

根据本公开的实施例，还可以设置系统入口保护策略，例如，在秒杀前仅向用户提供静态页面，静态页面中没有代码入口，在秒杀前的若干秒再将静态页面替换为真正的秒杀页面，避免页面代码过早暴露，防止被黑客恶意利用。

在本公开的实施例中，还可以对服务层的Web中间件进行优化，例如采用轻量级、性能好的Web中间件(如nginx)代替采用传统的Web中间件(如IHS)来发布静态页面，从而可以提供更高的处理性能和扩展能力。

在本公开的实施例中，对于整体业务复杂度较低的业务系统，服务层可以优先考虑采用集中式架构。避免微服务拆分之后引发的服务调度开销、分布式事务、长链路等问题，降低整体的运维成本。对于整体业务复杂度较高的业务系统，服务层可引入微服务架构。秒杀业务等场景下的微服务设计可以减少核心业务环节对其他微服务的同步调用依赖，可基于异步事件来保证数据的最终一致性。

根据本公开的实施例，访问请求处理方法还可以包括：在服务层缓存部分用户数据。

在本公开实施例中，可以将一些用户数据缓存在应用服务层，无需再去数据库获取，以减少数据传输，提高响应效率。例如，对于只读频繁访问、对内存空间占用有限的数据，可建立应用服务器本地缓存层，利用服务器内存提高访问效率。可支持多种缓存刷新策略，如应用服务器定时启动线程从数据库刷新数据，或手工应急刷新操作。

在本公开实施例中，可以在应用服务器配置多级缓存，对于热销的产品而言，分布式缓存有可能会出现热点瓶颈，可利用本地缓存和分布式缓存结合的多级方案应对这种场景，即服务层优先访问本地缓存，当本地缓存不存在时再从分布式缓存获取。本地缓存均匀地分布在各个应用节点中，降低了分布式缓存的热点压力。

根据本公开的实施例，还可以在服务层配置熔断与降级策略。当系统整体性能压力过大或者部分服务发生异常时，可对次要服务进行有策略的放弃，保证主要业务的正常运行。可以采用自动和手动策略相配合，提供人工干预机制。

例如，可以在服务层配置异常熔断策略，当请求响应的错误率超过一定阈值时可自动拒绝或重定向错误提示页面，避免异常过多后的失败重试拖垮系统整体性能。此外，还可以在服务器的连接之间进行异常熔断，例如服务器A连接服务器B并从服务器B获取数据，若B发生异常，则可以断开两者之间的连接，一段时间之后再尝试连接服务器B。

再例如，还可以在服务层配置服务功能降级策略，将部分非核心功能下架。例如，可支持部分业务服务的短期内关停或者限流，以优先保证核心服务所需要的性能资源。如在秒杀开始后的短期内对用户注册、用户修改密码等服务进行限制，减少非核心业务的性能开销。

再例如，还可以在服务层配置分布式缓存降级策略，对于使用分布式缓存的场景，当分布式缓存发生异常时，可支持熔断处理，系统自动切换访问本地缓存和数据库。

再例如，还可以在服务层配置数据库降级处理策略，例如，当某一数据库运行异常时，可以将数据库的数据存储在应用服务器中，数据库恢复后再将数据转回数据库。针对数据库处理缓慢导致应用无法获取数据库连接的极端情况，可考虑增加无数据库临时交易。通过综合运用缓存、本地文件等设计暂时取代数据库的持久化能力，保证系统处理能力在短时间内仍然能保持在较高水平。

根据本公开的实施例，访问请求处理方法还可以包括：按照预定分库策略，在数据层将用户数据拆分存储至多个节点数据库。

例如，应对秒杀等场景，可以引入更多数据库，将用户数据进行拆分，并分布到更多的数据库中，以使分摊到每个数据库的压力减小。例如，可以按照用户身份证尾号进行拆分，将尾号为0的放在一个数据库，尾号为1的放在另一个数据库等。

对于数据库承担高一致性数据写入操作的场景，可通过拆库、拆表、拆字段解决写操作热点问题。数据库按分片原则拆分多个节点库，将写操作分散到更多数据库服务器。对一致性要求最高的库存更新操作，在节点库完成。

在本公开的实施例中，对于秒杀业务场景，还可以对数据库的设置进行优化，例如，可删除非必须的索引，缩短单次事务的执行时间、用乐观锁代替悲观锁以使开锁时间更短。这样，可以简化数据库的流程和减小需要的时间。

在本公开的实施例中，可利用数据库事务保证数据的强一致性，如包含库存更新和订单生成的事务执行成功时则认为秒杀操作成功。用于判断秒杀是否成功。

在本公开的实施例中，还可结合SOGA(又称为Long-running-transaction，长事务)、TCC(Try Confirm Cancel)机制适当引入分布式事务来保障数据的一致性，即在服务层提供业务的执行、确认和回滚接口，同时需配合操作流水记录来保证数据的更新和回滚都有据可查。

在本公开的实施例中，对于数据量较大、读比写频繁的场景，可利用分布式缓存减轻数据库访问压力，如用户信息、会话信息等。

在本公开的实施例中，对于秒杀业务场景，可将分布式缓存库存更新作为数据库库存更新的前置环节。由于分布式缓存的单行记录更新速度远远高于数据库，如果基于分布式缓存设计库存更新机制，可以有效降低数据库的竞争压力，提升下单环节的响应速度。

本公开实施例提供的访问请求处理方法，可以针对秒杀业务等短时内密集发起业务请求的场景，在有限的资源的条件下，通过应用系统的可用性设计及部署，能够满足和支撑短时间内目标并发需求，减少非计划的停止服务时间。

本公开实施例的另一方面提供了一种访问请求处理系统，包括：

n个请求处理层，用于依次对m个访问请求进行限流处理，以使n个请求处理层中的访问请求的数量逐层递减，m和n均为大于等于2的整数。其中，n个请求处理层包括终端层、接入层和服务层。

根据本公开的实施例，终端层用于进行第一次限流处理，第一次限流处理包括以下处理中的至少一种：针对提交访问请求的频率超过第一频率阈值的用户，执行限制请求处理；接收接入层反馈的提交访问请求的频率超过第二频率阈值的用户或者IP地址，并针对用户或者IP地址执行限制请求处理。

根据本公开的实施例，接入层用于进行第二次限流处理，第二次限流处理包括以下处理中的至少一种：针对提交访问请求的数量排名前p位并且不属于白名单的用户或者IP地址，执行拒绝请求处理，p为大于等于1的整数。在接入层的待处理访问请求数量超过第一数量阈值的情况下，将超出第一数量阈值的部分访问请求重定向至静态页面缓存设备。

根据本公开的实施例，服务层用于进行第三次限流处理，第三次限流处理包括以下处理中的至少一种：在服务层的待处理访问请求数量超过第二数量阈值的情况下，将超出第二数量阈值的部分访问请求重定向至静态页面缓存设备。针对提交动态访问请求的频率超过第三频率阈值的用户或者IP地址，执行拒绝请求处理。针对不具备用户操作特征的访问请求，执行拒绝请求处理。

根据本公开的实施例，针对动态页面的访问请求，可以从静态页面缓存设备获取静态数据，并从服务层获取动态数据，以基于静态数据和所述动态数据得到动态页面。

根据本公开的实施例，可以按照预定分库策略，在数据层将用户数据拆分存储至多个节点数据库。还可以在服务层缓存部分用户数据。

需要说明的是，本公开的实施例中防问请求处理系统部分与本公开的实施例中访问请求处理方法部分是相对应的，访问请求处理系统部分的描述具体参考访问请求处理方法部分，在此不再赘述。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

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

Claims (10)

1.一种访问请求处理方法，包括：

接收用户提交的m个访问请求，m为大于等于2的整数；以及

依次在n个请求处理层对所述m个访问请求进行限流处理，以使所述n个请求处理层中的访问请求的数量逐层递减，其中，所述n个请求处理层包括终端层、接入层和服务层，n为大于等于2的整数。

2.根据权利要求1所述的方法，其中，所述依次在n个请求处理层对所述m个访问请求进行限流处理包括：在所述终端层进行第一次限流处理，所述第一次限流处理包括以下处理中的至少一种：

针对提交访问请求的频率超过第一频率阈值的用户，执行限制请求处理；

接收所述接入层反馈的提交访问请求的频率超过第二频率阈值的用户或者IP地址，并针对所述用户或者所述IP地址执行限制请求处理。

3.根据权利要求2所述的方法，其中，所述依次在n个请求处理层对所述m个访问请求进行限流处理还包括：在所述接入层进行第二次限流处理，所述第二次限流处理包括以下处理中的至少一种：

针对提交访问请求的数量排名前p位并且不属于白名单的用户或者IP地址，执行拒绝请求处理，p为大于等于1的整数；

在所述接入层的待处理访问请求数量超过第一数量阈值的情况下，将超出所述第一数量阈值的部分访问请求重定向至静态页面缓存设备。

4.根据权利要求3所述的方法，其中，所述依次在n个请求处理层对所述m个访问请求进行限流处理还包括：在所述服务层进行第三次限流处理，所述第三次限流处理包括以下处理中的至少一种：

在所述服务层的待处理访问请求数量超过第二数量阈值的情况下，将超出所述第二数量阈值的部分访问请求重定向至静态页面缓存设备；

针对提交动态访问请求的频率超过第三频率阈值的用户或者IP地址，执行拒绝请求处理；

针对不具备用户操作特征的访问请求，执行拒绝请求处理。

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

针对动态页面的访问请求，从所述静态页面缓存设备获取静态数据，并从所述服务层获取动态数据，以基于所述静态数据和所述动态数据得到动态页面。

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

按照预定分库策略，在数据层将用户数据拆分存储至多个节点数据库；

在所述服务层缓存部分用户数据。

7.一种访问请求处理系统，包括：

n个请求处理层，用于依次对m个访问请求进行限流处理，以使所述n个请求处理层中的访问请求的数量逐层递减，m和n均为大于等于2的整数；

其中，所述n个请求处理层包括终端层、接入层和服务层。

8.根据权利要求7所述的系统，其中，所述终端层用于进行第一次限流处理，所述第一次限流处理包括以下处理中的至少一种：

针对提交访问请求的频率超过第一频率阈值的用户，执行限制请求处理；

接收所述接入层反馈的提交访问请求的频率超过第二频率阈值的用户或者IP地址，并针对所述用户或者所述IP地址执行限制请求处理。

9.根据权利要求8所述的系统，其中，所述接入层用于进行第二次限流处理，所述第二次限流处理包括以下处理中的至少一种：

针对提交访问请求的数量排名前p位并且不属于白名单的用户或者IP地址，执行拒绝请求处理，p为大于等于1的整数；

在所述接入层的待处理访问请求数量超过第一数量阈值的情况下，将超出所述第一数量阈值的部分访问请求重定向至静态页面缓存设备。

10.根据权利要求9所述的系统，其中，所述服务层用于进行第三次限流处理，所述第三次限流处理包括以下处理中的至少一种：

在所述服务层的待处理访问请求数量超过第二数量阈值的情况下，将超出所述第二数量阈值的部分访问请求重定向至静态页面缓存设备；

针对提交动态访问请求的频率超过第三频率阈值的用户或者IP地址，执行拒绝请求处理；

针对不具备用户操作特征的访问请求，执行拒绝请求处理。

Images