应用请求处理方法、装置、电子设备及可读存储介质与流程

本申请涉及服务器，特别涉及一种应用请求处理方法、装置、电子设备及计算机可读存储介质。

背景技术：

1、随着互联网的快速发展，基于互联网的应用产品也越来越融入人们的生活。通常情况下，可以采用客户端和服务器结构的应用系统来实现这些应用产品的功能，具体为：用户通过客户端向服务器发送应用功能对应的应用请求，然后由服务器反馈请求处理结果。然而，服务器是为广大用户提供应用服务的，当服务器接入的客户端数量过多，或者客户端发起的应用请求数量过多时，网络带宽压力骤增，其稳定性无法得到有效保证。

2、因此，如何有效缓解应用请求处理过程中的带宽压力是本领域技术人员亟待解决的问题。

技术实现思路

1、本申请的目的是提供一种应用请求处理方法，该应用请求处理方法可以在应用请求处理过程中有效降低网络带宽压力；本申请的另一目的是提供一种应用请求处理装置、电子设备及计算机可读存储介质，均具有上述有益效果。

2、第一方面，本申请提供了一种应用请求处理方法，包括：

3、接收应用请求；

4、根据请求下发比判断所述应用请求是否通过，所述请求下发比根据服务端的最大请求通过数量和单位时间预估请求数量确定，所述请求下发比用于使得所述服务端的实际请求通过数量不超过所述最大请求通过数量；

5、若通过，则放行所述应用请求；

6、对所述应用请求进行下发处理，以实现应用请求处理。

7、可选地，所述请求下发比为所述最大请求通过数量和所述单位时间预估请求数量的比值；

8、所述最大请求通过数量为所述服务端允许放行的应用请求的最大数量；

9、所述单位时间预估请求数量为所述服务端在单位时间内接收的应用请求的预估数量。

10、可选地，所述最大请求通过数量为最大请求下发数量与历史请求下发比的比值；

11、所述最大请求下发数量根据所述服务端的性能数据确定。

12、可选地，所述单位时间预估请求数量为上一单位时间请求数量和单位时间请求变化数量的加和；

13、所述上一单位时间请求数量和所述单位时间请求变化数量根据所述服务端的历史请求数量确定。

14、可选地，所述根据请求下发比判断所述应用请求是否通过，包括：

15、生成预设范围内的随机数；

16、根据所述预设范围和所述请求下发比确定限流阈值；

17、当所述随机数不低于预设范围最小值且低于所述限流阈值时，确定所述应用请求通过；

18、当所述随机数不低于所述限流阈值且不超过预设范围最大值时，确定所述应用请求不通过。

19、可选地，所述对所述应用请求进行下发处理，以实现应用请求处理之前，还包括：

20、判断所述应用请求是否命中处理策略库；

21、若否，则拒绝所述应用请求。

22、可选地，当所述应用请求命中所述处理策略库时，所述方法还包括：

23、判断日志文件中是否存在所述应用请求命中的处理策略对应的下发日志；

24、若是，则在所述命中的处理策略对应的下发统计表中查询历史下发次数；

25、当所述历史下发次数超出预设下发额度时，拒绝所述应用请求。

26、可选地，当所述日志文件中不存在所述应用请求命中的处理策略对应的下发日志时，所述方法还包括：

27、在所述日志文件中创建所述应用请求命中的处理策略对应的下发日志；

28、相应地，所述对所述应用请求进行下发处理，以实现应用请求处理之后，还包括：

29、更新所述下发统计表中的历史下发次数。

30、可选地，所述根据请求下发比判断所述应用请求是否通过之前，还包括：

31、判断所述应用请求是否命中激活策略库；

32、若否，则执行所述根据请求下发比判断所述应用请求是否通过的步骤。

33、可选地，当所述应用请求命中所述激活策略库时，所述方法还包括：

34、确定命中的激活策略的激活数量；

35、当所述激活数量达到预设激活数量时，停止所述命中的激活策略；

36、当所述激活数量未达到所述预设激活数量时，更新所述激活数量。

37、可选地，所述确定命中的激活策略的激活数量之前，还包括：

38、判断是否存在所述应用请求对应的请求下发记录；

39、若否，则拒绝所述应用请求；

40、若是，则执行所述确定命中的激活策略的激活数量的步骤。

41、第二方面，本申请提供了一种应用请求处理装置，包括：

42、接收模块，用于接收应用请求；

43、判断模块，用于根据请求下发比判断所述应用请求是否通过，所述请求下发比根据服务端的最大请求通过数量和单位时间预估请求数量确定，所述请求下发用于使得所述服务端的实际请求通过数量不超过所述最大请求通过数量；

44、放行模块，用于若通过所述应用请求，则放行所述应用请求；

45、下发模块，用于对所述应用请求进行下发处理，以实现应用请求处理。

46、第三方面，本申请还公开了一种电子设备，包括：

47、存储器，用于存储计算机程序；

48、处理器，用于执行所述计算机程序时实现如上所述的任一种应用请求处理方法的步骤。

49、第四方面，本申请还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的任一种应用请求处理方法的步骤。

50、应用本申请所提供的技术方案，对于服务端而言，在应用请求处理过程中，可以根据自身的最大请求通过数量和单位时间预估请求数量进行计算，得到可以使得自身的实际请求通过数量不超过最大请求通过数量的请求下发比，由此，对于接收到的应用请求，即可直接利用该请求下发比来确定是否对其放行，并在确定允许放行时才会对该应用请求进行下发处理，从而完成应用请求处理。可见，该技术方案通过请求下发比对应用请求的处理数量进行了限制，有效地降低了带宽需求，减小了网络带宽压力。

技术特征：

1.一种应用请求处理方法，其特征在于，包括：

2.根据权利要求1所述的应用请求处理方法，其特征在于，所述请求下发比为所述最大请求通过数量和所述单位时间预估请求数量的比值；

3.根据权利要求2所述的应用请求处理方法，其特征在于，所述最大请求通过数量为最大请求下发数量与历史请求下发比的比值；

4.根据权利要求2所述的应用请求处理方法，其特征在于，所述单位时间预估请求数量为上一单位时间请求数量和单位时间请求变化数量的加和；

5.根据权利要求1所述的应用请求处理方法，其特征在于，所述根据请求下发比判断所述应用请求是否通过，包括：

6.根据权利要求1所述的应用请求处理方法，其特征在于，所述对所述应用请求进行下发处理，以实现应用请求处理之前，还包括：

7.根据权利要求6所述的应用请求处理方法，其特征在于，当所述应用请求命中所述处理策略库时，所述方法还包括：

8.根据权利要求7所述的应用请求处理方法，其特征在于，当所述日志文件中不存在所述应用请求命中的处理策略对应的下发日志时，所述方法还包括：

9.根据权利要求1所述的应用请求处理方法，其特征在于，所述根据请求下发比判断所述应用请求是否通过之前，还包括：

10.根据权利要求9所述的应用请求处理方法，其特征在于，当所述应用请求命中所述激活策略库时，所述方法还包括：

11.根据权利要求10所述的应用请求处理方法，其特征在于，所述确定命中的激活策略的激活数量之前，还包括：

12.一种应用请求处理装置，其特征在于，包括：

13.一种电子设备，其特征在于，包括：

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

技术总结
本申请公开了一种应用请求处理方法，包括：接收应用请求；根据请求下发比判断所述应用请求是否通过，所述请求下发比根据服务端的最大请求通过数量和单位时间预估请求数量确定，所述请求下发比用于使得所述服务端的实际请求通过数量不超过所述最大请求通过数量；若通过，则放行所述应用请求；对所述应用请求进行下发处理，以实现应用请求处理。应用本申请所提供的的技术方案，可以在应用请求处理过程中有效降低网络带宽压力。本申请还公开了一种应用请求处理装置、电子设备以及计算机可读存储介质，同样具有上述技术效果。

技术研发人员：宋环宇
受保护的技术使用者：深圳市迅雷网络技术有限公司
技术研发日：
技术公布日：2024/1/16