CN117668398A - 接口幂等性处理方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种接口幂等性处理方法、装置及电子设备，涉及幂等性通用注解技术领域。方法包括：获取用户信息和接口请求，并对接口请求的类型进行判断；在接口请求为第一类型请求的情况下，为接口请求分配标识信息；根据标识信息，在多级缓存中查找是否有对应于标识信息的存储记录，得到查找结果；基于查找结果，对第一类型的接口请求进行处理。与相关技术相比，本申请通过对接口接收到的请求的类型进行判断，在接口请求为第一类型请求的情况下，为接口请求分配标识信息，从而改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。

Description

接口幂等性处理方法、装置及电子设备

技术领域

本申请涉及幂等性通用注解技术领域，具体涉及一种接口幂等性处理方法、装置及电子设备。

背景技术

幂等指的是多次同样的操作而不改变结果。在复杂的业务系统中，可能会出现重复的请求，即同一请求因为某些原因被多次提交，比如微服务架构下，接口接收到的Http请求可能会超时，很多业务在超时场景下会进行重试，这也是造成重复请求的一个重要原因。此外消息队列MQ已经广泛应用在业务实现中，而MQ本身是不提供幂等性消费的，因此可能会消费重复的消息。因此我们需要提供幂等的接口来保证对重复请求或者重复消费的处理。

但是目前的接口的幂等方案中，都是先根据唯一性ID查询，然后根据查询的结果做对应的操作。同时会对相同的资源进行加锁来避免并发问题。在实际操作中某些情况下是没有唯一性ID的(如自研网络功能虚拟化NFV平台等)，因此目前的幂等方案无法直接进行使用。

发明内容

有鉴于此，本申请提供了一种接口幂等性处理方法、装置及电子设备，主要目的在于改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。

第一方面，本申请提供了一种接口幂等性处理方法，包括：

获取用户信息和接口请求，并对所述接口请求的类型进行判断；

在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息；

根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；

基于所述查找结果，对所述第一类型的接口请求进行处理。

可选地，所述在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息，包括：判断所述接口请求是否已具有请求标识；在不具有所述请求标识的情况下，根据所述用户信息，生成标识信息；在已具有所述请求标识的情况下，则根据已有的所述请求标识作为标识信息。

可选地，在不具有所述请求标识的情况下，根据所述用户信息，生成标识信息，包括：在所述用户信息和所述接口请求中提取请求信息；通过加密算法对所述请求信息进行加密处理，生成字符串，作为所述标识信息；其中，所述请求信息包括请求源地址、请求方法和定位符。

可选地，所述根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果，包括：基于所述标识信息，在一级缓存中查找是否由对应于所述标识信息的存储记录；在所述一级缓存中的查找结果为否的情况下，在二级缓存中查找是否由对应于所述标识信息的存储记录；在所述二级缓存中的查找结果为否的情况下，在三级缓存中查找是否由对应于所述标识信息的存储记录；其中，所述一级缓存为本地缓存，所述二级缓存为redis缓存，所述三级缓存为MySql数据库中的业务资源表。

可选地，所述基于所述查找结果，对所述第一类型的接口请求进行处理，包括：在任一级缓存的所述查找结果为是的情况下，返回重复请求；在所述三级缓存中的查找结果为否的情况下，执行所述接口请求对应的业务。

可选地，在获取用户信息和接口请求，并对所述接口请求的类型进行判断后，所述方法还包括：在所述接口请求为第二类型请求的情况下，将所述接口请求的消息ID作为标识信息；基于所述标识信息，依次在一级缓存和二级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；基于所述查找结果，对所述第二类型的接口请求进行处理。

可选地，所述基于所述查找结果，对所述第二类型的接口请求进行处理，包括：在任一级缓存的所述查找结果为是的情况下，返回重复请求；在所述二级缓存中的查找结果为否的情况下，执行所述接口请求对应的业务。

第二方面，本申请提供了一种接口幂等性处理装置，包括：

获取单元，被配置为获取用户信息和接口请求，并对所述接口请求的类型进行判断；

分配单元，被配置为在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息；

查找单元，被配置为根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；

处理单元，被配置为基于所述查找结果，对所述接口请求进行处理。

第三方面，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的接口幂等性处理方法。

第四方面，本申请提供了一种电子设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面所述的接口幂等性处理方法。

借由上述技术方案，本申请提供的一种接口幂等性处理方法、装置及电子设备，本申请首先获取用户信息和接口请求，并对接口请求的类型进行判断；在接口请求为第一类型请求的情况下，为接口请求分配标识信息；根据标识信息，在多级缓存中查找是否有对应于标识信息的存储记录，得到查找结果；基于查找结果，对第一类型的接口请求进行处理。与相关技术相比，本申请通过对接口接收到的请求的类型进行判断，在接口请求为第一类型请求的情况下，为接口请求分配标识信息，从而改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

图1示出了本申请实施例提供的一种接口幂等性处理方法的流程示意图；

图2示出了本申请实施例提供的一种接口幂等性处理方法的系统框架示意图；

图3示出了本申请实施例提供的另一种接口幂等性处理方法的流程示意图；

图4示出了本申请实施例提供的一种接口幂等性处理装置的结构示意图。

具体实施方式

为了能够更清楚地理解本申请的上述目的、特征和优点，下面将对本申请的方案进行进一步描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

为了改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题，本实施例提供了一种接口幂等性处理方法，如图1所示，该方法包括：

S101，获取用户信息和接口请求，并对接口请求的类型进行判断。

首先，用户信息包括例如用户的请求内容(创建、更新、删除等)、参数中的userID，以及请求源IP、请求方法HttpMethod和网址等。接口请求主要包括Http请求以及MQ消息(消息队列)的消费请求，主要目的也在于针对这两种请求的区分和处理。

S102，在接口请求为第一类型请求的情况下，为接口请求分配标识信息。

其中，第一类型请求为Http请求，第二类型请求为MQ消息的消费请求。在本实施例中，判断接口请求为第一类型请求的情况下，为接口请求分配标识信息，标识信息也即是唯一性ID。

S103，根据标识信息，在多级缓存中查找是否有对应于标识信息的存储记录，得到查找结果。

根据唯一性ID，在多级缓存机制中查找是否有对应于标识信息的存储记录。在本实施例中，多级缓存机制是指具有先后查询顺序的多级缓存，以本地缓存(例如Caffeine)作为一级缓存，redis作为二级缓存，Mysql数据库中的业务资源表作为三级缓存。

S104，基于查找结果，对接口请求进行处理。

依据在多级缓存中的查找结果，对接口请求进行处理。

在本实施例中，首先获取用户信息和接口请求，并对接口请求的类型进行判断；在接口请求为第一类型请求的情况下，为接口请求分配标识信息；根据标识信息，在多级缓存中查找是否有对应于标识信息的存储记录，得到查找结果；基于查找结果，对第一类型的接口请求进行处理。与相关技术相比，本实施例通过对接口接收到的请求的类型进行判断，在接口请求为第一类型请求的情况下，为接口请求分配标识信息，从而改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。

可选地，在接口请求为第一类型请求的情况下，为接口请求分配标识信息，包括：判断接口请求是否已具有请求标识；在不具有请求标识的情况下，根据用户信息，生成标识信息；在已具有请求标识的情况下，则根据已有的请求标识作为标识信息。

在本实施例中，对Http类型请求如何分配唯一性ID进行了说明。首先判断Http请求中是否已具有请求标识，也即是否有已有的ID，若有，则将已有的ID作为唯一性ID，或是将已有ID并结合请求信息，作为唯一性ID。若Http请求没有请求标识，则根据用户信息，为其生成标识信息。从而改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。

可选地，在不具有请求标识的情况下，根据用户信息，生成标识信息，包括：在用户信息和接口请求中提取请求信息；通过加密算法对请求信息进行加密处理，生成字符串，作为标识信息；其中，请求信息包括请求源地址、请求方法和定位符。

在本实施例中，对如何根据用户信息，生成标识信息的过程进行说明。首先过滤器Filter过滤用户的CUD(Create、Update、Delete)请求，获取header中的参数userId，从request中获取请求信息，包括请求源IP、请求方法HttpMethod和定位符，然后将这些参数与请求参数中的所有非空参数，进行加密(例如MD5算法)，生成如16进制的字符串作为唯一性ID。

可选地，根据标识信息，在多级缓存中查找是否有对应于标识信息的存储记录，得到查找结果，包括：基于标识信息，在一级缓存中查找是否由对应于标识信息的存储记录；在一级缓存中的查找结果为否的情况下，在二级缓存中查找是否由对应于标识信息的存储记录；在二级缓存中的查找结果为否的情况下，在三级缓存中查找是否由对应于标识信息的存储记录；其中，一级缓存为本地缓存，二级缓存为redis缓存，三级缓存为MySql数据库中的业务资源表。

在本实施例中，首先在本地缓存中查询是否由对应于标识信息的存储记录，没有去redis查询，如果redis没有记录那么进入请求参数校验模块，此时MySql中的业务资源表作为三级缓存，确认该请求是否在MySql中有记录。

可选地，基于查找结果，对第一类型的接口请求进行处理，包括：在任一级缓存的查找结果为是的情况下，返回重复请求；在三级缓存中的查找结果为否的情况下，执行接口请求对应的业务。

在本实施例中，这里的重复请求，指的是返回相同参数请求操作太频繁，请稍后再试的含义。如果在缓存中查到了对应的记录，那么该用户在同一资源池刚订购过同一订购参数的负载均衡资源，则认为他是重复操作，返回相同参数请求操作太频繁，请稍后再试的错误信息。如果没有记录，在进行参数校验和补齐以及相关处理后，资源请求入库，并且生产消息通知具体的业务实现模块进行处理，执行接口请求对应的业务。

可选地，在获取用户信息和接口请求，并对接口请求的类型进行判断后，方法还包括：在接口请求为第二类型请求的情况下，将接口请求的消息ID作为标识信息；基于标识信息，依次在一级缓存和二级缓存中查找是否有对应于标识信息的存储记录，得到查找结果；基于查找结果，对第二类型的接口请求进行处理。

在本实施例中，若接口请求为MQ消息的消费请求，由于此类消息中带有消息ID，则直接将消息ID作为标识信息，并在一级缓存和二级缓存中查找是否有对应的存储记录，从而实现对MQ消息的查询。

可选地，基于查找结果，对第二类型的接口请求进行处理，包括：在任一级缓存的查找结果为是的情况下，返回重复请求；在二级缓存中的查找结果为否的情况下，执行接口请求对应的业务。

在本实施例中，针对MQ消息的消费请求也同样提供了幂等接口和根据消费ID进行查询的功能，从而使得对于此类请求也能够实现接口识别和执行。

接下来从整体角度对本实施例所提出的接口幂等性处理方法进行说明。首先，在复杂的业务系统中，可能会出现重复的请求，即同一请求因为某些原因被多次提交，被称之为幂等。而MQ消费在相关技术中并不提供幂等性服务，因此可能会消费重复的信息。因此，我们需要提供幂等接口来保证对重复请求和重复消费的处理。

目前的方法都是先根据唯一性ID查询，然后根据查询的结果做对应的操作。同时会对相同的资源进行加锁来避免并发问题。加锁是通用的，不通用的部分就是判断这个操作之前有没有操作过，因此需要一个通用的存储来记录所有的操作。一般我们会选择使用多级缓存来提供性能，比如一级缓存使用Redis来实现，Redis可以设置一定的失效时间，这样查询性能高，可以适应大部分短时间内请求重复的场景，又可以让key自动失效。二级缓存使用MySql，适用于时间长或者中间状态查询以及失败重试的场景。但某些情况下对于没有唯一性ID的(如自研网络功能虚拟化NFV平台等)，因此目前的幂等方案无法直接进行使用。

幂等性技术的技术架构示意图，主要包括三部分：

(1)Idempotent注解：提供通用的幂等组件，注入对应的类即可实现幂等，屏蔽加锁，记录判断等逻辑。

(2)幂等组件：幂等实现方，以AOP方式提供对幂等注解的实现，具体提供了支持SPEL表达式方式配置幂等缓存key、支持自定义查询后的处理、支持选择多种存储组件、支持顺序或并发查重、支持定义不同存储的缓存过期时间、支持多种分布式加锁方式等等功能。

(3)存储组件：以策略模式来实现，提供防重表以供查询、记录、对比。

注解定义了幂等组件所有相关操作的方式，通过AOP拦截idempotent注解注解的方法，来进行具体的实现：

这一部分主要提供了value(锁的名称、默认方法名)、幂等key(配置后可以从方法参数中解析、默认从上下文获取)、一级缓存过期时间、二级缓存过期时间、缓存读写类型(顺序、并行)、读写锁过期时间、重复后的处理方法这些参数，可以看出，幂等方案的主要功能都在幂等注解中进行了相关定义。

如果用户定义了锁名称和幂等key，那么就从方法的参数中解析出幂等key组合所名称作为加锁的key来对幂等具体实现进行加锁；从idempotent注解中得到相关配置用于具体幂等实现的配置下发。具体的执行过程如图2所示。

至此，目前的幂等性方案中还存在对于Http请求没有唯一性ID，现有的幂等方案都是无法直接使用，以及无法同时满足MQ消费消息幂等的诉求的问题。

如图3所示，示出了本实施例所提出了另一种接口幂等性处理方法，

首先，该服务可基于docker进行部署，利用两个service服务器对外提供服务，请求通过轮询方式调度到对应的service，在service中拦截用户的请求，获取请求信息，生成唯一性ID。

具体地，Filter过滤用户的CUD(Create、Update、Delete)请求，获取header中的参数userId，从request中获取请求源IP、HttpMethod和URI，然后将这两个参数与请求参数中的所有非空参数，进行MD5算法加密，生成的16进制字符串作为唯一性ID。

进而将本地缓存Caffeine作为一级缓存，进入本地缓存，查询不同请求方法的本地缓存中是否有对应的唯一性ID的记录；本地缓存中没有去redis查询，此时redis作为二级缓存。对于Http请求，如果Caffeine缓存中查到了唯一ID对应的记录，那么该用户在同一资源池刚订购过同一订购参数的负载均衡资源，我们认为他是重复操作，返回相同参数请求操作太频繁，请稍后再试的错误信息；如果本地缓存没有，那么继续去redis查询，如果redis查到记录，说明是另一个服务已经执行了重复的请求了，那么在本地缓存保存该记录，返回重复操作。根据Http请求方法划分为Create、Update、Delete；通常我们认为创建弹性负载均衡资源的订单超时时间是30min，其他的操作默认超时时间是5min，因此我们本地缓存分为两部分。此处我们使用Caffeine作为一级本地缓存，考虑到资源操作可能会失败，而且资源操作并不总是性能较差耗费时间很长，此处创建弹性负载均衡资源使用一份Caffeine缓存，初始大小100，最大数量1000，过期时间10分钟(即我们认为同一用户在同一资源池，10分钟内不会进行请求参数完全一致的资源订购)；其他请求使用一份Caffeine缓存，初始大小200，最大数量5000，过期时间2分钟，超过过期时间的都将在缓存中删除。

如果redis中也没有那么进入请求参数校验模块，此时MySql中的业务资源表作为三级缓存，确认该请求是否在MySql中有记录，根据查询记录结果判断请求状态。如果MySql中没有记录，在进行参数校验和补齐以及相关处理后，资源请求入库，并且生产消息通知具体的业务实现模块进行处理。可选地，若在二级缓存或三级缓存中的查找结果为是，则可以将对应的记录信息同步至一级缓存中，以便下次在一级缓存中的查找。

若判断不是Http请求，则拦截Consumer消费的消息，本地缓存作为一级缓存，根据消息ID去本地缓存中查询是否有消息ID的记录。以消息ID作为key去Caffeine中查询是否有对应的记录；此处消息ID也会存储到资源表记录中，在工程启动时，会加载资源表中状态为PENDING_CREATE、PENDING_UPDATE、PENDING_DELETE的资源对应的消息ID到缓存中以供查重；进一步地，如果缓存中查到了消息ID对应的记录，那么认为该消息已被消费过或者消费中，提交对应的offset；如果没查到，那么继续在redis中查询。如果redis中查到该消息ID对应的记录，那么认为该消息已被消费过或者消费中，提交对应的offset；如果没查到，那么认为是新的请求，执行消费消息的业务逻辑。

在本实施例中，通过在业务提供方根据请求的userId、host、HttpMethod和URI以及请求参数，使用MD5加密算法生成字符串作为唯一性ID。解决了目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。此外，解决MQ消费消息的幂等，通过使用Caffeine作为一级缓存，Redis作为二级缓存，兼顾了性能和可靠性。

进一步的，作为图1至图3所示方法的具体实现，本实施例提供了一种接口幂等性处理装置，如图4所示，该装置包括：获取单元41、分配单元42、查找单元43和处理单元44。

获取单元41，被配置为获取用户信息和接口请求，并对所述接口请求的类型进行判断；

分配单元42，被配置为在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息；

查找单元43，被配置为根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；

处理单元44，被配置为基于所述查找结果，对所述接口请求进行处理。

在具体的应用场景中，分配单元42，具体被配置为判断所述接口请求是否已具有请求标识；在不具有所述请求标识的情况下，根据所述用户信息，生成标识信息；在已具有所述请求标识的情况下，则根据已有的所述请求标识作为标识信息。

在具体的应用场景中，分配单元42，具体还被配置为在所述用户信息和所述接口请求中提取请求信息；通过加密算法对所述请求信息进行加密处理，生成字符串，作为所述标识信息；其中，所述请求信息包括请求源地址、请求方法和定位符。

在具体的应用场景中，查找单元43，具体还被配置为基于所述标识信息，在一级缓存中查找是否由对应于所述标识信息的存储记录；在所述一级缓存中的查找结果为否的情况下，在二级缓存中查找是否由对应于所述标识信息的存储记录；在所述二级缓存中的查找结果为否的情况下，在三级缓存中查找是否由对应于所述标识信息的存储记录；其中，所述一级缓存为本地缓存，所述二级缓存为redis缓存，所述三级缓存为MySql数据库中的业务资源表。

在具体的应用场景中，查找单元43，具体还被配置为在任一级缓存的所述查找结果为是的情况下，返回重复请求；在所述三级缓存中的查找结果为否的情况下，执行所述接口请求对应的业务。

在具体的应用场景中，处理单元44，具体还被配置为在所述接口请求为第二类型请求的情况下，将所述接口请求的消息ID作为标识信息；基于所述标识信息，依次在一级缓存和二级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；基于所述查找结果，对所述第二类型的接口请求进行处理。

在具体的应用场景中，处理单元44，具体还被配置为在任一级缓存的所述查找结果为是的情况下，返回重复请求；在所述二级缓存中的查找结果为否的情况下，执行所述接口请求对应的业务。

需要说明的是，本实施例提供的一种接口幂等性处理装置所涉及各功能单元的其它相应描述，可以参考图1至图3中的对应描述，在此不再赘述。

基于上述如图1至图3所示方法，相应的，本实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述如图1至图3所示的方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景的方法。

基于上述如图1至图3所示的方法，以及图4所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种电子设备，可配置在计算机端侧等，该设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1至图3所示的方法。

基于上述如图1至图3所示的方法，以及图4所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种芯片，包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，使得所述电子设备执行上述如图1至图3所示的方法。

可选的，上述实体设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的上述实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本实施例的方案，首先获取用户信息和接口请求，并对接口请求的类型进行判断；在接口请求为第一类型请求的情况下，为接口请求分配标识信息；根据标识信息，在多级缓存中查找是否有对应于标识信息的存储记录，得到查找结果；基于查找结果，对第一类型的接口请求进行处理。与相关技术相比，本实施例通过对接口接收到的请求的类型进行判断，在接口请求为第一类型请求的情况下，为接口请求分配标识信息，从而改善目前部分情况下控制台请求没有唯一性ID，导致目前的幂等方案无法直接应用的问题。

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

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所述的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种接口幂等性处理方法，其特征在于，包括：

获取用户信息和接口请求，并对所述接口请求的类型进行判断；

在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息；

根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；

基于所述查找结果，对所述第一类型的接口请求进行处理。

2.根据权利要求1所述的方法，其特征在于，所述在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息，包括：

判断所述接口请求是否已具有请求标识；

在不具有所述请求标识的情况下，根据所述用户信息，生成标识信息；

在已具有所述请求标识的情况下，则根据已有的所述请求标识作为标识信息。

3.根据权利要求2所述的方法，其特征在于，在不具有所述请求标识的情况下，根据所述用户信息，生成标识信息，包括：

在所述用户信息和所述接口请求中提取请求信息；

通过加密算法对所述请求信息进行加密处理，生成字符串，作为所述标识信息；

其中，所述请求信息包括请求源地址、请求方法和定位符。

4.根据权利要求1所述的方法，其特征在于，所述根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果，包括：

基于所述标识信息，在一级缓存中查找是否由对应于所述标识信息的存储记录；

在所述一级缓存中的查找结果为否的情况下，在二级缓存中查找是否由对应于所述标识信息的存储记录；

在所述二级缓存中的查找结果为否的情况下，在三级缓存中查找是否由对应于所述标识信息的存储记录；

其中，所述一级缓存为本地缓存，所述二级缓存为redis缓存，所述三级缓存为MySql数据库中的业务资源表。

5.根据权利要求4所述的方法，其特征在于，所述基于所述查找结果，对所述第一类型的接口请求进行处理，包括：

在任一级缓存的所述查找结果为是的情况下，返回重复请求；

在所述三级缓存中的查找结果为否的情况下，执行所述接口请求对应的业务。

6.根据权利要求1至5中任一项所述的方法，其特征在于，在获取用户信息和接口请求，并对所述接口请求的类型进行判断后，所述方法还包括：

在所述接口请求为第二类型请求的情况下，将所述接口请求的消息ID作为标识信息；

基于所述标识信息，依次在一级缓存和二级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；

基于所述查找结果，对所述第二类型的接口请求进行处理。

7.根据权利要求6所述的方法，其特征在于，所述基于所述查找结果，对所述第二类型的接口请求进行处理，包括：

在任一级缓存的所述查找结果为是的情况下，返回重复请求；

在所述二级缓存中的查找结果为否的情况下，执行所述接口请求对应的业务。

8.一种接口幂等性处理装置，其特征在于，包括：

获取单元，被配置为获取用户信息和接口请求，并对所述接口请求的类型进行判断；

分配单元，被配置为在所述接口请求为第一类型请求的情况下，为所述接口请求分配标识信息；

查找单元，被配置为根据所述标识信息，在多级缓存中查找是否有对应于所述标识信息的存储记录，得到查找结果；

处理单元，被配置为基于所述查找结果，对所述接口请求进行处理。

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

10.一种电子设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的方法。