CN109087055B - 业务请求的控制方法和装置 - Google Patents

Abstract

本发明提供了一种业务请求的控制方法和装置，该方法包括：在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增；判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的业务请求禁止执行后续的业务逻辑。本发明实现了分布式流量的控制，以及对高并发的业务请求的及时应对，并确保了被访问的业务资源的原子化。

Description

业务请求的控制方法和装置

技术领域

本发明涉及计算机技术领域，特别是涉及一种业务请求的控制方法和装置。

背景技术

流量限制在后台服务设计中使用较为频繁，目的是为了减小上层服务请求，对下层核心服务的影响，防止核心服务出现不可用的情况。具体而言，当突然间存在对同一业务资源的巨大访问量时，系统容易宕机崩溃，使得对任意一个业务访问请求都无法处理。

此外，在高并发的场景下，当大量的业务请求访问同一种有限的业务资源时，还会存在请求超发的问题。例如在双十一期间，客户订单量较大，而某种商品的库存是有限的，那么当商品开抢时，系统可以同一时间接收到对该商品的大量订单请求，往往造成实际库存已经不足或为零，但是系统还是在对同时收到的多个订单进行响应，来完成多个订单，无法保证被访问的资源的原子性。

因此，现有技术中的业务请求的处理方案显然存在着无法应对高并发的业务请求，以及无法确保被访问的业务资源的原子化的问题。

发明内容

本发明提供了一种业务请求的控制方法和装置，以解决现有技术中的业务请求的处理方案所存在的无法应对高并发的业务请求，以及无法确保被访问的业务资源的原子化的问题。

为了解决上述问题，根据本发明的一个方面，本发明公开了一种业务请求的控制方法，包括：

在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增；

判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；

在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的业务请求禁止执行后续的业务逻辑。

在一种可能的实施方式中，所述Redis服务器采用键-值存储每个业务接口的QPS数值，其中，所述Redis服务器预先为每个业务接口分配一个键，每个键对应的值用于存储对应业务接口的QPS数值，其中，所述值的数据类型为哈希表，所述哈希表为字段与字段值的映射表；

所述在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增，包括：

在业务接口接收到一个业务请求时，Redis服务器确定所述业务接口对应的目标键、以及所述业务请求的接收时间点，其中，所述接收时间点的最小时间单位为秒；

所述Redis服务器根据所述接收时间点计算所述目标键的目标字段；

所述Redis服务器对所述目标键的哈希表中所述目标字段对应的目标字段值加一；

所述在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器，包括：

在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器。

在一种可能的实施方式中，所述Redis服务器对所述目标键的哈希表中所述目标字段对应的目标字段值加一，包括：

在所述Redis服务器的目标键对应的哈希表中不存在目标字段时，所述Redis服务器对所述目标键的哈希表添加目标字段，并对所述目标字段对应的目标字段值从零开始加一；

在所述Redis服务器的目标键对应的哈希表中存在目标字段时，所述Redis服务器对所述目标键的哈希表中所述目标字段对应的目标字段值从现有数值开始加一。

在一种可能的实施方式中，所述在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器之后，所述方法还包括：

在所述业务接口再次接收到一个业务请求、且再次接收到的业务请求的接收时间点对应的字段与所述目标字段相同时，所述Redis服务器返回第二预设错误信息至所述业务接口对应的业务服务器，其中，第二预设错误信息用于表示对所述业务接口当前接收到的业务请求拒绝响应。

在一种可能的实施方式中，所述在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器之后，所述方法还包括：

所述Redis服务器按照预设时间周期对目标哈希表中的数据进行清除，其中，所述目标哈希表为字段对应的接收时间点位于当前时间点之前的哈希表。

在一种可能的实施方式中，所述在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增，包括：

在业务接口接收到一个业务请求时，Redis服务器采用Lua脚本对所述业务接口对应所述QPS指标进行数量自增。

在一种可能的实施方式中，所述方法还包括：

Redis服务器实时从业务服务器接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值；

所述Redis服务器采用所述更新后的预设QPS阈值对相应业务接口的预设QPS阈值进行更新。

根据本发明的另一方面，本发明还公开了一种业务请求的控制装置，应用于Redis服务器，所述控制装置包括：

自增模块，用于在业务接口接收到一个业务请求时，对所述业务接口对应的QPS指标进行数量自增；

判断模块，用于判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；

第一返回模块，用于在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的业务请求禁止执行后续的业务逻辑。

在一种可能的实施方式中，所述Redis服务器采用键-值存储每个业务接口的QPS数值，其中，所述Redis服务器预先为每个业务接口分配一个键，每个键对应的值用于存储对应业务接口的QPS数值，其中，所述值的数据类型为哈希表，所述哈希表为字段与字段值的映射表；

所述自增模块包括：

确定子模块，用于在业务接口接收到一个业务请求时，确定所述业务接口对应的目标键、以及所述业务请求的接收时间点，其中，所述接收时间点的最小时间单位为秒；

计算子模块，用于根据所述接收时间点计算所述目标键的目标字段；

自增子模块，用于对所述目标键的哈希表中所述目标字段对应的目标字段值加一；

所述第一返回模块，还用于在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，返回第一预设错误信息至所述业务接口对应的业务服务器。

在一种可能的实施方式中，所述自增子模块包括：

第一自增单元，用于在所述Redis服务器的目标键对应的哈希表中不存在目标字段时，对所述目标键的哈希表添加目标字段，并对所述目标字段对应的目标字段值从零开始加一；

第二自增单元，用于在所述Redis服务器的目标键对应的哈希表中存在目标字段时，对所述目标键的哈希表中所述目标字段对应的目标字段值从现有数值开始加一。

在一种可能的实施方式中，所述装置还包括：

第二返回模块，用于在所述业务接口再次接收到一个业务请求、且再次接收到的业务请求的接收时间点对应的字段与所述目标字段相同时，返回第二预设错误信息至所述业务接口对应的业务服务器，其中，第二预设错误信息用于表示对所述业务接口当前接收到的业务请求拒绝响应。

在一种可能的实施方式中，所述装置还包括：

清除模块，用于按照预设时间周期对目标哈希表中的数据进行清除，其中，所述目标哈希表为字段对应的接收时间点位于当前时间点之前的哈希表。

在一种可能的实施方式中，所述自增模块，还用于在业务接口接收到一个业务请求时，采用Lua脚本对所述业务接口对应所述QPS指标进行数量自增。

在一种可能的实施方式中，所述装置还包括：

接收模块，用于实时从业务服务器接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值；

更新模块，用于采用所述更新后的预设QPS阈值对相应业务接口的预设QPS阈值进行更新。

根据本发明的再一方面，本发明还公开了一种Redis服务器，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的业务请求的控制程序，所述业务请求的控制程序被所述处理器执行时实现上述任意一种实施方式中的业务请求的控制方法的步骤。

根据本发明的又一方面，本发明还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有业务请求的控制程序，所述业务请求的控制程序被处理器执行时实现上述任意一种实施方式中的业务请求的控制方法中的步骤。

与现有技术相比，本发明包括以下优点：

本发明实施例利用Redis服务器的单线程模型的特点，使Redis服务器对业务接口进行监控，在业务接口接收到一个业务请求的情况下，Redis服务器就可以对该业务接口的QPS指标进行数量自增，并预先设置对各个业务接口的QPS阈值；那么如果数量自增后的某个业务接口的QPS指标超过对应该业务接口的QPS阈值，则返回错误信息至该业务接口对应的业务服务器，实现了分布式流量的控制，对高并发的业务请求的及时应对，并确保了被访问的业务资源的原子化。

附图说明

图1是本发明的一种业务请求的控制系统实施例的结构框图；

图2是本发明的一种业务请求的控制方法实施例的步骤流程图；

图3是本发明的一种业务请求的控制装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图1，示出了本发明的一种业务请求的控制系统实施例的结构框图，具体可以包括：

客户端、业务接口(这里包括业务接口1、业务接口2…业务接口N)、业务服务器集群、Redis服务器集群和Zookeeper集群。

其中，业务服务器集群包括多个业务服务器，Redis服务器集群包括多个Redis服务器，Zookeeper集群包括多个Zookeeper。

由于服务器集群中各个服务器的功能是相同的，因此，这里以单个服务器为例来对本发明实施例的控制系统进行说明。

业务服务器可以处理多个业务，每个业务可以对应M个业务接口(M大于或等于1，且小于N)，客户端通过业务接口与业务服务器通信，客户端通过业务接口向业务服务器发送业务请求，从而获取资源；

但是，由于对于访问的任意一种资源都是有限的，那么为了应对高并发的业务请求，并确保被访问的业务资源的原子化，本发明实施例的业务请求的控制系统还包括了Redis服务器和Zookeeper。

其中，Redis服务器具有单线程原子特性，因此，可以确保分布式环境的高并发场景下对每个业务接口接收到的业务请求的计数准确性；

Redis是一个开源的，BSD(Berkeley Software Distribution)许可的，高级的“键(Key)-值(Value)”的缓存与存储。它经常被称为是一个数据结构服务器，它支持存储的Value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(orted set，有序集合)和hash(哈希类型)。由于Redis是一个开源的Key-Value缓存和存储，部署极为简单，然后可以通过Lua脚本来实现本发明实施例的业务请求的控制。其中，Lua脚本是一种轻量小巧的脚本语言，用标准C语言编写并以源代码形式开放，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。Lua的扩展性好，可以实现更多的功能，本发明实施例可以根据业务请求的实际控制需求，对Lua进行控制方法的编写，并将编写后的Lua嵌入到Redis服务器中。

为了确保被访问业务资源的原子化，本发明实施例可以对每个业务接口人工配置QPS(Query Per Second，每秒查询率)数值，其中，QPS是对一个查询服务器在规定时间内所处理流量多少的衡量标准。并将人工配置的每个业务接口的QPS数值保存在Zookeeper中。

其中，Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper配置有良好的可用性以及并发更新的通知机制，Zookeeper通过监听器来监听对各个业务接口所配置的QPS的数值(即QPS阈值)的变更，其中，由于QPS可以人为的动态修改，因此，一旦Zookeeper通过监听器监听到存在某个QPS的配置数值的变化，Zookeeper就会及时的通过业务服务器来将各个业务接口最新的QPS配置数值通知给Redis服务器，实现对最新的QPS配置数值的自动提醒。然后，Redis服务器就可以利用由业务服务器转发的来自Zookeeper的各个业务接口的最新QPS阈值来对各个业务接口的业务请求进行控制，能够很好地应对各个业务接口的高并发业务请求，同时又确保了被访问的业务资源的原子化。

在一种可能的实施方式中，该Zookeeper也可以替换为一个数据库，也就是说，本发明实施例可以将人工配置的各个业务接口的最新QPS数值存储在该数据库中，那么在具体进行业务请求的控制时，则需要Redis服务器在每次QPS的配置数值更改时都通过业务服务器去该数据库中去查询最新的QPS数值，只是这种采用数据库来存储配置的QPS数值的方式，不能够将更新后的最新QPS数值进行自动提醒至Redis服务器，而需要Redis服务器主动去获取最新的QPS数值，但是，这种数据库的方案同样能够实现本发明实施例控制系统的对高并发的业务请求的应对，以及确保被访问的业务资源的原子化的功能。

结合图1所示的控制系统，这里参照图2，示出了本发明的一种业务请求的控制方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增；

其中，该业务接口可以是图1所示的控制系统中的任意一个业务接口。

当Redis服务器检测到某个业务接口接收到一个业务请求后，Redis服务器就会对该业务接口的QPS指标进行数量自增。

在一种可能的实施方式中，在执行步骤101时，在业务接口接收到一个业务请求时，Redis服务器可以采用Lua脚本对所述业务接口对应所述QPS指标进行数量自增。

也就是说，如图1所示的实施例所述，Redis服务器可以采用Lua脚本来编写本发明实施例的控制方法，因此，Redis服务器可以通过Lua脚本来进行上述QPS指标的数量自增操作。

其中，由于Lua脚本的扩展性好，可以实现更多的控制功能，Redis服务器就可以利用Lua脚本来作为控制方法的扩展工具，实现分布式流量的控制。

在一种可能的实施方式一中，如图1所示的实施例所述，该Redis服务器可以采用键(Key)-值(Value)来存储每个业务接口的QPS数值；其中，所述Redis服务器可以预先为每个业务接口分配一个Key。例如为业务接口1分配interface1key，为业务接口2分配interface2key；每个Key对应的Value则用于存储对应业务接口的QPS数值，即，interface1key对应的Value用于存储业务接口1的QPS数值；interface2key对应的Value用于存储业务接口2的QPS数值。

而Value支持的数据类型有很多，具体参照上述实施例，那么在本实施例中，所述Value的数据类型则为哈希表，所述哈希表为field(字段)与value(字段值)的映射表；也就是说，每个业务接口的QPS数值都存储在对应Key的哈希表中。例如业务接口1的QPS数值存储在与interface1key对应的hash1表中，例如业务接口2的QPS数值存储在与interface2key对应的hash2表中。

需要注意的是，这里的Value表示Redis的存储结构的键对应的值，value表示哈希表中的对应字段的字段值。

那么在执行步骤101时，则可以通过如下方式来实现：

在业务接口接收到一个业务请求时，Redis服务器确定所述业务接口对应的目标Key、以及所述业务请求的接收时间点；

例如，业务接口1接收到一个业务请求，则Redis服务器可以确定预先为该业务接口1分配的目标Key(目标键)，即interface1key；此外，Redis服务器还可以确定该业务请求的接收时间点，例如12点30分30秒，其中，由于QPS指标描述的是每秒查询率，因此，所述接收时间点的最小时间单位为秒。

所述Redis服务器根据所述接收时间点计算所述目标Key的目标field(目标字段)；

其中，Redis服务器中数据的存储结构为Key-Value(其中，Value为hash形式)，一个业务接口对应一个hash表，该hash表中存储了在接收到业务请求的各个时间点(时间单位为秒)，业务接口所接收的业务请求的总数。

为了区分不同时间点(时间单位为秒)所接收到的业务请求的总数，这里Redis服务器可以按照HHMMSS(即，小时分钟秒)这一原则来计算各个接收时间点的field，例如业务接口1接收到业务请求的接收时间点为12点30分30秒，则可以将123030作为interface1key对应的field。

所述Redis服务器对所述目标Key的哈希表中所述目标field对应的目标value(目标字段值)加一；

其中，field的取值123030对应的value存储的是该12点30分30秒这一秒内该业务接口1接收到的业务请求的数量。

因此，当检测到业务接口1接收到了一个业务接口后，就可以对interface1key的哈希表中的field为123030的记录进行操作，具体为对123030对应的value的数值加1。

其中，该步骤所体现的指令可以为hincrby interface1key 123030 1，其中，该hincrby命令用于为哈希表中的字段值(这里为123030对应的value)加上指定增量值(这里为1)。

表1示意了本发明一个实施例的Key-Value(其中，Value为field-value形式的hash表)的数据存储结构，这里示出了业务接口1和业务接口2在12点30分30秒～12点30分32秒中每一秒所接收到的业务请求的统计量。

表1

在一种可能的实施方式中，在执行所述Redis服务器对所述目标Key的哈希表中所述目标field对应的目标value加一时，可以分为以下两种情况来执行：

若所述Redis服务器的目标Key对应的哈希表中不存在目标field，则所述Redis服务器对所述目标Key的哈希表添加目标field，并对所述目标field对应的目标value从零开始加一；

以业务接口1为例进行说明，例如Redis服务器的系统时间刚刚从12点30分30秒这一秒结束，进入下一秒12点30分31秒，那么Redis服务器中interface1key的哈希表中显然不存在数值为123031的field，因此，需要在interface1key对应的哈希表中增加一条记录，该记录中field为123031，而123031对应的value则是零，那么在执行命令hincrbyinterface1key 1230311时，则是对interface1key的123031对应的value从零加一。

也就是说，当Redis服务器的系统时间已经超过12点30分30秒这一秒，进入到了12点30分31秒，则12点30分31秒对应的value则从零自增，每次加一。

若所述Redis服务器的目标Key对应的哈希表中存在目标field，则所述Redis服务器对所述目标Key的哈希表中所述目标field对应的目标value从现有数值开始加一。

继续以业务接口1为例进行说明，例如Redis服务器的系统时间仍然在12点30分30秒这一秒内，该1秒还没有结束，则通过对Redis服务器中的存储数据进行查询可知，存在interface1key对应的field，即123030，那么可以对123030对应的value继续加一，这里即对1000加1，使得123030对应的value变为1001。

这样，本发明实施例通过在Redis服务器中设置Key-Value的存储结构，并使Value的数据类型为hash表，并对每个业务接口分配一个Key和对应的hash表，该hash表中的多个记录分别存储了每一秒该业务接口所接收到业务请求的统计量，那么通过这种方式来对各个业务接口在每一秒所接收到的业务请求的数量进行统计，可以准确的对并发请求量进行统计，从而便于后续的并发请求控制，并确保被访问资源的原子性。

步骤102，判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；

其中，如图1的实施例所述，本发明实施例的方法可以对各个业务接口分配配置QPS阈值，也即每个业务接口在一秒内所能够响应的业务请求的最大数量，那么各个业务接口在每一秒内对一个业务请求接收后，本发明实施例的方法都可以对相应业务接口的QPS指标进行数量自增，并该业务接口的这一秒内自增后的QPS指标与该业务接口的QPS阈值进行比较，判断自增后的QPS指标是否超过该业务接口的QPS阈值。

步骤103，在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的业务请求禁止执行后续的业务逻辑。

那么如果自增后的该业务接口的QPS指标(即业务请求的统计量)超过了对该业务接口所配置的QPS阈值，即说明该业务接口在该秒内所接收到的业务请求的总量已经超过该业务接口所能响应的最大数量。因此，业务服务器在接收到来自Redis服务器的第一预设错误信息后，可以对所述业务接口当前接收到的业务请求禁止执行后续的业务逻辑，例如禁止下单处理。

该Redis服务器可以返回第一预设错误信息(例如-1)至该业务接口所对应的业务服务器，从而使得该业务服务器对当前接收到的业务请求禁止执行后续的业务逻辑，例如该业务接口为下单接口，则业务服务器可以对该业务接口的下单请求禁止执行下单逻辑，避免订单量超过商品库存量的问题。

在实施方式一中，在执行步骤103时，若所述目标value超过与所述目标Key对应的业务接口的预设QPS阈值，则所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器。

举例来说，例如对业务接口1预先配置的QPS阈值为1000，那么经过实施方式一，对interface1key的hash表中的123030对应的value加一操作后，使得value从1000变为1001，则该目标value的数值1001已经超过了业务接口1的预设QPS阈值1000，则所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器。

在一种可能的实施方式中，所述若所述目标value超过与所述目标Key对应的业务接口的预设QPS阈值，则所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器之后，根据本发明实施例的方法还可以包括：

若所述业务接口再次接收到一个业务请求、且再次接收到的业务请求的接收时间点对应的field与所述目标field相同，则所述Redis服务器返回第二预设错误信息至所述业务接口对应的业务服务器。

其中，第二预设错误信息用于表示对所述业务接口当前接收到的业务请求拒绝响应，因此，业务服务器在接收到来自Redis服务器的第二预设错误信息后，可以对所述业务接口在这一秒内再次接收到的业务请求拒绝响应。

继续上述实施例来进行说明，经过上述自增操作后，业务接口1的hash表中field数值为123030对应的value由1000变为1001，即该业务接口1在123030这一秒内的业务请求量已经超过上限，但是该12点30分30秒这一秒还没有结束，即，当前时间还在该12点30分30秒这一秒内，没有进入下一秒，而该业务接口1又接收到了一个业务请求，则针对这一秒内已经超限的业务接口，该Redis服务器会返回第二预设错误信息(例如错误代码400)至该业务接口1对应的业务服务器，来使业务服务器对该业务接口当前收到的业务请求拒绝响应。

其中，在对再次接收到的业务请求的field的确定方式上与上述实施例的目标field的确定方式类似，也是按照业务请求的接收时间点来计算，具体参照上文，这里不再赘述。

这样，本发明实施例针对某一秒内的业务请求量已经超过该业务接口在该秒内的QPS阈值的情况，如果在该一秒内该业务接口继续接收到业务请求，则本发明实施例的方法可以直接使业务服务器拒绝对该业务请求的执行，即响应，避免对流量已经超限的业务接口继续接收到的流量继续进行响应，很好地对高并发的业务请求进行应对，并确保了该业务接口对应的被访问的业务资源的原子化，避免系统紊乱和宕机。

在一种可能的实施方式中，所述若所述目标value超过与所述目标Key对应的业务接口的预设QPS阈值，则所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器之后，根据本发明实施例的方法还可以包括：

所述Redis服务器按照预设时间周期对目标哈希表中的数据进行清除，其中，所述目标哈希表为field对应的接收时间点位于当前时间点之前的哈希表。

继续参照表1，本发明实施例的Redis服务器侧可以预设设置清除内存数据的时间周期，例如该时间周期T为2秒，那么Redis可以每两秒对过期的field以及对应的字段值中的数据进行清除，例如当前时间点为12点30分32秒，上一次清理内存是12点30分30秒，那么Redis服务器中内存存储的数据如表1所示，分别存储了业务接口1和业务接口2在12点30分30秒和12点30分31秒这两秒的业务请求统计量。

显然，12点30分30秒和12点30分31秒相对于当前时间12点30分32秒已经过期，因此，这里可以将表1中针对interface1key的hash表中field的数值123030以及对应的value的数值1000均清除，针对interface1key的hash表中field的数值123031以及对应的value的数值1均清除；针对interface2key的hash表中field的数值123030以及对应的value的数值2500均清除，针对interface2key的hash表中field的数值123031以及对应的value的数值3000均清除。

这样，通过定时的将过期的field数值以及对应的业务请求统计量value数值清除，可以确保Redis服务器的内存不会膨胀，减小Redis服务器的系统压力以及Lua脚本的计数压力，提高分布式环境下流量限制的效率。

在一种可能的实施方式中，根据本发明实施例的方法还可以包括：

Redis服务器实时从业务服务器接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值；

所述Redis服务器采用所述更新后的预设QPS阈值对相应业务接口的预设QPS阈值进行更新。

也就是说，在上述实施例中对于Redis服务器在判断各个业务接口在某一秒内的业务请求的接收总量是否超过限值时，该限值是由Zookeeper通过业务服务器发送给Redis服务器的，具体参照图1所示实施例中关于Zookeeper的描述。

由于各个业务接口所配置的QPS阈值是随时可以人工修改的，因此Zookeeper可以实时的将发生更新的QPS阈值发送至Redis服务器，这样，Redis服务器可以及时的知晓哪些业务接口的预设QPS阈值发生了变化以及变化后的新的QPS阈值。Redis服务器就可以采用该更新后的预设QPS阈值来对相应业务接口的预设QPS阈值进行更新。

例如，用户在12点30分31秒对业务接口1的预设QPS阈值由2000修改为3000，则Redis服务器接收了业务接口1的最新的预设QPS阈值为3000，并将本地的关于业务接口1的预设QPS阈值从2000修改为3000，这些处理的时间都是毫秒级的，所占用的时间相对于接收业务请求的时间可以忽略。

那么如果在12点30分31秒，该业务接口1接收到了业务请求，则Redis服务器可以对interface1key的hash表进行修改，具体为对interface1key的hash表中的field为123031对应的value的数值1加1，使得该value修改为2，在修改value后，在与该业务接口1的预设QPS阈值进行比较时，则是与3000进行比较，而非之前的2000。

这样，本发明实施例的Redis服务器通过实时接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值，并采用更新后的预设QPS阈值来对相应业务接口的QPS阈值进行更新，那么当Redis服务器在对各个业务接口的每一秒的业务请求的接收量进行统计后，与对应业务接口的预设QPS阈值进行比较时，可以与该业务接口的最新的QPS阈值进行比较。而由于QPS阈值的更新数值是根据实际应用场景的并发量和系统性能而调整的，那么针对同一个业务接口，通过不同秒之间的预设QPS阈值存在差异，可以使得业务系统性能达到最优，在每一秒都能够以最佳性能来处理并发的业务请求。

借助于本发明上述实施例的技术方案，本发明实施例利用Redis服务器的单线程模型的特点，使Redis服务器对业务接口进行监控，在业务接口接收到一个业务请求的情况下，Redis服务器就可以对该业务接口的QPS指标进行数量自增，并预先设置对各个业务接口的QPS阈值；那么如果数量自增后的某个业务接口的QPS指标超过对应该业务接口的QPS阈值，则返回错误信息至该业务接口对应的业务服务器，实现了分布式流量的控制，对高并发的业务请求的及时应对，并确保了被访问的业务资源的原子化。

在一种可能的实施方式中，Lua脚本中在判断某个业务接口的QPS指标超过该业务接口的预设QPS阈值之后，可以将该业务接口处于预警状态的信息发送给前端接入层；在前端接入层再次接收到向该业务接口发送的业务请求时，可以将业务请求转发至其他机器(可以理解与该业务接口功能相同的另一个业务接口)进行处理。由于是原子性的，可以保证并发下的准确性。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

与上述本发明实施例所提供的方法相对应，参照图3，示出了本发明一种业务请求的控制装置20实施例的结构框图，应用于Redis服务器200，该装置具体可以包括如下模块：

自增模块21，用于在业务接口接收到一个业务请求时，对所述业务接口对应的QPS指标进行数量自增；

判断模块22，用于判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；

第一返回模块23，用于在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的业务请求禁止执行后续的业务逻辑。

在一种可能的实施方式中，所述Redis服务器200采用键(Key)-值(Value)存储每个业务接口的QPS数值，其中，所述Redis服务器200预先为每个业务接口分配一个Key(键)，每个Key对应的Value(值)用于存储对应业务接口的QPS数值，其中，所述Value的数据类型为哈希表，所述哈希表为field(字段)与value(字段值)的映射表；

所述自增模块21包括：

确定子模块，用于在业务接口接收到一个业务请求时，确定所述业务接口对应的目标Key(即目标键)、以及所述业务请求的接收时间点，其中，所述接收时间点的最小时间单位为秒；

计算子模块，用于根据所述接收时间点计算所述目标Key的目标field(即目标字段)；

自增子模块，用于对所述目标Key的哈希表中所述目标field对应的目标value(即目标字段值)加一；

所述第一返回模块23，还用于若所述目标value超过与所述目标Key对应的业务接口的预设QPS阈值，则返回第一预设错误信息至所述业务接口对应的业务服务器。

在一种可能的实施方式中，所述自增子模块包括：

第一自增单元，用于若所述Redis服务器200的目标Key对应的哈希表中不存在目标field，则对所述目标Key的哈希表添加目标field，并对所述目标field对应的目标value从零开始加一；

第二自增单元，用于若所述Redis服务器200的目标Key对应的哈希表中存在目标field，则对所述目标Key的哈希表中所述目标field对应的目标value从现有数值开始加一。

在一种可能的实施方式中，所述装置还包括：

第二返回模块，用于若所述业务接口再次接收到一个业务请求、且再次接收到的业务请求的接收时间点对应的field与所述目标field相同，则返回第二预设错误信息至所述业务接口对应的业务服务器，其中，第二预设错误信息用于表示对所述业务接口当前接收到的业务请求拒绝响应。

在一种可能的实施方式中，所述装置还包括：

清除模块，用于按照预设时间周期对目标哈希表中的数据进行清除，其中，所述目标哈希表为field对应的接收时间点位于当前时间点之前的哈希表。

在一种可能的实施方式中，所述自增模块21，还用于在业务接口接收到一个业务请求时，采用Lua脚本对所述业务接口对应所述QPS指标进行数量自增。

在一种可能的实施方式中，所述装置还包括：

接收模块，用于实时从业务服务器接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值；

更新模块，用于采用所述更新后的预设QPS阈值对相应业务接口的预设QPS阈值进行更新。

借助于本发明上述实施例的技术方案，本发明实施例利用Redis服务器的单线程模型的特点，使Redis服务器对业务接口进行监控，在业务接口接收到一个业务请求的情况下，Redis服务器就可以对该业务接口的QPS指标进行数量自增，并预先设置对各个业务接口的QPS阈值；那么如果数量自增后的某个业务接口的QPS指标超过对应该业务接口的QPS阈值，则返回错误信息至该业务接口对应的业务服务器，实现了分布式流量的控制，对高并发的业务请求的及时应对，并确保了被访问的业务资源的原子化。

根据本发明的一个实施例，还提供了一种Redis服务器。

该Redis服务器包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的业务请求的控制程序，所述业务请求的控制程序被所述处理器执行时实现如上述任意一个实施例所述的业务请求的控制方法的步骤。

根据本发明的一个实施例，还提供了一种计算机可读存储介质。

该计算机可读存储介质上存储有业务请求的控制程序，所述业务请求的控制程序被处理器执行时实现如述任意一个实施例所述的业务请求的控制方法中的步骤。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种业务请求的控制方法和一种业务请求的控制装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (14)

1.一种业务请求的控制方法，其特征在于，包括：

在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增；

判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；其中，所述预设QPS阈值被配置为所述业务接口在一秒内能够响应的业务请求的最大数量，所述业务请求为访问有限的业务资源的请求；

在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的所述业务请求禁止执行后续的业务逻辑；

其中，在所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器的步骤之后，所述方法还包括：

所述Redis服务器将所述业务接口处于预警状态的信息发送至前端接入层；

在所述前端接入层再次接收到向所述业务接口发送的业务请求时，将所述业务请求发送至其他业务接口进行处理；

所述方法还包括：

所述Redis服务器实时从业务服务器接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值；

所述Redis服务器采用所述更新后的预设QPS阈值对相应业务接口的预设QPS阈值进行更新。

2.根据权利要求1所述的方法，其特征在于，所述Redis服务器采用键-值存储每个业务接口的QPS数值，其中，所述Redis服务器预先为每个业务接口分配一个键，每个键对应的值用于存储对应业务接口的QPS数值，其中，所述值的数据类型为哈希表，所述哈希表为字段与字段值的映射表；

所述在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增，包括：

在业务接口接收到一个业务请求时，Redis服务器确定所述业务接口对应的目标键、以及所述业务请求的接收时间点，其中，所述接收时间点的最小时间单位为秒；

所述Redis服务器根据所述接收时间点计算所述目标键的目标字段；

所述Redis服务器对所述目标键的哈希表中所述目标字段对应的目标字段值加一；

所述在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器，包括：

在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器。

3.根据权利要求2所述的方法，其特征在于，所述Redis服务器对所述目标键的哈希表中所述目标字段对应的目标字段值加一，包括：

在所述Redis服务器的目标键对应的哈希表中不存在目标字段时，所述Redis服务器对所述目标键的哈希表添加目标字段，并对所述目标字段对应的目标字段值从零开始加一；

在所述Redis服务器的目标键对应的哈希表中存在目标字段时，所述Redis服务器对所述目标键的哈希表中所述目标字段对应的目标字段值从现有数值开始加一。

4.根据权利要求2所述的方法，其特征在于，所述在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器之后，所述方法还包括：

在所述业务接口再次接收到一个业务请求、且再次接收到的业务请求的接收时间点对应的字段与所述目标字段相同时，所述Redis服务器返回第二预设错误信息至所述业务接口对应的业务服务器，其中，第二预设错误信息用于表示对所述业务接口当前接收到的业务请求拒绝响应。

5.根据权利要求2所述的方法，其特征在于，所述在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，所述Redis服务器返回第一预设错误信息至所述业务接口对应的业务服务器之后，所述方法还包括：

所述Redis服务器按照预设时间周期对目标哈希表中的数据进行清除，其中，所述目标哈希表为字段对应的接收时间点位于当前时间点之前的哈希表。

6.根据权利要求1所述的方法，其特征在于，所述在业务接口接收到一个业务请求时，Redis服务器对所述业务接口对应的QPS指标进行数量自增，包括：

在业务接口接收到一个业务请求时，Redis服务器采用Lua脚本对所述业务接口对应所述QPS指标进行数量自增。

7.一种业务请求的控制装置，其特征在于，应用于Redis服务器，所述控制装置包括：

自增模块，用于在业务接口接收到一个业务请求时，对所述业务接口对应的QPS指标进行数量自增；

判断模块，用于判断数量自增后的所述业务接口对应的QPS指标是否超过所述业务接口的预设QPS阈值；其中，所述预设QPS阈值被配置为所述业务接口在一秒内能够响应的业务请求的最大数量，所述业务请求为访问有限的业务资源的请求；

第一返回模块，用于在数量自增后的所述业务接口对应的QPS指标超过所述业务接口的预设QPS阈值时，返回第一预设错误信息至所述业务接口对应的业务服务器，其中，第一预设错误信息用于表示对所述业务接口当前接收到的所述业务请求禁止执行后续的业务逻辑；

其中，所述第一返回模块，还用于：

将所述业务接口处于预警状态的信息发送至前端接入层；

在所述前端接入层再次接收到向所述业务接口发送的业务请求时，将所述业务请求发送至其他业务接口进行处理；

所述装置还包括：

接收模块，用于实时从业务服务器接收来自Zookeeper的针对每个业务接口的更新后的预设QPS阈值；

更新模块，用于采用所述更新后的预设QPS阈值对相应业务接口的预设QPS阈值进行更新。

8.根据权利要求7所述的装置，其特征在于，所述Redis服务器采用键-值存储每个业务接口的QPS数值，其中，所述Redis服务器预先为每个业务接口分配一个键，每个键对应的值用于存储对应业务接口的QPS数值，其中，所述值的数据类型为哈希表，所述哈希表为字段与字段值的映射表；

所述自增模块包括：

确定子模块，用于在业务接口接收到一个业务请求时，确定所述业务接口对应的目标键、以及所述业务请求的接收时间点，其中，所述接收时间点的最小时间单位为秒；

计算子模块，用于根据所述接收时间点计算所述目标键的目标字段；

自增子模块，用于对所述目标键的哈希表中所述目标字段对应的目标字段值加一；

所述第一返回模块，还用于在所述目标字段值超过与所述目标键对应的业务接口的预设QPS阈值时，返回第一预设错误信息至所述业务接口对应的业务服务器。

9.根据权利要求8所述的装置，其特征在于，所述自增子模块包括：

第一自增单元，用于在所述Redis服务器的目标键对应的哈希表中不存在目标字段时，对所述目标键的哈希表添加目标字段，并对所述目标字段对应的目标字段值从零开始加一；

第二自增单元，用于在所述Redis服务器的目标键对应的哈希表中存在目标字段时，对所述目标键的哈希表中所述目标字段对应的目标字段值从现有数值开始加一。

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

第二返回模块，用于在所述业务接口再次接收到一个业务请求、且再次接收到的业务请求的接收时间点对应的字段与所述目标字段相同时，返回第二预设错误信息至所述业务接口对应的业务服务器，其中，第二预设错误信息用于表示对所述业务接口当前接收到的业务请求拒绝响应。

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

清除模块，用于按照预设时间周期对目标哈希表中的数据进行清除，其中，所述目标哈希表为字段对应的接收时间点位于当前时间点之前的哈希表。

12.根据权利要求7所述的装置，其特征在于，

所述自增模块，还用于在业务接口接收到一个业务请求时，采用Lua脚本对所述业务接口对应所述QPS指标进行数量自增。

13.一种Redis服务器，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的业务请求的控制程序，所述业务请求的控制程序被所述处理器执行时实现如权利要求1至6中任一项所述的业务请求的控制方法的步骤。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有业务请求的控制程序，所述业务请求的控制程序被处理器执行时实现如权利要求1至6中任一项所述的业务请求的控制方法中的步骤。

Images