CN110661863A

CN110661863A - 一种请求处理方法、装置及电子设备和存储介质

Info

Publication number: CN110661863A
Application number: CN201910894855.6A
Authority: CN
Inventors: 史文学
Original assignee: Zheng Wei Yun Ltd
Current assignee: Zheng Wei Yun Ltd
Priority date: 2019-09-20
Filing date: 2019-09-20
Publication date: 2020-01-07
Anticipated expiration: 2039-09-20
Also published as: CN110661863B

Abstract

本申请公开了一种请求处理方法、装置及设备和介质，方法包括：当接收到用户请求后，确定用户请求对应的请求接口；基于请求接口判断是否需要对用户请求进行防重校验；若判定需要对用户请求进行防重校验，则获取用户请求的发起方的第一标识，并获取请求接口的第二标识；利用第一标识和第二标识判断预设缓存空间中是否存在与当前用户请求重复的请求记录；若预设缓存空间中存在与当前用户请求重复的请求记录，则禁止对当前用户请求进行响应。本申请将根据当前用户请求确定其对应的请求接口，基于上述请求接口确定是否需要对当前用户请求进行防重校验，无需依赖前端开发，对于已开发完成的系统，降低了对已有系统的侵入性以及接入成本。

Description

一种请求处理方法、装置及电子设备和存储介质

技术领域

本申请涉及计算机技术领域，更具体地说，涉及一种请求处理方法、装置及一种电子设备和一种计算机可读存储介质。

背景技术

同一个表单、同样的数据，如果多次提交，会给服务器造成不必要的压力，在平时项目中可能会出现由于用户误操作多次点击提交按钮，或由于网速等原因造成页面卡顿，用户重复刷新提交页面，会导致数据的重复提交，造成数据重复，增加服务器负载，严重情况下甚至会造成服务器宕机。因此有效防止重复提交时非常有必要的。

在传统技术中，针对防止重复提交，通常采用Token(令牌)机制，即当一个请求到达前端时，前端将一个Token放入该请求的session中，并将该Token传给提交页面，在提交时后端服务器会拦截该请求，并判断session保存的Token与提交的Token是否一致。若不一致或session中的Token为空，则禁止响应当前提交请求，从而实现防止重复提交。

然而，在上述技术方案中，前端需要传入指定的Token，后端在接收到请求后基于Token进行防重校验，也即，现有防重提交技术方案需要依赖于前后端双方的工作，且若在系统开发结束后需要为已有的系统添加防重提交功能时，需要修改系统的底层框架代码，对于系统的侵入性较大。

发明内容

本申请的目的在于提供一种请求处理方法、装置及一种电子设备和一种计算机可读存储介质，无需依赖前端开发，降低了对已有系统的侵入性以及接入成本。

为实现上述目的，本申请提供了一种请求处理方法，包括：

当接收到用户请求后，确定所述用户请求对应的请求接口；

基于所述请求接口判断是否需要对所述用户请求进行防重校验；

若判定需要对所述用户请求进行防重校验，则获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识；

利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录；

若所述预设缓存空间中存在与当前所述用户请求重复的请求记录，则禁止对当前所述用户请求进行响应。

可选的，所述基于所述请求接口判断是否需要对所述用户请求进行防重校验，包括：

判断所述请求接口是否预先添加注解；

如果是，则判定所述请求接口接收到的用户请求需要进行防重校验。

可选的，当接收到用户请求后，确定所述用户请求对应的请求接口，包括：

当接收到用户请求后，利用预先编写的Spring拦截器对所述用户请求进行拦截；

对所述用户请求进行解析，确定所述用户请求对应的请求接口。

可选的，所述获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识，包括：

确定所述用户请求中携带的请求参数，得到所述发起方对应的第一标识；

利用Java反射机制获取所述请求接口对应的Token。

可选的，所述利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录之后，还包括：

若所述预设缓存空间中未存在与当前所述用户请求重复的请求记录，则将所述第二标识存入当前所述用户请求对应的工作线程域中；

将所有所述工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录，并保存至所述预设缓存空间中。

可选的，还包括：

若监测到对当前所述用户请求的响应过程完成，则从当前所述用户请求对应的工作线程域中获取对应的第二标识；

利用所述第二标识在所述预设缓存空间中确定对应的请求记录并删除。

可选的，将所有所述工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录之后，还包括：

获取针对所述请求记录设定的有效时间；

若监测到在所述有效时间后所述请求记录仍存储在所述预设缓存空间中，则自动对所述请求记录进行删除。

为实现上述目的，本申请提供了一种请求处理装置，包括：

接口确定模块，用于当接收到用户请求后，确定所述用户请求对应的请求接口；

防重判断模块，用于基于所述请求接口判断是否需要对所述用户请求进行防重校验；

标识获取模块，用于若判定需要对所述用户请求进行防重校验，则获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识；

记录判断模块，用于利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录；

响应禁止模块，用于若所述预设缓存空间中存在与当前所述用户请求重复的请求记录，则禁止对当前所述用户请求进行响应。

为实现上述目的，本申请提供了一种电子设备，包括：

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

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

为实现上述目的，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述请求处理方法的步骤。

通过以上方案可知，本申请提供的一种请求处理方法，包括：当接收到用户请求后，确定所述用户请求对应的请求接口；基于所述请求接口判断是否需要对所述用户请求进行防重校验；若判定需要对所述用户请求进行防重校验，则获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识；利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录；若所述预设缓存空间中存在与当前所述用户请求重复的请求记录，则禁止对当前所述用户请求进行响应。由上可知，本申请在接收到用户请求后，将根据当前用户请求确定其对应的请求接口，并基于上述请求接口确定是否需要对当前用户请求进行防重校验，进而根据预设缓存空间中是否存在请求记录判断当前用户请求是否重复，无需依赖前端开发，对于已开发完成的系统，通过直接引入上述请求接口即可实现针对特定请求的防重校验，降低了对已有系统的侵入性以及接入成本。

本申请还公开了一种请求处理装置及一种电子设备和一种计算机可读存储介质，同样能实现上述技术效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

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

图1为本申请实施例公开的一种请求处理方法的流程图；

图2为本申请实施例公开的另一种请求处理方法的流程图；

图3为本申请实施例公开的一种具体的请求处理方法的流程图；

图4为本申请实施例公开的一种请求处理装置的结构图；

图5为本申请实施例公开的一种电子设备的结构图；

图6为本申请实施例公开的另一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在现有技术中，针对防止重复提交，通常采用Token(令牌)机制，前端需要传入指定的Token，后端在接收到请求后基于Token进行防重校验，需要依赖于前后端双方的工作，且若在系统开发结束后需要为已有的系统添加防重提交功能时，需要修改系统的底层框架代码，对于系统的侵入性较大。

因此，本申请实施例公开了一种请求处理方法，无需依赖前端开发，降低了对已有系统的侵入性以及接入成本。

参见图1所示，本申请实施例公开的一种请求处理方法包括：

S101：当接收到用户请求后，确定所述用户请求对应的请求接口；

本申请实施例中，在接收到用户请求之后，确定当前用户请求对应的请求接口，其中，上述请求接口与请求是一一对应的关系。

具体地，可以预先编写Spring拦截器，用于对用户请求进行拦截，在接收到用户请求后可利用Spring拦截器对用户请求进行拦截，并对用户请求进行解析，以确定用户请求对应的请求接口。

S102：基于所述请求接口判断是否需要对所述用户请求进行防重校验；

在本步骤中，将根据请求接口判断是否当前用户请求是否需要进行防重校验，具体地，可以利用Java注解技术为需要进行防重校验的请求对应的请求接口添加注解，从而可以通过判断请求接口是否预先添加注解，如果是，则判定当前请求接口接收到的用户请求需要进行防重校验。

S103：若判定需要对所述用户请求进行防重校验，则获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识；

若判定需要对用户请求进行防重校验，则获取用户请求的发起方的第一标识，并获取请求接口的第二标识。具体地，可确定用户请求中携带的请求参数，得到发起方对应的第一标识，并利用Java反射机制获取请求接口对应的Token，将该Token确定为请求接口的第二标识。

S104：利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录；

S105：若所述预设缓存空间中存在与当前所述用户请求重复的请求记录，则禁止对当前所述用户请求进行响应。

本申请实施例中，利用第一标识和第二标识判断预设缓存空间中是否存在与当前用户请求重复的请求记录，若预设缓存空间中存在与当前用户请求重复的请求记录，则禁止对当前用户请求进行响应，避免重复响应同一请求。

本申请实施例公开了另一种请求处理方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。参见图2所示，具体的：

S201：当接收到用户请求后，确定所述用户请求对应的请求接口；

S202：基于所述请求接口判断是否需要对所述用户请求进行防重校验；

S203：若判定需要对所述用户请求进行防重校验，则获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识；

S204：利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录；

S205：若所述预设缓存空间中存在与当前所述用户请求重复的请求记录，则禁止对当前所述用户请求进行响应；

S206：若所述预设缓存空间中未存在与当前所述用户请求重复的请求记录，则将所述第二标识存入当前所述用户请求对应的工作线程域中；

S207：将所有所述工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录，并保存至所述预设缓存空间中。

本申请实施例中，若判定得到预设缓存空间中未存在与当前所述用户请求重复的请求记录，则可将第二标识存入当前所述用户请求对应的工作线程域中，并将工作线程域中保存的第二标识和对应的第一标识绑定生成请求记录，将请求记录保存至预设存储空间中。

进一步地，本申请实施例还可以对用户请求的处理过程进行监测，若监测到对当前用户请求的响应过程完成，则从当前用户请求对应的工作线程域中获取对应的第二标识，以便利用第二标识在预设缓存空间中确定出对应的请求记录并删除。可以理解的是，预设存储空间用于保存所有正在处理未结束的请求记录，具体可以为redis数据库。

作为一种优选实施方式，本申请实施例在将所有工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录之后，还可以对请求记录设定一个有效时间，可利用服务器获取获取用户设定的有效时间，若监测到在有效时间后请求记录仍存储在预设缓存空间中，则自动对请求记录进行删除，防止因程序异常等原因导致预设存储空间中记录长期存储，避免对后续请求处理造成影响。

下面以具体应用场景实例对本申请实施例提供的一种具体的请求处理方法进行介绍。如图3所示，本实施例基于Java注解技术，对于需要防重的处理，在后端接口上增加注解，指定接口对应的唯一Token值。进而可以基于Spring切面技术，对于前端提交的请求进行拦截，并判断该提交请求对应的接口是否添加有注解，若无注解，则可直接放行；若有注解，则本实施例利用反射技术从注解中取出接口对应的唯一Token，将该Token存入本次请求对应的工作线程域中，并从当前请求的参数中取出用于标识用户的唯一信息作为key，与该Token一并存入Redis中。在本次请求完成后，从本次请求对应的工作线程域中取出对应的Token，并取出用户的唯一key，以根据上述key移除Redis中对应的请求记录。

在后端对请求进行处理的过程中，对于同一请求的到来，利用Token值与用户相关唯一标识信息校验Redis中是否存有对应的请求记录，若存有，则代表上一请求没有结束，判定为重复提交，禁止对当前请求进行响应，否则非重复提交。另外，本实施例对于Redis中key对应的请求记录，还可以为其设定一个过期时间，防止因程序异常而导致Redis中记录长存。

本申请实施例中，利用J ava注解技术为需要进行防重校验的接口注入注解，利用Spring拦截器对请求进行统一处理，降低工具的侵入性，使工具的接入与业务脱耦，利用Redis充当存储介质，对于历史存在系统、或者新开发的系统，可以直接通过该后端组件快速实现特定场景下的防重提交，接入成本小，且整个防重过程不需要依赖前端开发介入，仅仅依赖了成熟的Redis以及Spring技术，扩展性强。

下面对本申请实施例提供的一种请求处理装置进行介绍，下文描述的一种请求处理装置与上文描述的一种请求处理方法可以相互参照。

参见图4所示，本申请实施例提供的一种请求处理装置包括：

接口确定模块301，用于当接收到用户请求后，确定所述用户请求对应的请求接口；

防重判断模块302，用于基于所述请求接口判断是否需要对所述用户请求进行防重校验；

标识获取模块303，用于若判定需要对所述用户请求进行防重校验，则获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识；

记录判断模块304，用于利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录；

响应禁止模块305，用于若所述预设缓存空间中存在与当前所述用户请求重复的请求记录，则禁止对当前所述用户请求进行响应。

关于上述模块301至305的具体实施过程可参考前述实施例公开的相应内容，在此不再进行赘述。

在上述实施例的基础上，作为一种优选实施方式，所述防重判断模块302，包括：

注解判断单元，用于判断所述请求接口是否预先添加注解；如果是，则进入防重判定单元的工作流程；

防重判定单元，用于判定所述请求接口接收到的用户请求需要进行防重校验。

在上述实施例的基础上，作为一种优选实施方式，所述接口确定模块301，包括：

请求拦截单元，用于当接收到用户请求后，利用预先编写的Spring拦截器对所述用户请求进行拦截；

请求解析单元，用于对所述用户请求进行解析，确定所述用户请求对应的请求接口。

在上述实施例的基础上，作为一种优选实施方式，所述标识获取模块303，包括：

第一获取单元，用于确定所述用户请求中携带的请求参数，得到所述发起方对应的第一标识；

第二获取单元，用于利用Java反射机制获取所述请求接口对应的Token。

在上述实施例的基础上，作为一种优选实施方式，所述请求处理装置还包括：

标识保存模块，用于在利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录之后，若所述预设缓存空间中未存在与当前所述用户请求重复的请求记录，则将所述第二标识存入当前所述用户请求对应的工作线程域中；

记录保存模块，用于将所有所述工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录，并保存至所述预设缓存空间中。

响应监测模块，用于若监测到对当前所述用户请求的响应过程完成，则从当前所述用户请求对应的工作线程域中获取对应的第二标识；

记录删除模块，用于利用所述第二标识在所述预设缓存空间中确定对应的请求记录并删除。

时间设定模块，用于将所有所述工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录之后，获取针对所述请求记录设定的有效时间；

自动删除模块，用于若监测到在所述有效时间后所述请求记录仍存储在所述预设缓存空间中，则自动对所述请求记录进行删除。

本申请还提供了一种电子设备，参见图5所示，本申请实施例提供的一种电子设备包括：

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

处理器200，用于执行所述计算机程序时可以实现上述实施例所提供的步骤。

具体的，存储器100包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令，该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。处理器200在一些实施例中可以是一中央处理器(CentralProcessing Unit，CPU)、控制器、微控制器、微处理器或其他数据处理芯片，为电子设备提供计算和控制能力，执行所述存储器100中保存的计算机程序时，可以实现前述任一种实施例公开的请求处理方法的步骤。

在上述实施例的基础上，作为优选实施方式，参见图6所示，所述电子设备还包括：

输入接口300，与处理器200相连，用于获取外部导入的计算机程序、参数和指令，经处理器200控制保存至存储器100中。该输入接口300可以与输入装置相连，接收用户手动输入的参数或指令。该输入装置可以是显示屏上覆盖的触摸层，也可以是终端外壳上设置的按键、轨迹球或触控板，也可以是键盘、触控板或鼠标等。

显示单元400，与处理器200相连，用于显示处理器200处理的数据以及用于显示可视化的用户界面。该显示单元400可以为LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。

网络端口500，与处理器200相连，用于与外部各终端设备进行通信连接。该通信连接所采用的通信技术可以为有线通信技术或无线通信技术，如移动高清链接技术(MHL)、通用串行总线(USB)、高清多媒体接口(HDMI)、无线保真技术(WiFi)、蓝牙通信技术、低功耗蓝牙通信技术、基于IEEE802.11s的通信技术等。

图6仅示出了具有组件100-500的电子设备，本领域技术人员可以理解的是，图6示出的结构并不构成对电子设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

本申请还提供了一种计算机可读存储介质，该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。该存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述任一种实施例公开的请求处理方法的步骤。

本申请在接收到用户请求后，将根据当前用户请求确定其对应的请求接口，并基于上述请求接口确定是否需要对当前用户请求进行防重校验，进而根据预设缓存空间中是否存在请求记录判断当前用户请求是否重复，无需依赖前端开发，对于已开发完成的系统，通过直接引入上述请求接口即可实现针对特定请求的防重校验，降低了对已有系统的侵入性以及接入成本。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

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

Claims

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

当接收到用户请求后，确定所述用户请求对应的请求接口；

2.根据权利要求1所述的请求处理方法，其特征在于，所述基于所述请求接口判断是否需要对所述用户请求进行防重校验，包括：

判断所述请求接口是否预先添加注解；

3.根据权利要求1所述的请求处理方法，其特征在于，当接收到用户请求后，确定所述用户请求对应的请求接口，包括：

4.根据权利要求1所述的请求处理方法，其特征在于，所述获取所述用户请求的发起方的第一标识，并获取所述请求接口的第二标识，包括：

利用Java反射机制获取所述请求接口对应的Token。

5.根据权利要求1至4任一项所述的请求处理方法，其特征在于，所述利用所述第一标识和第二标识判断预设缓存空间中是否存在与当前所述用户请求重复的请求记录之后，还包括：

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

7.根据权利要求5所述的请求处理方法，其特征在于，将所有所述工作线程域中保存的第二标识和对应的所述第一标识绑定得到请求记录之后，还包括：

获取针对所述请求记录设定的有效时间；

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

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

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

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述请求处理方法的步骤。

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