CN116074384B - 一种控制业务请求数量的方法及系统 - Google Patents

Abstract

本发明的实施例公开了一种控制业务请求数量的方法及系统，方法包括：接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制；若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝；若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求。系统包括：业务请求模块，限制服务模块，业务请求处理模块和负载实时监测模块。本发明主要针对业务系统中的请求调用控制，实现简单，方便集成，容易嵌入已有业务中，对于中小型项目的请求数量控制需求具有良好的适用性。

Description

一种控制业务请求数量的方法及系统

技术领域

本发明涉及互联网、分布式服务技术领域，特别涉及一种控制业务请求数量的方法及系统。

背景技术

在分布式服务系统中，若上游服务在短时间内向下游服务发出大量的业务请求，那么可能会导致下游服务负载过大，对服务器资源造成冲击。对服务之间的业务请求数量进行定量的控制，能有效的避免由于请求量过载导致的服务崩溃问题，从而提升服务的健壮性。

早期业务简单，可能没有对服务之间的请求数量进行控制。随着业务的迭代，复杂度的提升，业务之间相互调用越来越频繁，对业务请求数量进行控制显得越发重要。

现有的技术中，对业务请求数量的控制的方法主要有两种：第一种为基于时间窗口的请求量控制，通过获取当前时间窗口的请求量信息，根据请求量信息从额度分配服务器获得当前请求量额度。当前请求量额度由每个业务服务器上报的请求量动态分配。该种方式，需要一个功能复杂的额度分配服务，且该方式更适用于复杂的面向前端的网关系统的访问控制。第二种为基于限流熔断服务的请求量控制，根据限流服务统计的当前业务服务的负载情况，且根据不同业务服务的重要程度，为业务服务限制可接收的请求数量。同样，该种方式适合于大型的业务系统。这些方法均缺少对中小型业务在快速集成服务之间请求数量控制的功能需求的考虑。

发明内容

有鉴于此，本发明实施例的目的在于提供一种控制业务请求数量的方法及系统，主要针对业务系统中的请求调用控制，实现简单，方便集成，容易嵌入已有业务中，对于中小型项目的请求数量控制需求具有良好的适用性。

第一方面，本发明实施例提供了一种控制业务请求数量的方法，其中，包括：

接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制。

若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝。

若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，所述获取redis请求限制服务包括：

预设redis请求时间T，在请求时间T内，本次业务请求的每条数据均持续循环遍历，直至获取到redis锁。

建立有序集合，记录所有业务请求。

从有序集合中删除超时未回复请求的数据。

统计有序集合中已放行数据的数量，判断已放行数据的数量是否超过请求数量限制的数量上限，若超过上限，则对超出的数据持续循环获取redis锁。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，若未超过请求数量限制的数量上限，则将本次业务请求添加到有序集合中，元素类型记为已放行未回复，元素item为请求信息，元素score为当前时间戳。

结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，将本次业务请求发送到下游服务后，通知下游服务通过RPC接口回调请求限制器，将本次业务请求从有序集合中删除。

结合第一方面，本发明实施例提供了第一方面的第四种可能的实施方式，其中，还包括：

实时监测是否发生上游服务负载变化事件或下游服务负载变化，若发生上游服务负载变化事件或下游服务负载变化，则获取负载调整服务。

结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，所述负载调整服务包括：

生成负载信息，所述负载信息包括业务请求类型、当前业务请求类型对应的负载值和当前最大负载限额。

当前最大负载限额为上游服务负载限额和下游服务负载限额中的较小值。

上游服务负载限额根据当前启动的上游服务器数量和每台上游服务器的处理数量上限生成。

下游服务负载限额根据当前启动的下游服务器数量和每台下游服务器的处理数量上限生成。

根据所述负载信息，计算得到当前业务请求类型的请求数量上限。

将修改后的请求数量上限发送下游服务和上游服务。

第二方面，本发明实施例还提供了一种控制业务请求数量的系统，其中，包括：

业务请求模块，用于接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制。

限制服务模块，用于若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝。

业务请求处理模块，用于若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求。

负载实时监测模块，用于实时监测是否发生上游服务负载变化事件或下游服务负载变化，若发生上游服务负载变化事件或下游服务负载变化，则获取负载调整服务。

结合第二方面，本发明实施例提供了第二方面的第一种可能的实施方式，其中，所述限制服务模块包括：

redis锁获取单元，用于预设redis请求时间T，在请求时间T内，本次业务请求的每条数据均持续循环遍历，直至获取到redis锁。

有序集合建立单元，用于建立有序集合，记录所有业务请求。

未回复请求删除单元，用于从有序集合中删除超时未回复请求的数据。

数量上限判断单元，用于统计有序集合中已放行数据的数量，判断已放行数据的数量是否超过请求数量限制的数量上限，若超过上限，则对超出的数据持续循环获取redis锁。

结合第二方面，本发明实施例提供了第二方面的第二种可能的实施方式，其中，所述业务请求处理模块包括：

调用单元，用于将本次业务请求发送到下游服务后，通知下游服务通过RPC接口回调请求限制器。

完成请求删除单元，用于将本次业务请求从有序集合中删除。

结合第二方面，本发明实施例提供了第二方面的第三种可能的实施方式，其中，所述负载实时监测模块包括：

负载信息生成单元，用于生成负载信息，所述负载信息包括业务请求类型、当前业务请求类型对应的负载值和当前最大负载限额，当前最大负载限额为上游服务负载限额和下游服务负载限额中的较小值，上游服务负载限额根据当前启动的上游服务器数量和每台上游服务器的处理数量上限生成，下游服务负载限额根据当前启动的下游服务器数量和每台下游服务器的处理数量上限生成。

请求数量上限计算单元，用于根据所述负载信息，计算得到当前业务请求类型的请求数量上限。

请求数量上限传输单元，用于将修改后的请求数量上限发送下游服务和上游服务。

本发明实施例的有益效果是：

本发明获取Redis请求限制服务时采用循环等待的方式，请求限制服务获取成功之后，业务请求发送之前将请求信息放置到已放行未回复集合中，下游服务接收到请求之后通过RPC回调将请求限制服务中该请求删除。其中超时未回复的请求，则获取请求限制服务时会将记录删除，及时回收请求限制数量，防止请求无法下发，影响业务运行。本发明考虑到中小型业务在快速集成服务之间请求数量控制的功能需求，通过redis实现简单易用的请求数量控制功能。针对中小型业务系统做简单的请求数量控制功能，且对复杂系统的流程调用控制也可实现，实现简单，方便集成到当前业务代码中。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明控制业务请求数量的方法的流程图；

图2为本发明控制业务请求数量的方法中redis请求限制服务的流程图；

图3为本发明控制业务请求数量的方法中下游服务接收并执行本次业务请求的流程图；

图4为本发明控制业务请求数量的方法中负载调整服务的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件能够以各种不同的配置来布置和设计。

请参照图1，本发明的第一个实施例提供一种控制业务请求数量的方法，包括：

S100，接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制。

S200，若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝。

S300，若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求。

具体的，如图2所示，所述获取redis请求限制服务包括：

预设redis请求时间T，在请求时间T内，本次业务请求的每条数据均持续循环遍历，直至获取到redis锁。

其中，所述redis锁为并发控制锁，锁的数据结构为redis的String结构，获取方式为在redis中设置成功一个String结构的键值对。主要获取流程为：

(1)在请求时间T内，持续尝试设置key-value键值对，若设置成功，则代表锁获取成功；若key-value键值对在请求时间T内未设置成功，则获取锁失败。

(2)获取锁成功则继续往下执行，获取锁失败则持续循环获取。

建立有序集合，记录所有业务请求。

从有序集合中删除超时未回复请求的数据。

统计有序集合中已放行数据的数量，判断已放行数据的数量是否超过请求数量限制的数量上限，若超过上限，则对超出的数据持续循环获取redis锁。

其中，若未超过请求数量限制的数量上限，则将本次业务请求添加到有序集合中，元素类型记为已放行未回复，元素item为请求信息，元素score为当前时间戳。

其中，元素item在C语言中用于表示索引的对象。

其中，元素score在C语言中用于标识。

具体的，如图3所示，将本次业务请求发送到下游服务后，通知下游服务通过RPC接口回调请求限制器，将本次业务请求从有序集合中删除。

其中，RPC回调接口的执行过程为：

(1)接收到下游服务的回调请求。

(2)根据上报的服务请求信息，将有序集合中该业务请求信息删除，即释放业务控制数量。

其中，还包括：

S400，实时监测是否发生上游服务负载变化事件或下游服务负载变化，若发生上游服务负载变化事件或下游服务负载变化，则获取负载调整服务。

具体的，如图4所示，其中，所述负载调整服务包括：

S401，生成负载信息，所述负载信息包括业务请求类型、当前业务请求类型对应的负载值和当前最大负载限额。

S402，当前最大负载限额为上游服务负载限额和下游服务负载限额中的较小值。

S403，上游服务负载限额根据当前启动的上游服务器数量和每台上游服务器的处理数量上限生成。

S404，下游服务负载限额根据当前启动的下游服务器数量和每台下游服务器的处理数量上限生成。

S405，根据所述负载信息，计算得到当前业务请求类型的请求数量上限。

S406，将修改后的请求数量上限发送下游服务和上游服务。

本发明的第二个实施例提供一种控制业务请求数量的系统，其中，包括：

业务请求模块，用于接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制。

限制服务模块，用于若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝。

业务请求处理模块，用于用于若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求。

负载实时监测模块，用于实时监测是否发生上游服务负载变化事件或下游服务负载变化，若发生上游服务负载变化事件或下游服务负载变化，则获取负载调整服务。

其中，所述限制服务模块包括：

redis锁获取单元，用于预设redis请求时间T，在请求时间T内，本次业务请求的每条数据均持循环续遍历，直至获取到redis锁。

有序集合建立单元，用于建立有序集合，记录所有业务请求。

未回复请求删除单元，用于从有序集合中删除超时未回复请求的数据。

数量上限判断单元，用于统计有序集合中已放行数据的数量，判断已放行数据的数量是否超过请求数量限制的数量上限，若超过上限，则对超出的数据持续循环获取redis锁。

其中，所述业务请求处理模块包括：

调用单元，用于将本次业务请求发送到下游服务后，通知下游服务通过RPC接口回调请求限制器。

完成请求删除单元，用于将本次业务请求从有序集合中删除。

其中，所述负载实时监测模块包括：

负载信息生成单元，用于生成负载信息，所述负载信息包括业务请求类型、当前业务请求类型对应的负载值和当前最大负载限额，当前最大负载限额为上游服务负载限额和下游服务负载限额中的较小值，上游服务负载限额根据当前启动的上游服务器数量和每台上游服务器的处理数量上限生成，下游服务负载限额根据当前启动的下游服务器数量和每台下游服务器的处理数量上限生成。

请求数量上限计算单元，用于根据所述负载信息，计算得到当前业务请求类型的请求数量上限。

请求数量上限传输单元，用于将修改后的请求数量上限发送下游服务和上游服务。

本发明实施例旨在保护一种控制业务请求数量的方法及系统，具备如下效果：

1.本发明考虑到中小型业务在快速集成服务之间请求数量控制的功能需求，通过redis实现简单易用的请求数量控制功能。针对中小型业务系统做简单的请求数量控制功能，且对复杂系统的流程调用控制也可实现，实现简单，方便集成到当前业务代码中。

2.本发明设有实时监测负载变化，根据实时服务器数量，及时更新调整请求数量上限，根据能够实时负载信息确定是否限流，提高了限流控制的精准度。

3.本发明的请求限制数量、超时时间等常量可基于配置文件进行配置，亦可用其他方式动态获取。

4.本发明针对业务系统中的请求调用控制，实现简单，方便集成，容易嵌入已有业务中，对于中小型项目的请求数量控制需求具有良好的适用性。

本发明实施例所提供的控制业务请求数量的方法及装置的计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行前面方法实施例中的方法，具体实现可参见方法实施例，在此不再赘述。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述控制业务请求数量的方法，从而能够实现简单，方便集成，容易嵌入已有业务中，对于中小型项目的请求数量控制需求具有良好的适用性。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (5)

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

接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制；

若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝；

若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求；

所述redis请求限制服务包括：

预设redis请求时间T，在请求时间T内，本次业务请求的每条数据均持续循环遍历，直至获取到redis锁；

建立有序集合，记录所有业务请求；

从有序集合中删除超时未回复请求的数据；

统计有序集合中已放行数据的数量，判断已放行数据的数量是否超过请求数量限制的数量上限，若超过上限，则对超出的数据持续循环获取redis锁；

若未超过请求数量限制的数量上限，则将本次业务请求添加到有序集合中，元素类型记为已放行未回复，元素item为请求信息，元素score为当前时间戳；

将本次业务请求发送到下游服务后，通知下游服务通过RPC接口回调请求限制器；

将本次业务请求从有序集合中删除。

2.根据权利要求1所述的控制业务请求数量的方法，其特征在于，还包括：

实时监测是否发生上游服务负载变化事件或下游服务负载变化，若发生上游服务负载变化事件或下游服务负载变化，则获取负载调整服务。

3.根据权利要求2所述的控制业务请求数量的方法，其特征在于，所述负载调整服务包括：

生成负载信息，所述负载信息包括业务请求类型、当前业务请求类型对应的负载值和当前最大负载限额；

当前最大负载限额为上游服务负载限额和下游服务负载限额中的较小值；

上游服务负载限额根据当前启动的上游服务器数量和每台上游服务器的处理数量上限生成；

下游服务负载限额根据当前启动的下游服务器数量和每台下游服务器的处理数量上限生成；

根据所述负载信息，计算得到当前业务请求类型的请求数量上限；

将修改后的请求数量上限发送下游服务和上游服务。

4.一种控制业务请求数量的系统，其特征在于，包括：

业务请求模块，用于接收上游服务新增的业务请求，判断所述业务请求是否需要进行请求数量限制；

限制服务模块，用于若需要进行请求数量限制，则获取redis请求限制服务，对未超出数量上限的业务请求进行放行，对超出数量上限的业务请求进行拒绝；

业务请求处理模块，用于若未超出数量上限，则继续处理本次业务请求，将本次业务请求发送到下游服务，以使得下游服务接收并执行本次业务请求；

负载实时监测模块，用于实时监测是否发生上游服务负载变化事件或下游服务负载变化，若发生上游服务负载变化事件或下游服务负载变化，则获取负载调整服务；

所述限制服务模块包括：

redis锁获取单元，用于预设redis请求时间T，在请求时间T内，本次业务请求的每条数据均持续循环遍历，直至获取到redis锁；

有序集合建立单元，用于建立有序集合，记录所有业务请求；

未回复请求删除单元，用于从有序集合中删除超时未回复请求的数据；

数量上限判断单元，用于统计有序集合中已放行数据的数量，判断已放行数据的数量是否超过请求数量限制的数量上限，若超过上限，则对超出的数据持续循环获取redis锁；

所述业务请求处理模块包括：

调用单元，用于将本次业务请求发送到下游服务后，通知下游服务通过RPC接口回调请求限制器；

完成请求删除单元，用于将本次业务请求从有序集合中删除。

5.根据权利要求4所述的控制业务请求数量的系统，其特征在于，所述负载实时监测模块包括：

负载信息生成单元，用于生成负载信息，所述负载信息包括业务请求类型、当前业务请求类型对应的负载值和当前最大负载限额，当前最大负载限额为上游服务负载限额和下游服务负载限额中的较小值，上游服务负载限额根据当前启动的上游服务器数量和每台上游服务器的处理数量上限生成，下游服务负载限额根据当前启动的下游服务器数量和每台下游服务器的处理数量上限生成；

请求数量上限计算单元，用于根据所述负载信息，计算得到当前业务请求类型的请求数量上限；

请求数量上限传输单元，用于将修改后的请求数量上限发送下游服务和上游服务。