CN108112038B - 一种控制访问流量的方法及装置 - Google Patents

Abstract

本发明实施例公开了一种控制访问流量的方法及装置，涉及互联网技术领域，能够缓解由于恶意刷单造成的一些业务场景下的销售量受到影响的问题。本发明包括：根据所配置的业务数据，确定分配至各个业务场景的流控策略；根据各个业务场景的流控策略，分别分配各个业务场景的线程数；对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略；对请求数量符合这一个业务场景的流控策略的用户进行限制。本发明适用于控制访问量。

Description

一种控制访问流量的方法及装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种控制访问流量的方法及装置。

背景技术

随着互联网技术的发展，在在线金融、贸易方面，已经存在很多电子商务平台、在线金融系统等平台、系统，以满足用户需求。而各种营销活动、促销活动也层出不穷，这都极大地增加了这些平台、系统的访问量。

由于访问量的不断攀升，各应用系统在接收用户发送的服务请求时，与用户设备对接的服务器承受的流量压力越来越大，若遇到“双十一”、“双十二”等流量峰值时期，海量的用户会同时进行下单、结算的操作，这就导致下单系统和结算系统等应用系统会承受很大的操作流量。

当承担下单和结算等功能的系统所承载的负载过大时，为了保障系统的正常运行并保障大部分用户的正常操作，通常会向发出超出负载部分的用户，反馈表示操作失败或者强制等待的消息，实际上中断了这一部分的用户操作。其中又由于黄牛刷单、自动脚本等恶意的刷单行为，会以很高的频率重复进行下单、结算的操作或者进行页面刷新的操作，这又会进一步增加操作流量，导致系统负载进一步增大以及更多的正常用户收到表示操作失败或者强制等待的消息，从而严重影响销售量，给运营商造成不小的经济损失。同时又由于运营商对于目前的各种恶意的刷单行为没有较为有效的限制方式，主要都是购置更多的服务器设备增加下单和结算等功能的系统负载能力，来应付流量峰值时期的操作流量，从而增加了运营成本。

发明内容

本发明的实施例提供一种控制访问流量的方法及装置，缓解了由于恶意刷单造成的一些业务场景下的销售量受到影响的问题。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明的实施例提供的方法，包括：

根据所配置的业务数据，确定分配至各个业务场景的流控策略；

根据各个业务场景的流控策略，分别分配各个业务场景的线程数；

对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略；

对请求数量符合这一个业务场景的流控策略的用户进行限制。

结合第一方面，在第一方面的第一种可能的实现方式中，所述根据所配置的业务数据，确定分配至各个业务场景的流控策略，包括：

从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景，所述业务数据至少包括：所述业务系统中运行的虚拟机(JVM)的集合，和所述业务系统所展示页面的页面结构；所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符(URL)；

读取预设的各个业务场景的流控策略。

结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，根据各个业务场景的流控策略，分别分配各个业务场景的线程数，包括：

根据各个业务场景的流控策略，确定各个业务场景在当前时间段内的优先级，并依据优先级确定各个业务场景的线程数；

按照所确定的各个业务场景的线程数，为各个业务场景的虚拟机分配线程。

结合第一方面的第一种可能的实现方式，在第三种可能的实现方式中，所述计数用户发送的用于访问一个业务场景的请求数量，包括

检测在当前的时间段内，访问业务场景的URL或者接口的次数；

若所述次数大于触发阀值，则对所述用户标识限制访问次数。

结合第一方面，在第一方面的第四种可能的实现方式中，还包括：

检测计数器的计数值是否大于预设值；

若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设值，得到所述计数器的真实值。

结合第一方面，在第一方面的第五种可能的实现方式中，所述检测计数结果是否符合这一个业务场景的流控策略，包括：

检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的设定值；

若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，并将超出了访问这一个业务场景的最大人数的用户的识别标识，添加至排队队列。

结合第一方面或第一方面的第五种可能的实现方式,在第六种可能的实现方式中，所述对请求数量符合这一个业务场景的流控策略的用户进行限制，包括：

检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则将用户的识别标识添加至排队队列。

结合第一方面的第六种可能的实现方式，在第七种可能的实现方式中，所述用户发送的请求数量包括：

单个用户访问这一个业务场景的URL或者接口的次数；

或者，所有用户访问这一个业务场景的URL或者接口的次数之和。

第二方面，本发明的实施例提供的装置，包括：

业务场景管理模块，用于根据所配置的业务数据，确定分配至各个业务场景的流控策略；

性能管理模块，用于根据由所述业务场景管理模块确定的各个业务场景的流控策略，分别分配各个业务场景的线程数；

用户管理模块，用于对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略；并对请求数量符合这一个业务场景的流控策略的用户进行限制。

结合第二方面，在第二方面的第一种可能的实现方式中，所述业务场景管理模块，具体用于从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景；并读取预设的各个业务场景的流控策略；

所述业务数据至少包括：所述业务系统中运行的虚拟机(JVM)的集合，和所述业务系统所展示页面的页面结构；所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符(URL)；

所述性能管理模块，具体用于根据各个业务场景的流控策略，确定各个业务场景在当前时间段内的优先级，并依据优先级确定各个业务场景的线程数；并按照所确定的各个业务场景的线程数，为各个业务场景的虚拟机分配线程；

所述用户管理模块，具体用于检测在当前的时间段内，访问业务场景的URL或者接口的次数；若所述次数大于触发阀值，则对所述用户标识限制访问次数；

所述用户管理模块，具体还用于检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的设定值；若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，并将超出了访问这一个业务场景的最大人数的用户的识别标识，添加至排队队列；

和，检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则将用户的识别标识添加至排队队列；

其中，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数；或者，所有用户访问这一个业务场景的URL或者接口的次数之和。

结合第二方面的第二种可能的实现方式，在第二种可能的实现方式中，还包括：

计数器管理模块，用于检测计数器的计数值是否大于预设值；若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设值，得到所述计数器的真实值。

本发明实施例提供的控制访问流量的方法及装置，针对具体的业务场景的恶意的刷单行为，对不同的业务场景采取各自的流控策略，从而对该业务场景下的用户操作行为进行了限制，缓解了由于恶意刷单造成的一些业务场景下的销售量受到影响的问题，从而减小运营商的经济损失。

附图说明

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

图1为本发明实施例提供的一种系统架构示意图；

图2为本发明实施例提供的控制访问流量的方法的流程示意图；

图3、图4为本发明实施例提供的控制访问流量的装置的结构示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本发明实施例具体可以实现在一种如图1所示的系统中，其中包括：分析服务器、至少一种业务系统、由用户操作的用户设备；

分析服务器，具体可以是单独作成的服务器设备，比如：机架式、刀片、塔式或者机柜式的服务器设备，也可以采用工作站、大型计算机等具备较强计算能力硬件设备；也可以是由多个服务器设备组成的服务器集群；分析服务器连接至少一种业务系统。分析服务器用于执行本实施例所提供的方法流程，比如：分析服务器根据各个业务系统的所配置的业务数据，各个业务系统当前运行的业务场景。比如：业务系统为智能货架系统，具体用于显示一种展示了多种商品的货架页面，分析服务器可以从智能货架系统提取货架页面的页面结构，并获取页面结构中的商品信息、商品的URL(Uniform Resource Locator，统一资源定位符)信息、页面地址信息等用于表示业务场景的信息。

本实施例中所述的业务场景，具体可以理解为一种由业务数据和一系列的业务执行流程组成的数据集合，比如：商品信息(在一些具体领域中，商品信息也可称为单品)、URL(Uniform Resource Locator，统一资源定位符)信息、页面地址信息等，通常的这些业务数据有业务系统存储并维护，业务执行流程由业务系统上运行的执行模块(比如业务系统上建立的虚拟机)执行；在业务系统上同时也可以生成对应业务执行流程中各个环节的页面，并在展示页面中添加相应的业务数据；根据用户设备的访问请求和用户操作，用户设备可以向业务系统请求访问相应的业务执行流程中的某一个环节的页面，并将所访问的页面展示在用户设备的显示单元上(比如显示在智能手机的触摸屏)；在业务执行流程的执行过程中，由于用户操作或者自动触发等原因，使的用户设备所显示的当前所在业务环节的页面跳转至下一个业务环节的页面。

URL信息中具体还可以包括用于表示业务场景的业务属性的信息，比如：商品编码、品牌编码、品类编码等。

业务系统具体可以是用于在线交易业务、金融业务或者物流业务等业务系统，比如可以包括但不限于：在线购物平台、智能货架系统或是其它用于承担下单和结算等功能的系统等。

用户设备具体可以实做成单独一台装置，或整合于各种不同的媒体数据播放装置中，诸如智能手机、平板电脑(Tablet Personal Computer)、膝上型电脑(LaptopComputer)、个人数字助理(personal digital assistant，简称PDA)或可穿戴式设备(Wearable Device)等。用户设备上可以通过安装的应用程序或者APP，显示业务系统所展示的交互界面，比如：用于承担下单和结算等功能的系统所展示的结算页面、智能货架系统所展示的货架页面等，通常的业务系统所展示的交互界面中包括了商品信息、商品的URL信息、页面地址信息等用于表示业务场景的信息，还包括了用于用户进行操作的点击控件或者操作模块。

本发明实施例提供一种控制访问流量的方法，如图2所示，包括：

S1、根据所配置的业务数据，确定分配至各个业务场景的流控策略。

其中，业务数据具体可以是业务系统中所配置的用于表示具体业务场景的信息，比如：商品信息、商品的URL信息、页面地址信息等。业务场景具体可以理解为一种或者多种业务数据以及页面内容的集合，这些业务数据与用户的操作行为相关联且会由于用户的操作产生流量负载，比如：并获取页面结构中的商品信息、商品的URL信息、页面地址信息等用于表示业务场景的信息。

例如：在促销系统中，业务场景包括了一个商品的促销活动(促销活动具体可以呈现为目前各类购物网站上的包括了广告信息、商品简介等信息的活动界面)，则可以从促销系统中提取所配置的该商品的URL信息或者促销系统所展示的促销页面的页面地址，作为所述业务数据。而各个用户操作各自的用户设备通过URL信息访问促销页面，或者通过输入页面地址将浏览器跳转至促销页面的行为，都可以记录为这些用户在业务场景下的操作行为。

例如：在下单系统中，业务场景包括了等待支付操作的商品列表，则商品信息、商品数量、店铺信息等可以作为所述业务数据。而各个用户操作各自的用户设备进行验证、支付的操作，都可以记录为这些用户在业务场景下的操作行为。

本实施例中的流控策略，具体可以包括：对于业务场景下的，由于用户的操作而产生的流量负载的控制规则。例如：流控策略可以包括：基于所分配的线程数的(比如按照具体的负载情况增减承担具体业务功能的虚拟机的线程数)、基于用户标识的(比如限制一些用户标识的访问次数)、基于URL(比如限制通过URL跳转而来的访问次数)的或者其他粒度的控制规则。

S2、根据各个业务场景的流控策略，分别分配各个业务场景的线程数。

具体的，所述根据所配置的业务数据，确定分配至各个业务场景的流控策略的方式可以包括：从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景。并读取预设的各个业务场景的流控策略。其中，所述业务数据至少包括：所述业务系统中运行的虚拟机(JVM)的集合，和所述业务系统所展示页面的页面结构。所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符(URL)。具体的，不同的业务场景可以由至少一个虚拟机承担业务场景中所涉及的业务功能，比如对用户的操作进行处理。

则根据各个业务场景的流控策略，分别分配各个业务场景的线程数的方式可以包括：

根据各个业务场景的流控策略，确定各个业务场景在当前时间段内的优先级，并依据优先级确定各个业务场景的线程数。并按照所确定的各个业务场景的线程数，为各个业务场景的虚拟机分配线程。例如：针对不同业务场景进行单个JVM(Java虚拟机)线程数分配，可降级业务可以把线程数分配为0。

从而通过控制分配至业务的线程，控制系统对于业务的处理能力(限制负载)，使得在用户接入业务时能够正常顺利的接入，不再通过反馈表示操作失败或者强制等待的消息来限制用户的接入。而将对于用户的卡口限制在业务的负载能力上，且可以根据当前业务的重要程度，调整分配至各个业务的负载资源(线程)，避免了由于用户在业务入口被卡主而导致的用户流失。

S3、对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略。

S4、对请求数量符合这一个业务场景的流控策略的用户进行限制。

本发明实施例提供的控制访问流量的方法，针对具体的业务场景的恶意的刷单行为，对不同的业务场景采取各自的流控策略，从而对该业务场景下的用户操作行为进行了限制，缓解了由于恶意刷单造成的一些业务场景下的销售量受到影响的问题，从而减小运营商的经济损失。并且，相对于直接为各个业务系统增加服务器设备的系统优化方式，本实施例通过较为精确的控制线程资源对各个业务场景的性能进行优化，应付流量峰值时期的操作流量的优化手段的粒度更细，对于计算资源的调配也更灵活，改善了单纯的通过增设服务器设备来扩充负载能力的方式，缓解了由于大量增设服务器设备造成的运营成本增加的问题。比如：在一个业务系统中存在多个业务场景，由于黄牛刷单造成了其中一个业务场景的负载过高，需要增加计算资源，而现有方案中主要是以服务器设备为单位为整个业务系统调配计算资源，一旦黄牛刷单的行为停止或者缓解，则会造成为改业务系统新增的服务器设备的计算资源被闲置或者空转，造成计算资源的浪费，还是会增加运营成本。

在本实施例中，所述计数用户发送的用于访问一个业务场景的请求数量的具体方式，可以包括：

检测在当前的时间段内内，对应用户标识的访问业务场景的URL或者接口的次数；若所述次数大于触发阀值，则对所述用户标识限制访问次数。若所述次数小于等于触发阀值，则不做额外处理。

例如：分析服务器可以从业务系统获取用户的访问请求，或者直接接收用户设备发送的访问请求。其中，所述用户访问请求中含有用户标识，用户标识包括但不限于用户的账号信息、用户设备的IP地址等。

其中，本实施例中所述的当前的时间段，在实际应用中可以是：当前的时间周期，即分析服务器在每一个所设定的时间周期内，检测访问业务场景的URL或者接口的次数，比如：所设定的时间周期为3分钟，则每隔3分钟分析服务器检测一次所述用户标识对应的用户设备访问业务场景的URL或者接口的次数。

本实施例中所述的当前的时间段，在实际应用中也可以是：从起始时刻开始至当前时刻之间的时间段，且对应每一个时间段都设定触发阀值，比如：0-2分钟的触发阀值为10次访问、0-4分钟的触发阀值为22次访问、0-6分钟的触发阀值为34次访问。起始时刻为11:00：若当前时刻为11:01，则分析服务器检测所述用户标识对应的用户设备访问业务场景的URL或者接口的次数是否大于10次；若当前时刻为11:03，则分析服务器检测所述用户标识对应的用户设备访问业务场景的URL或者接口的次数是否大于22次；若当前时刻为11:05，则分析服务器检测所述用户标识对应的用户设备访问业务场景的URL或者接口的次数是否大于34次。采用该方式，可以限制在某一时间段进行了过多业务操作行为的用户，并暂时中断该用户的业务流程，等过了一定的时间后，从起始时刻开始至最新时刻之间的时间段的触发阀值大于用户的操作次数后，再继续该用户的业务流程，比如：0-4分钟的触发阀值为22次访问、0-6分钟的触发阀值为34次访问。在11:03，分析服务器检测所述用户标识对应的用户设备访问业务场景的URL或者接口的次数为34次，只有当时间为11:07以后，11:07以后的触发阀值大于34次，则才重新开放该用户的操作。

在本实施例中，用户标识具体可以是用户设备的IP地址、用户账号或者UA(消息头)；用户标识也可以采用Token令牌(一种基于Token机制生成的标识)，比如：在用户进入排队队列时，采用的Token令牌也可以称为TokenID，排队结束后用户设备再次发送的访问请求中需要有TokenID的才能访问业务场景。

进一步的，可限制单个用户访问某个URL或者接口的次数，如果用户触发阀值被禁用设置的时间。也可以限制多个用户访问某个URL或者接口的次数，比如：本实施例在实际应用中，UA可以由多个IP地址共用，并且其中的至少一个IP地址存在于黑名单或者风险名单中，且这些存在于黑名单或者风险名单中的IP地址使用该UA的次数，在该UA被使用的总次数中的占比大于预设占比，则可以限制使用该UA的所有用户；再比如：说一个UA使用多个IP段(如192.168.1、192.168.2等格式的IP段)，而根据风控中心的评估结果或者黑名单/风险名可知，其中的一个IP段风险较大，则限制使用该UA的所有用户。

在本实施例中，还提供一种快速确认计数器是否存在生命周期的方式，具体包括：

检测计数器的计数值是否大于预设值。

若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设值，得到所述计数器的真实值。若否则判定所述计数器不具有生命周期，因此不错处理。

例如：本实施例中提供一种改进的Redies分布式计数器，可以将计数器的初始值调整为一个很大的值作为设定值，如在实际业务应用中一般不可能达到的值，比如1亿，再将计数器的计数值转换为：设定值+真实值，从而当检测到一个计数器返回的值为一个很大的值时，就说明该计数器是有生命周期的，避免了现有方案中，还需要额外发送一个确认消息来确认计数器是否有生命周期的步骤，本实施例中不需通过额外的消息交互即可确认计数器是否有生命周期，尤其是在大规模的分布式系统中，确认步骤的节省能够一定程度上提高运行效率。

进一步的，所述检测计数结果是否符合这一个业务场景的流控策略，包括：检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的设定值，其中，在流控策略中包括了针对一个或者多个业务场景的设定值，分析服务器可以检测一个业务场景当前实际并发量是否大于该业务场景的设定值。若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，并将超出了访问这一个业务场景的最大人数的用户的识别标识，添加至排队队列，其中，用户的识别标识具体可以是设备号、IP地址、MAC地址或者Token令牌等可以在一个业务场景中作为用户的唯一标识的信息。

所述对请求数量符合这一个业务场景的流控策略的用户进行限制，包括：检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求。若在指定的时间段再次发送了访问请求，则将用户的识别标识添加至排队队列。

其中，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数。或者，所有用户访问这一个业务场景的URL或者接口的次数之和。例如：针对URL的流控策略包括三个层级，从先到后依次为：

第一层级：限制并发量。如果并发数>F,则触发流控策略。否则，进入第二层级。

第二层级：限制所有用户的访问量。如果在A秒之内，所有用户的访问量>D,则第D个请求往后的所有请求都会进入排队。否则，进入第三层级。

第三层级：限制单个用户的访问量。如果在A秒之内，某个用户的访问量>B,则其在之后的C秒之内的请求都会进入排队。否则，放过该请求。

本发明实施例提供的控制访问流量的方法，针对具体的业务场景的恶意的刷单行为，对不同的业务场景采取各自的流控策略，从而对该业务场景下的用户操作行为进行了限制，缓解了由于恶意刷单造成的一些业务场景下的销售量受到影响的问题，从而减小运营商的经济损失。并且，相对于直接为各个业务系统增加服务器设备的系统优化方式，本实施例通过较为精确的控制线程资源对各个业务场景的性能进行优化，应付流量峰值时期的操作流量的优化手段的粒度更细，对于计算资源的调配也更灵活，改善了单纯的通过增设服务器设备来扩充负载能力的方式，缓解了由于大量增设服务器设备造成的运营成本增加的问题。

本发明实施例还提供一种控制访问流量的装置，具体可以运行在如图1所示的分析服务器上。如图3所示的该装置包括：

业务场景管理模块，用于根据所配置的业务数据，确定分配至各个业务场景的流控策略；

性能管理模块，用于根据由所述业务场景管理模块确定的各个业务场景的流控策略，分别分配各个业务场景的线程数；

用户管理模块，用于对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略；并对请求数量符合这一个业务场景的流控策略的用户进行限制。

在本实施例中，所述业务场景管理模块，具体用于从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景；并读取预设的各个业务场景的流控策略；

所述业务数据至少包括：所述业务系统中运行的虚拟机(JVM)的集合，和所述业务系统所展示页面的页面结构；所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符(URL)；

所述性能管理模块，具体用于根据各个业务场景的流控策略，确定各个业务场景在当前时间段内的优先级，并依据优先级确定各个业务场景的线程数；并按照所确定的各个业务场景的线程数，为各个业务场景的虚拟机分配线程；

所述用户管理模块，具体用于检测在当前的时间段内，访问业务场景的URL或者接口的次数；若所述次数大于触发阀值，则对所述用户标识限制访问次数；

所述用户管理模块，具体还用于检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的设定值；若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，并将超出了访问这一个业务场景的最大人数的用户的识别标识，添加至排队队列；

和，检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则将用户的识别标识添加至排队队列；

其中，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数；或者，所有用户访问这一个业务场景的URL或者接口的次数之和。

进一步的，如图4所示的该装置还包括：

计数器管理模块，用于检测计数器的计数值是否大于预设值；若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设值，得到所述计数器的真实值。

本发明实施例提供的控制访问流量的装置，针对具体的业务场景的恶意的刷单行为，对不同的业务场景采取各自的流控策略，从而对该业务场景下的用户操作行为进行了限制，缓解了由于恶意刷单造成的一些业务场景下的销售量受到影响的问题，从而减小运营商的经济损失。并且，相对于直接为各个业务系统增加服务器设备的系统优化方式，本实施例通过较为精确的控制线程资源对各个业务场景的性能进行优化，应付流量峰值时期的操作流量的优化手段的粒度更细，对于计算资源的调配也更灵活，改善了单纯的通过增设服务器设备来扩充负载能力的方式，缓解了由于大量增设服务器设备造成的运营成本增加的问题。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (8)

1.一种控制访问流量的方法，其特征在于，包括：

根据所配置的业务数据，确定分配至各个业务场景的流控策略；

根据各个业务场景的流控策略，分别分配各个业务场景的线程数；

对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略；

对请求数量符合这一个业务场景的流控策略的用户进行限制；

所述对请求数量符合这一个业务场景的流控策略的用户进行限制，包括：检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则将用户的识别标识添加至排队队列；

所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数；或者，所有用户访问这一个业务场景的URL或者接口的次数之和；

其中，针对URL的流控策略包括三个层级，从先到后依次为：第一层级：限制并发量；如果并发数>F,则触发流控策略，否则，进入第二层级；第二层级：限制所有用户的访问量，如果在A秒之内，所有用户的访问量>D,则第D个请求往后的所有请求都会进入排队；否则，进入第三层级；第三层级：限制单个用户的访问量；如果在A秒之内，某个用户的访问量>B,则其在之后的C秒之内的请求都会进入排队；否则，放过该请求。

2.根据权利要求1所述的方法，其特征在于，所述根据所配置的业务数据，确定分配至各个业务场景的流控策略，包括：

从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景，所述业务数据至少包括：所述业务系统中运行的虚拟机（JVM）的集合，和所述业务系统所展示页面的页面结构；所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符（URL）；

读取预设的各个业务场景的流控策略。

3.根据权利要求2所述的方法，其特征在于，根据各个业务场景的流控策略，分别分配各个业务场景的线程数，包括：

根据各个业务场景的流控策略，确定各个业务场景在当前时间段内的优先级，并依据优先级确定各个业务场景的线程数；

按照所确定的各个业务场景的线程数，为各个业务场景的虚拟机分配线程。

4.根据权利要求2所述的方法，其特征在于，所述计数用户发送的用于访问一个业务场景的请求数量，包括：

检测在当前的时间段内，访问业务场景的URL或者接口的次数；

若所述次数大于触发阀值，则对所述用户标识限制访问次数。

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

检测计数器的计数值是否大于预设值；

若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设值，得到所述计数器的真实值。

6.根据权利要求1所述的方法，其特征在于，所述检测计数结果是否符合这一个业务场景的流控策略，包括：

检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的设定值；

若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，并将超出了访问这一个业务场景的最大人数的用户的识别标识，添加至排队队列。

7.一种控制访问流量的装置，其特征在于，包括：

业务场景管理模块，用于根据所配置的业务数据，确定分配至各个业务场景的流控策略；

性能管理模块，用于根据由所述业务场景管理模块确定的各个业务场景的流控策略，分别分配各个业务场景的线程数；

用户管理模块，用于对于每一个业务场景：计数用户发送的用于访问一个业务场景的请求数量，并检测计数结果是否符合这一个业务场景的流控策略；并对请求数量符合这一个业务场景的流控策略的用户进行限制；

所述业务场景管理模块，具体用于从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景；并读取预设的各个业务场景的流控策略；

所述业务数据至少包括：所述业务系统中运行的虚拟机（JVM）的集合，和所述业务系统所展示页面的页面结构；所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符（URL）；

所述性能管理模块，具体用于根据各个业务场景的流控策略，确定各个业务场景在当前时间段内的优先级，并依据优先级确定各个业务场景的线程数；并按照所确定的各个业务场景的线程数，为各个业务场景的虚拟机分配线程；

所述用户管理模块，具体用于检测在当前的时间段内，访问业务场景的URL或者接口的次数；若所述次数大于触发阀值，则对所述用户标识限制访问次数；

所述用户管理模块，具体还用于检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的设定值；若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，并将超出了访问这一个业务场景的最大人数的用户的识别标识，添加至排队队列；

和，检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则将用户的识别标识添加至排队队列；

其中，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数；或者，所有用户访问这一个业务场景的URL或者接口的次数之和；

其中，针对URL的流控策略包括三个层级，从先到后依次为：第一层级：限制并发量；如果并发数>F,则触发流控策略，否则，进入第二层级；第二层级：限制所有用户的访问量，如果在A秒之内，所有用户的访问量>D,则第D个请求往后的所有请求都会进入排队；否则，进入第三层级；第三层级：限制单个用户的访问量；如果在A秒之内，某个用户的访问量>B,则其在之后的C秒之内的请求都会进入排队；否则，放过该请求。

8.根据权利要求7所述的装置，其特征在于，还包括：

计数器管理模块，用于检测计数器的计数值是否大于预设值；若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设值，得到所述计数器的真实值。

Images