CN108111554B - 一种访问队列的控制方法及装置 - Google Patents

Abstract

本发明实施例公开了一种访问队列的控制方法及装置，涉及互联网技术领域，能够缓减实际销售量降低的问题。本发明包括：当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识；从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列；根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送；当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务。本发明适用于处理具有海量访问请求的场景。

Description

一种访问队列的控制方法及装置

技术领域

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

背景技术

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

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

当用于承担下单和结算等功能的系统所承载的负载过大时，为了保障系统的正常运行并保障大部分用户的正常操作，通常会向发出超出负载部分的用户，反馈表示操作失败的消息，实际上就是中断了用户操作，很多用户在重复操作几次仍未成功的情况下往往会取消所下的订单，这就直接减少了实际销售量。又由于一些黄牛的恶意的刷单行为，通过自动脚本重复进行“下单-结算”的过程，且这些自动脚本大多将接收到的表示操作失败的消息作为循环触发的条件，使得自动脚本能够以很高的频率重复进行“下单-结算”的过程，这又会进一步增加操作流量，增多了普通用户的操作被中断的几率，从而降低了实际销售量，给商家造成不小的经济损失。

发明内容

本发明的实施例提供一种访问队列的控制方法及装置，能够缓减实际销售量降低的问题。

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

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

当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识；

从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列；

根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送，所述等待消息包括当前时刻至完成排队的剩余时间和在队列中的当前位置；

当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务。

结合第一方面，在第一方面的第一种可能的实现方式中，所述生成排队标识包括：

根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成排队标识。

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

确定对应所述业务场景的服务节点(Server)，并获取对应所述业务场景的服务节点的节点地址(Server IP)的数量；

对应所述业务场景，建立指定数量的队列，所述指定数量为对应所述业务场景的Server IP的虚拟机(JVM)的数量。

结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，所述指定数量为对应所述业务场景的Server IP的数量的2倍。

结合第一方面的第二种可能的实现方式，在第四种可能的实现方式中，所述根据所生成的排队标识所放入的队列，得到等待消息，包括：

获取所述排队标识放入的队列的时刻，该队列中的排队标识的总数；

根据所述该队列中的排队标识的总数，和所述排队标识放入的队列的时刻至当前时刻的该队列中的排队标识的出队数量，获取所述排队标识当前在所放入的队列中的位置；

根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间，并生成所述等待消息。

结合第一方面的第四种可能的实现方式，在第五种可能的实现方式中，所述根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间包括：

获取所述业务场景对应的各个队列的在一个调度周期内的出队数量，其中，一个队列的在一个调度周期内的出队数量＝(调度周期*应用服务节点的空闲线程数量*平均消耗速率*同一业务场景下的队列数量)/(用于流量控制的服务节点的数量)：

根据所述排队标识当前在所放入的队列中的位置和所放入的队列的在一个调度周期内的出队数量，确定所述当前时刻至完成排队的剩余时间；

其中：所述调度周期表示：将成排队的排队标识从这一个队列中剔除的时间间隔；所述应用服务节点(App Server)的空闲线程数量大于等于1；所述平均消耗速率表示：预设的对应同一业务场景的各个队列平均出队速率，所述平均消耗速率＝所述应用服务节点的每秒的处理的事务数量(tps)/所述应用服务节点的总线程数量；所述同一业务场景下的队列数量等于所述指定数量。

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

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

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

若是则执行所述业务场景的流控策略，并对请求数量不符合这一个业务场景的流控策略的用户进行限制。

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

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

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

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

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

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

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

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

若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，当所述用户数量将大于排队阈值时，将访问这一个业务场景的用户导入排队队列。

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

检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则导入这一个业务场景的队列，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数，或者，所有用户访问这一个业务场景的URL或者接口的次数的总和。

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

检测模块，用于当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识；

队列管理模块，用于从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列；并根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送，所述等待消息包括当前时刻至完成排队的剩余时间和在队列中的当前位置；

所述检测模块，还用于当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务。

结合第二方面，在第二方面的第一种可能的实现方式中，所述检测模块，具体用于根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成排队标识会员编码(Custno)；

所述队列管理模块，具体用于获取所述排队标识放入的队列的时刻，该队列中的排队标识的总数；并根据所述该队列中的排队标识的总数，和所述排队标识放入的队列的时刻至当前时刻的该队列中的排队标识的出队数量，获取所述排队标识当前在所放入的队列中的位置；之后根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间，并生成所述等待消息；

所述队列管理模块，具体还用于确定对应所述业务场景的服务节点(Server)，并获取对应所述业务场景的服务节点的节点地址(Server IP)的数量；对应所述业务场景，建立指定数量的队列，所述指定数量为对应所述业务场景的Server IP的虚拟机(JVM)的数量。

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

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

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

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

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

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

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

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

所述用户管理模块，具体还用于检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的阈值；若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，当所述用户数量将大于排队阈值时，将访问这一个业务场景的用户导入排队队列；

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

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

结合第二方面或第二方面的任意一种可能的实现方式,在第四种可能的实现方式中，还包括：计数器管理模块，用于检测计数器的计数值是否大于预设的设定值；若是则判定所述计数器具有生命周期，并根据所述计数器的计数值和预设的设定值，得到所述计数器的真实值。

本发明实施例提供的访问队列的控制方法及装置，在对业务场景采取了流控策略的情况下，对该业务场景下的用户操作行为进行了限制，并将用户引导入业务场景的队列中进行排队等待，向用户反馈等待消息。相对于通过反馈表示操作失败的消息来中断用户操作的方式，可以降低用户在得知操作失败后重复进行操作行为的几率，而在实际应用中，默认进入等待队列的用户取消所下的订单的几率也很低，缓减了实际销售量降低的问题，减少了商家的经济损失。

附图说明

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

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

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

图3、图4为本发明实施例提供的具体实例的示意图；

图5a、图5b为本发明实施例提供的一种可能的界面实例的示意图；

图6、图7、图8为本发明实施例提供的访问队列的控制装置的结构示意图。

具体实施方式

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

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

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

构，并获取页面结构中的商品信息、商品的URL(Uniform Resource Locator，统一资源定位符)信息、页面地址信息等用于表示业务场景的信息。分析服务器上可以运行基于Redis/kafka(其中，Redis是一种key-value存储系统，Kafka是一种高吞吐量的分布式发布订阅消息系统)的排队系统，具体可以Redis的list结构作为FIFO队列，从而建立对应各个业务场景的队列。其中，业务数据具体可以是业务系统中所配置的用于表示具体业务场景的信息，比如：商品信息、商品的URL信息、页面地址信息等。

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

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

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

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

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

S1、当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识。

其中，业务场景具体可以理解为一种或者多种业务数据以及页面内容的集合，这些业务数据与用户的操作行为相关联且会由于用户的操作产生流量负载，比如：并获取页面结构中的商品信息、商品的URL信息、页面地址信息等用于表示业务场景的信息。例如：在促销系统中，业务场景包括了一个商品的促销活动(促销活动具体可以呈现为目前各类购物网站上的包括了广告信息、商品简介等信息的活动界面)，则可以从促销系统中提取所配置的该商品的URL信息或者促销系统所展示的促销页面的页面地址，作为所述业务数据。而各个用户操作各自的用户设备通过URL信息访问促销页面，或者通过输入页面地址将浏览器跳转至促销页面的行为，都可以记录为这些用户在业务场景下的操作行为。例如：在下单系统中，业务场景包括了等待支付操作的商品列表，则商品信息、商品数量、店铺信息等可以作为所述业务数据。而各个用户操作各自的用户设备进行验证、支付的操作，都可以记录为这些用户在业务场景下的操作行为。

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

具体的，分析服务器接收/获取到用户设备发出的访问请求(比如用于下单并支付的访问请求)，该访问请求指向对应的业务系统中具体的业务场景。分析服务器可以先检测用户设备发送的访问请求指向的业务场景检测是否达到流控阀值，若是则该业务场景的流控策略被激活并执行。此时分析服务器触发生成对应该用户设备的排队标识TokenID(一种基于Token机制生成的唯一标识)并将其放入对应该业务场景的其中的一个队列，并将包括了排队标识的排队轮询结果反馈给用户设备。

在本实施例中，分析服务器在生产排队标识后，可以将所生成的排队标识向用户设备发送，以便于通知用户设备：本次访问已进入排队过程，并在S3将向用户设备发送等待消息，以便于用户设备根据等待消息显示最新的剩余时间和在队列中最新的位置；也可以是，分析服务器在生产排队标识后，通过排队标识对用户进行排队，并将生成的等待消息发送给用户设备，即分析服务器向用户设备发送等待消息而不再发送排队标识，从而减少排队过程中与用户设备的信息交互次数。

S2、从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列。

S3、根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送。

其中，所述等待消息包括当前时刻至完成排队的剩余时间和在队列中的当前位置。具体的，分析服务器可以按预设周期定时向所述用户设备发送等待消息，每一次发送的等待消息中包括了最新的剩余时间和在队列中最新的位置。

S4、当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务。

其中，当TokenID在调度策略的控制下出队后，带有该TokenID的请求被再次发送。这时，流控监控模块会根据TokenID放过该请求，即本次排队完成。例如：如图4所示的，当排队结束后，分析服务器可以向用户发送表示排队结束的通知消息，并触发用户设备再次发送携带了排队标识的(比如TokenID)的访问请求，分析服务器在验证TokenID合法则继续原业务处理。若用户设备再次发送的访问请求中不包括合法的TokenID，则继续排队。

本发明实施例提供的访问队列的控制方法，在对业务场景采取了流控策略的情况下，对该业务场景下的用户操作行为进行了限制，并将用户引导入业务场景的队列中进行排队等待，向用户反馈等待消息。相对于通过反馈表示操作失败的消息来中断用户操作的方式，可以降低用户在得知操作失败后重复进行操作行为的几率，而在实际应用中，默认进入等待队列的用户取消所下的订单的几率也很低，缓减了实际销售量降低的问题，减少了商家的经济损失。并且对于一些用于恶意刷单的自动脚本，都会进入排队等待，通过队列作为缓冲，使得自动脚本无法通过大量刷单立即完成访问操作，从而也就降低了频繁刷单对于其他普通用户的影响。

在本实施例中可以采用Token机制，来保障用户在展示线和交易线进行操作的畅通。采用Token机制的消息的生命周期受访问次数和时间限制。具体的，本实施例中生成排队标识的具体方式可以包括：

根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成排队标识。

例如：若将TokenID作为排队标识，则根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成TokenID，还可以在TokenID的字符串末尾增加用于表示状态信息的字符。其中，每个TokenID为每个业务系统中的唯一的标识，TokenID有自己的生命周期，TokenID生成、销毁、生命周期由流控排队系统维护。

具体的：

对于未生效生命周期由时间维度来描述，时间默认为5分钟；

对于生效生命周期由时间和次数两个维度进行描述，时间维度为10S，次数为1次，其中：

若TokenID已经生效且在10秒后未被使用表明此TokenID已经失效；

若TokenID已经生效且在10秒内使用次数已经达到1表示此TokenID已经生效；

若TokenID失效，则再次进入排队。其中，在TokenID的末尾的状态信息中，若字符为1，则表示TokenID的状态为生效，若字符为0则表示未效。

针对各业务场景所建立的队列，在本实施例中，可以采用Redis的List数据结构，入队由流控组件操作使用LPUSH方法，出队由流控排队系统的调度模块使用RPOP方法，其中，LPUSH、RPOP都是Redis中的命令方法。例如：本实施例中还包括：

确定对应所述业务场景的服务节点(Server)，并获取对应所述业务场景的服务节点的节点地址(Server IP)的数量。本实施例中，服务节点(Server)具体可以是根据所分配的硬件资源(比如内存、CPU或者线程等)建立的用于数据处理的虚拟机，按照具体功能可以分为应用服务节点(App Server)和用于流量控制的服务节点(Web Server)。

对应所述业务场景，建立指定数量的队列，所述指定数量为对应所述业务场景的Server IP的虚拟机(JVM)的数量，比如：Server IP对应2个JVM，队列数量设定为server IP数量的2倍，从而则刚好可以保证一个应用服务节点对应一个队列，避免出现一个队列对应多个Server的情况。例如：采用如图3所示的排队方式，其中Redis/kafka是一种队列管理器，具体可以Redis的list结构作为FIFO队列，并在Redis/kafka中记录流控策略被触发的应用场景。

分析服务器通过应用层包括前段设备和后端设备，其中前段设备对Redis/kafka进行队列调度，后端设备连接数据层数据库并通过显示器或者触摸屏输出显示可视化的界面，以便于技术人员观察队列调度的情况。在数据库中，注册了运行本实施例中所述的流控策略的业务系统，并可以实时接收新的业务系统注册，并存储新注册的业务系统的流控策略或者向新注册的业务系统提供数据库中预先存储的流控策略；在数据库中还可以记录对于各个业务场景的负载情况进行监控得到的历史数据，以及对应各个业务场景的队列的监控数据，以便于后续分析使用。

配置数据由SCM配置中心向应用服务节点和分析服务器发送，在SCM配置中心配置并作为发送的配置数据可以包括：调度周期、应用服务节点的空闲线程数量、平均消耗速率、同一业务场景下的队列数量和用于流量控制的服务节点(Web Server)的数量等参数。

应用服务节点还可以监控用户设备对触发了流控策略的业务场景进行访问的情况，并记录在流控策略的执行过程中对于用户访问数量等维度的监控统计结果，并传输给Redis/kafka。业务场景具体可以包括智能货架、CMS(Content Management System，内容管理系统)等业务场景。

每个应用系统各拥有M个队列(M＝排队系统App Server数量*N，N≥2，N为整数，App Server可以理解为用于支撑具体应用场景的服务节点)，每个队列都有各自独立的调度器。在应用系统接入后，需要对应用系统分配队列，而每一个应用系统的队列数与Server数一致。这样在队列调度时，不论是对集群Server还是对单Server，对Server的调度方式都一样。这里的Server指的是由划分出的计算资源建立的服务器节点。使得操作集群环境和单Server没有区别，也降低了在集群环境中队列调度算法的复杂性。

在本实施例的优选方案中，所述指定数量为对应所述业务场景的Server IP的数量的2倍。

在本实施例中，所述根据所生成的排队标识所放入的队列并得到等待消息的具体方式，包括：

获取所述排队标识放入的队列的时刻，该队列中的排队标识的总数。

根据所述该队列中的排队标识的总数，和所述排队标识放入的队列的时刻至当前时刻的该队列中的排队标识的出队数量，获取所述排队标识当前在所放入的队列中的位置。比如：TokenID当前位置＝所有入队的TokenID总数(某TokenID入队时刻)-所有出队的TokenID总数(当前时刻)。

根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间，并生成所述等待消息。

在本实施例中，获取剩余时间的具体方式包括：获取所述业务场景对应的各个队列的在一个调度周期内的出队数量；并根据所述排队标识当前在所放入的队列中的位置和所放入的队列的在一个调度周期内的出队数量，确定所述当前时刻至完成排队的剩余时间。

其中，一个队列的在一个调度周期内的出队数量＝(调度周期*应用服务节点的空闲线程数量*平均消耗速率*同一业务场景下的队列数量)/(用于流量控制的服务节点的数量)。

其中：所述调度周期表示：将成排队的排队标识从这一个队列中剔除的时间间隔，可以按照该时间间隔把排完队的排队标识剔除出队，剔除出队的排队标识对应的用户即判定为可以正常访问，之后分析服务器可以向用户终端发送通知，用户终端接到通知后再次发送访问请求，比如：用户终端通过自动刷新浏览器页面的方式再次发送访问请求。；所述应用服务节点(App Server)的空闲线程数量大于等于1；所述平均消耗速率表示：预设的对应同一业务场景的各个队列平均出队速率，所述平均消耗速率＝所述应用服务节点的每秒的处理的事务数量(tps)/所述应用服务节点的总线程数量，比如：对单个APP server为1000tps(每秒的处理的事务数量)，线程数为10，平均消耗速率应该为1000tps/10＝100，具体可以由技术人员在SCM配置中心设置平均消耗速率或者由SCM配置中心自动配置；所述同一业务场景下的队列数量等于所述指定数量。

具体的，剩余时间＝TokenID当前位置/(在一个调度周期内的出队数量*调度周期)。使得用户可以看到当前排队的位置和等待的剩余时间，由于上述计算方法与Redis零交互，从而降低了Redis的运行压力。在每一个反馈周期中，分析服务器都可以重复执行一遍上述过程来刷新“当前时刻至完成排队的剩余时间”和“在队列中的当前位置”，并将刷新后的结果反馈至用户设备，以便于用户设备也同步刷新所显示的“当前时刻至完成排队的剩余时间”和“在队列中的当前位置”。例如：在排队过程中，用户设备可以向分析服务器每隔7秒请求获取一次最新的排队位置和剩余时间。具体如图5a所示的，当用户等待的时间<＝10分钟时，显示当前位置和剩余时间；以及如图5b所示的，当等待时间>10分钟时，提醒用户耐心排队等待。

在本实施例中，通过分配队列的方式，避免了从业务上去限制接入人数，并可以依据具体情况设置多个队列，从而保障分流至每个队列中的用户设备数量相近。比如：在具体理解上，可以类比超市收银台的排队方式，新接入的用户被分配至人数较少的队列中。

本实施例还提供一种对针对业务场景进行流量控制的方式，具体包括：

根据所配置的业务数据，确定分配至所述业务场景的流控策略。并计数用户发送的用于访问所述业务场景的请求数量，并检测计数结果是否符合所述业务场景的流控策略。若是则执行所述业务场景的流控策略，并对请求数量不符合这一个业务场景的流控策略的用户进行限制。

具体的，所述根据所配置的业务数据，确定分配至各个业务场景的流控策略的方式可以包括：从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景。并读取预设的各个业务场景的流控策略。其中，所述业务数据至少包括：所述业务系统中运行的虚拟机(JVM)的集合，和所述业务系统所展示页面的页面结构。所述业务场景至少包括：所述业务系统中所运行的且用于承担业务功能的虚拟机，和所述业务系统所展示页面的页面结构对应的统一资源定位符(URL)。具体的，不同的业务场景可以由至少一个虚拟机承担业务场景中所涉及的业务功能，比如对用户的操作进行处理。例如：针对不同业务场景进行单个JVM(Java虚拟机)线程数分配，可降级业务可以把线程数分配为0。从而通过控制分配至业务的线程，控制系统对于业务的处理能力(限制负载)，使得在用户接入业务时能够正常顺利的接入，不再通过反馈表示操作失败或者强制等待的消息来限制用户的接入。而将对于用户的卡口限制在业务的负载能力上，且可以根据当前业务的重要程度，调整分配至各个业务的负载资源(线程)，避免了由于用户在业务入口被卡主而导致的用户流失。

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

其中，所述根据所配置的业务数据，确定分配至所述业务场景的流控策略，包括：从业务系统提取业务数据，根据所提取的业务数据确定所述业务系统中存在的业务场景，并读取预设的各个业务场景的流控策略。

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

具体的，计数结果是否符合所述业务场景的流控策略的方式包括：检测在当前时间段内，对应用户标识的访问业务场景的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(UserAgent，用户代理；也可称为消息头)；用户标识也可以采用Token令牌(一种基于Token机制生成的标识)，比如：在用户进入排队队列时，采用的Token令牌也可以称为Token ID，排队结束后用户设备再次发送的访问请求中需要有Token ID的才能访问业务场景。

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

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

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

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

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

进一步的，所述检测计数结果是否符合这一个业务场景的流控策略，包括：检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的阈值。若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，当所述用户数量将大于排队阈值时，将访问这一个业务场景的用户导入排队队列。

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

具体的，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数。或者，所有用户访问这一个业务场景的URL或者接口的次数的总和。检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求。若在指定的时间段再次发送了访问请求，则导入这一个业务场景的队列。

例如：针对URL的流控策略包括三个层级，从先到后依次为：

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

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

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

本发明实施例提供的访问队列的控制方法及装置，在对业务场景采取了流控策略的情况下，对该业务场景下的用户操作行为进行了限制，并将用户引导入业务场景的队列中进行排队等待，向用户反馈等待消息。相对于通过反馈表示操作失败的消息来中断用户操作的方式，可以降低用户在得知操作失败后重复进行操作行为的几率，而在实际应用中，默认进入等待队列的用户取消所下的订单的几率也很低，缓减了实际销售量降低的问题，减少了商家的经济损失。并且对于一些用于恶意刷单的自动脚本，都会进入排队等待，通过队列作为缓冲，使得自动脚本无法通过大量刷单立即完成访问操作，从而也就降低了频繁刷单对于其他普通用户的影响。

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

检测模块，用于当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识；

队列管理模块，用于从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列；并根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送，所述等待消息包括当前时刻至完成排队的剩余时间和在队列中的当前位置；

所述检测模块，还用于当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务。

在本实施例中，所述检测模块，具体用于根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成排队标识；

所述队列管理模块，具体用于获取所述排队标识放入的队列的时刻，该队列中的排队标识的总数；并根据所述该队列中的排队标识的总数，和所述排队标识放入的队列的时刻至当前时刻的该队列中的排队标识的出队数量，获取所述排队标识当前在所放入的队列中的位置；之后根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间，并生成所述等待消息；

所述队列管理模块，具体还用于确定对应所述业务场景的服务节点(Server)，并获取对应所述业务场景的服务节点的节点地址(Server IP)的数量；对应所述业务场景，建立指定数量的队列，所述指定数量为对应所述业务场景的Server IP的虚拟机(JVM)的数量。

本发明实施例提供的访问队列的控制装置，在对业务场景采取了流控策略的情况下，对该业务场景下的用户操作行为进行了限制，并将用户引导入业务场景的队列中进行排队等待，向用户反馈等待消息。相对于通过反馈表示操作失败的消息来中断用户操作的方式，可以降低用户在得知操作失败后重复进行操作行为的几率，而在实际应用中，默认进入等待队列的用户取消所下的订单的几率也很低，缓减了实际销售量降低的问题，减少了商家的经济损失。并且对于一些用于恶意刷单的自动脚本，都会进入排队等待，通过队列作为缓冲，使得自动脚本无法通过大量刷单立即完成访问操作，从而也就降低了频繁刷单对于其他普通用户的影响。

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

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

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

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

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

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

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

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

所述用户管理模块，具体还用于检测对于这一个业务场景的并发量是否大于这一个业务场景的流控策略的阈值；若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，当所述用户数量将大于排队阈值时，将访问这一个业务场景的用户导入排队队列；

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

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

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

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

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

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

Claims (11)

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

当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识；

从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列；

根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送，所述等待消息包括当前时刻至完成排队的剩余时间和在队列中的当前位置；

当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务；

还包括：

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

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

若是则执行所述业务场景的流控策略，并对请求数量不符合这一个业务场景的流控策略的用户进行限制；

所述检测计数结果是否符合这一个业务场景的流控策略，包括：

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

若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，当所述用户数量将大于排队阈值时，将访问这一个业务场景的用户导入排队队列。

2.根据权利要求1所述的方法，其特征在于，所述生成排队标识包括：

根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成排队标识。

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

确定对应所述业务场景的服务节点(Server)，并获取对应所述业务场景的服务节点的节点地址(ServerIP)的数量；

对应所述业务场景，建立指定数量的队列，所述指定数量为对应所述业务场景的Server IP的虚拟机(JVM)的数量。

4.根据权利要求3所述的方法，其特征在于，所述根据所生成的排队标识所放入的队列，得到等待消息，包括：

获取所述排队标识放入的队列的时刻，该队列中的排队标识的总数；

根据所述该队列中的排队标识的总数，和所述排队标识放入的队列的时刻至当前时刻的该队列中的排队标识的出队数量，获取所述排队标识当前在所放入的队列中的位置；

根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间，并生成所述等待消息。

5.根据权利要求4所述的方法，其特征在于，所述根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间包括：

获取所述业务场景对应的各个队列的在一个调度周期内的出队数量，其中，一个队列的在一个调度周期内的出队数量＝(调度周期*应用服务节点的空闲线程数量*平均消耗速率*同一业务场景下的队列数量)/(用于流量控制的服务节点的数量)：

根据所述排队标识当前在所放入的队列中的位置和所放入的队列的在一个调度周期内的出队数量，确定所述当前时刻至完成排队的剩余时间；

其中：所述调度周期表示：将排成队列的排队标识从这一个队列中剔除的时间间隔；所述应用服务节点(App Server)的空闲线程数量大于等于1；所述平均消耗速率表示：预设的对应同一业务场景的各个队列平均出队速率，所述平均消耗速率＝所述应用服务节点的每秒的处理的事务数量(tps)/所述应用服务节点的总线程数量；所述同一业务场景下的队列数量等于所述指定数量。

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

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

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

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

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

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

8.根据权利要求1所述的方法，其特征在于，所述对请求数量不符合这一个业务场景的流控策略的用户进行限制，包括：

检测用户发送的请求数量是否超过这一个业务场景的流控策略中所设定的最大值，若是则检测在指定的时间段是否再次发送访问请求；若在指定的时间段再次发送了访问请求，则导入这一个业务场景的队列，所述用户发送的请求数量包括：单个用户访问这一个业务场景的URL或者接口的次数，或者，所有用户访问这一个业务场景的URL或者接口的次数的总和。

9.一种访问队列的控制装置，其特征在于，包括：

检测模块，用于当检测到用户设备发送的访问请求指向的业务场景的流控策略被执行时，生成排队标识；

队列管理模块，用于从所述业务场景对应的队列中，选择其中一个队列，并将所生成的排队标识放入所选择的队列；并根据所生成的排队标识所放入的队列，得到等待消息，并向所述用户设备发送，所述等待消息包括当前时刻至完成排队的剩余时间和在队列中的当前位置；

所述检测模块，还用于当所生成排队标识完成所在队列中的排队后，接收所述用户设备再次发送的访问请求，并在检测到所述访问请求中包含所述排队标识时，继续处理所述访问请求对应的业务；

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

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

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

所述检测计数结果是否符合这一个业务场景的流控策略，包括：

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

若是，则在预设的时间段内，检测访问这一个业务场景的用户数量，当所述用户数量将大于排队阈值时，将访问这一个业务场景的用户导入排队队列。

10.根据权利要求9所述的装置，其特征在于，所述检测模块，具体用于根据会员编码(Custno)、有效标识和随机数，进行加密计算并生成排队标识；

所述队列管理模块，具体用于获取所述排队标识放入的队列的时刻，该队列中的排队标识的总数；并根据所述该队列中的排队标识的总数，和所述排队标识放入的队列的时刻至当前时刻的该队列中的排队标识的出队数量，获取所述排队标识当前在所放入的队列中的位置；之后根据所述排队标识当前在所放入的队列中的位置得到所述当前时刻至完成排队的剩余时间，并生成所述等待消息；

所述队列管理模块，具体还用于确定对应所述业务场景的服务节点(Server)，并获取对应所述业务场景的服务节点的节点地址(Server IP)的数量；对应所述业务场景，建立指定数量的队列，所述指定数量为对应所述业务场景的Server IP的虚拟机(JVM)的数量。

11.根据权利要求9或10所述的装置，其特征在于，还包括：

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

Images