处理接口幂等性的两种常见方案

【Spring Boot】实现接口幂等性的 4 种方案 在HTTP/1.1中,对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外),即第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。幂等性是开发当中很常见也很重要的一个需求,尤其是支付、订单等与金钱挂钩的服务,保证接口幂等性尤其重要。对于下单等存在唯一主键的,可以使用“唯一主键方案”的方式实现; 阅读详情

接口幂等性处理算是一个非常常见的需求了,我们在很多项目中其实都会遇到。今天我们来看看两种比较简单的实现思路。

1. 接口幂等性实现方案梳理

其实接口幂等性的实现方案还是蛮多的,我这里和小伙伴们分享两种比较常见的方案。

1.1 基于 Token

基于 Token 这种方案的实现思路很简单,整个流程分两步:

  1. 客户端发送请求,从服务端获取一个 Token 令牌,每次请求获取到的都是一个全新的令牌。
  2. 客户端发送请求的时候,携带上第一步的令牌,处理请求之前,先校验令牌是否存在,当请求处理成功,就把令牌删除掉。

大致的思路就是上面这样,当然具体的实现则会复杂很多,有很多细节需要注意,松哥之前也专门录过这种方案的视频,小伙伴们可以参考下,录了两个视频,一个是基于拦截器处理的,还有一个是基于 AOP 切面处理的:

基于拦截器处理(视频一):

基于 AOP 切面处理(视频二):

1.2 基于请求参数校验

最近在 TienChin 项目中使用的是另外一种方案,这种方案是基于请求参数来判断的,如果在短时间内,同一个接口接收到的请求参数相同,那么就认为这是重复的请求,拒绝处理,大致上就是这么个思路。

相比于第一种方案,第二种方案相对来说省事一些,因为只有一次请求,不需要专门去服务端拿令牌。在高并发环境下这种方案优势比较明显。

所以今天我就来和大家聊聊第二种方案的实现,后面在 TienChin 项目视频中也会和大家细讲。

2. 基于请求参数的校验

首先我们新建一个 Spring Boot 项目,引入 Web 和 Redis 依赖,新建完成后,先来配置一下 Redis 的基本信息,如下:

spring.redis.host=localhost
spring.redis.port=6379
spring.redis.password=123
复制代码

为了后续 Redis 操作方便,我们再来对 Redis 进行一个简单封装,如下:

@Component
public class RedisCache {
    @Autowired
    public RedisTemplate redisTemplate;
    public <T> void setCacheObject(final String key, final T value, final Integer timeout, final TimeUnit timeUnit) {
        redisTemplate.opsForValue().set(key, value, timeout, timeUnit);
    }
    public <T> T getCacheObject(final String key) {
        ValueOperations<String, T> operation = redisTemplate.opsForValue();
        return operation.get(key);
    }
}
复制代码

这个比较简单,一个存数据,一个读数据。

接下来我们自定义一个注解,在需要进行幂等性处理的接口上,添加该注解即可,将来这个接口就会自动的进行幂等性处理。

@Inherited
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RepeatSubmit {
    /**
     * 间隔时间(ms),小于此时间视为重复提交
     */
    public int interval() default 5000;

    /**
     * 提示消息
     */
    public String message() default "不允许重复提交,请稍候再试";
}
复制代码

这个注解我们通过拦截器来进行解析,解析代码如下:

public abstract class RepeatSubmitInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (handler instanceof HandlerMethod) {
            HandlerMethod handlerMethod = (HandlerMethod) handler;
            Method method = handlerMethod.getMethod();
            RepeatSubmit annotation = method.getAnnotation(RepeatSubmit.class);
            if (annotation != null) {
                if (this.isRepeatSubmit(request, annotation)) {
                    Map<String, Object> map = new HashMap<>();
                    map.put("status", 500);
                    map.put("msg", annotation.message());
                    response.setContentType("application/json;charset=utf-8");
                    response.getWriter().write(new ObjectMapper().writeValueAsString(map));
                    return false;
                }
            }
            return true;
        } else {
            return true;
        }
    }

    /**
     * 验证是否重复提交由子类实现具体的防重复提交的规则
     *
     * @param request
     * @return
     * @throws Exception
     */
    public abstract boolean isRepeatSubmit(HttpServletRequest request, RepeatSubmit annotation);
}
复制代码

这个拦截器是一个抽象类,将接口方法拦截下来,然后找到接口上的 @RepeatSubmit 注解,调用 isRepeatSubmit 方法去判断是否是重复提交的数据,该方法在这里是一个抽象方法,我们需要再定义一个类继承自这个抽象类,在新的子类中,可以有不同的幂等性判断逻辑,这里我们就是根据 URL 地址+参数 来判断幂等性条件是否满足:

@Component
public class SameUrlDataInterceptor extends RepeatSubmitInterceptor {
    public final String REPEAT_PARAMS = "repeatParams";

    public final String REPEAT_TIME = "repeatTime";
    public final static String REPEAT_SUBMIT_KEY = "REPEAT_SUBMIT_KEY";

    private String header = "Authorization";

    @Autowired
    private RedisCache redisCache;

    @SuppressWarnings("unchecked")
    @Override
    public boolean isRepeatSubmit(HttpServletRequest request, RepeatSubmit annotation) {
        String nowParams = "";
        if (request instanceof RepeatedlyRequestWrapper) {
            RepeatedlyRequestWrapper repeatedlyRequest = (RepeatedlyRequestWrapper) request;
            try {
                nowParams = repeatedlyRequest.getReader().readLine();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

        // body参数为空,获取Parameter的数据
        if (StringUtils.isEmpty(nowParams)) {
            try {
                nowParams = new ObjectMapper().writeValueAsString(request.getParameterMap());
            } catch (JsonProcessingException e) {
                e.printStackTrace();
            }
        }
        Map<String, Object> nowDataMap = new HashMap<String, Object>();
        nowDataMap.put(REPEAT_PARAMS, nowParams);
        nowDataMap.put(REPEAT_TIME, System.currentTimeMillis());

        // 请求地址(作为存放cache的key值)
        String url = request.getRequestURI();

        // 唯一值(没有消息头则使用请求地址)
        String submitKey = request.getHeader(header);

        // 唯一标识(指定key + url + 消息头)
        String cacheRepeatKey = REPEAT_SUBMIT_KEY + url + submitKey;

        Object sessionObj = redisCache.getCacheObject(cacheRepeatKey);
        if (sessionObj != null) {
            Map<String, Object> sessionMap = (Map<String, Object>) sessionObj;
            if (compareParams(nowDataMap, sessionMap) && compareTime(nowDataMap, sessionMap, annotation.interval())) {
                return true;
            }
        }
        redisCache.setCacheObject(cacheRepeatKey, nowDataMap, annotation.interval(), TimeUnit.MILLISECONDS);
        return false;
    }

    /**
     * 判断参数是否相同
     */
    private boolean compareParams(Map<String, Object> nowMap, Map<String, Object> preMap) {
        String nowParams = (String) nowMap.get(REPEAT_PARAMS);
        String preParams = (String) preMap.get(REPEAT_PARAMS);
        return nowParams.equals(preParams);
    }

    /**
     * 判断两次间隔时间
     */
    private boolean compareTime(Map<String, Object> nowMap, Map<String, Object> preMap, int interval) {
        long time1 = (Long) nowMap.get(REPEAT_TIME);
        long time2 = (Long) preMap.get(REPEAT_TIME);
        if ((time1 - time2) < interval) {
            return true;
        }
        return false;
    }
}
复制代码

我们来看下具体的实现逻辑:

  1. 首先判断当前的请求对象是不是 RepeatedlyRequestWrapper,如果是,说明当前的请求参数是 JSON,那么就通过 IO 流将参数读取出来
  2. 如果在第一步中,并没有拿到参数,那么说明参数可能并不是 JSON 格式,而是 key-value 格式,那么就以 key-value 的方式读取出来参数,并将之转为一个 JSON 字符串。
  3. 接下来构造一个 Map,将前面读取到的参数和当前时间存入到 Map 中。
  4. 接下来构造存到 Redis 中的数据的 key,这个 key 由固定前缀 + 请求 URL 地址 + 请求头的认证令牌组成,这块请求头的令牌还是非常重要需要有的,只有这样才能区分出来当前用户提交的数据(如果是 RESTful 风格的接口,那么为了区分,也可以将接口的请求方法作为参数拼接到 key 中)。
  5. 接下来就去 Redis 中获取数据,获取到之后,分别去比较参数是否相同以及时间是否过期。
  6. 如果判断都没问题,返回 true,表示这个请求重复了。
  7. 否则返回说明这是用户对这个接口第一次提交数据或者是已经过了时间窗口了,那么就把参数字符串重新缓存到 Redis 中,并返回 false,表示请求没问题。

好啦,做完这一切,最后我们再来配置一下拦截器即可:

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Autowired
    RepeatSubmitInterceptor repeatSubmitInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(repeatSubmitInterceptor)
                .addPathPatterns("/**");
    }
}
复制代码

如此,我们的接口幂等性就处理好啦~在需要的时候,就可以直接在接口上使用啦:

@RestController
public class HelloController {

    @PostMapping("/hello")
    @RepeatSubmit(interval = 100000)
    public String hello(@RequestBody String msg) {
        System.out.println("msg = " + msg);
        return "hello";    }
}
简单聊聊Redis处理接口幂等性的两种方案 在HTTP/1.1中,对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果,即第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。insert操作,这种情况下多次请求,可能会产生重复数据。update操作,如果只是单纯的更新数据,比如:,是没有问题的。如果还有计算,比如:,这种情况下多次请求,可能会导致数据错误。 阅读详情

相关推荐

实现接口幂等性的几种方案!

服务器端在处理请求之前,首先检查该标识符是否已经处理过,如果已经处理过,则直接返回之前的结果,否则继续处理请求。幂等性键方案是一种使用业务相关的键来实现幂等性的方案。服务器端在处理请求之前,首先检查该键是否已经处理过,如果已经处理过,则直接返回之前的结果,否则继续处理请求。在分布式系统或并发环境中,正确地处理幂等性是至关重要的,以确保数据的一致性和可靠性。这些方案都可以帮助实现接口的幂等性。无论选择哪种方案,都应该在设计和开发阶段考虑到幂等性,并进行相应的测试和验证,以确保系统的可靠性和一致性。

DevSavantX的博客 446

「并发编程实战」接口幂等性设计的最佳实现(8种实现方案)

幂等是一个数学与计算机科学概念。。比如求绝对值的函数,就是幂等的,。计算机科学中,幂等表示一次和多次请求某一个资源应该具有同样的副作用,或者说,多次请求所产生的影响与一次请求执行的影响效果相同。产生原因①用户重复提交:一般是指用户填写好表单信息后,由于响应较慢,从而多次点击提交按钮。②非法调用:指第三方通过逆向手段调试到了接口地址,然后通过爬虫或接口工具多次调用。③失败重试:指分布式项目中,被调用方出现超时或异常时,触发了调用方的重试补偿机制。④重复消息:通常指引入MQ。

frozenpenguin的博客 1万+

【微服务】接口幂等性常用解决方案

接口幂等性常用解决方案

congge 6504

实现接口幂等性的8种解决方案

接口如何实现幂等性?

weixin_51582215的博客 5394

Python自动化测试全套教程-第一天(python、pycharm开发环境的安装与配置(图文超级详细);附安装包)

本文介绍了Python开发环境的完整安装配置流程。主要内容包括:1) Python解释器的下载安装与版本检测方法;2) PyCharm IDE的下载安装步骤,包括专业版和社区版的选择;3) PyCharm的基础配置和项目创建方法;4) 开发环境的基本构造说明。文章提供了两种获取安装包的方式(官网下载和文章附件),并详细说明了解释器卸载、安装过程中的注意事项,以及如何验证环境配置成功。特别强调了PyCharm安装时的路径选择和虚拟环境的创建方法,为Python初学者提供了完整的开发环境搭建指南。

kiwi_king的博客 2035

c++实现异步线程池并详细分析线程池析构流程

多线程编程是提高程序性能和响应能力的关键技术之一,异步线程池作为多线程编程的一种有效实现方式,能够管理和复用线程资源,避免频繁创建和销毁线程带来的开销。在本文中,我们将深入探讨如何实现一个异步线程池。

2301_76564925的博客 1599

如何保证接口的幂等性?常见的实现方案有哪些?

。。

不花的花和尚的博客 3993

S7-200 SMART Modbus RTU从站配置与调试实战指南

本文提供了一份详细的S7-200 SMART PLC配置为Modbus RTU从站的实战指南。内容涵盖从硬件基础、软件准备、指令库调用、核心编程到地址映射与调试排错的完整流程。重点解析了MBUS_INIT与MBUS_SLAVE指令的关键参数配置,并深入探讨了Modbus地址与PLC内部V存储区的对应关系,帮助工程师快速打通通讯链路,实现与上位机、触摸屏等主站设备的稳定数据交互。

potato的博客 756

Redis 处理接口幂等性的两种方案

前言:接口幂等性问题,对于开发人员来说,是一个跟语言无关的公共问题。对于一些用户请求,在某些情况下是可能重复发送的,如果是查询类操作并无大碍,但其中有些是涉及写入操作的,一旦重复了,可能会导致很严重的后果,例如交易的接口如果重复请求可能会重复下单。接口幂等性是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。 一、接口幂等性 1.1、什么是接口幂等性 在HTTP/1.1中,对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络

何哥的博客 1万+

网络攻防实验——网络监听

利用CAIN实现ARP监听。

Trieyes_of_feng的博客 3197

VIO实战前传:手把手教你解读Kalibr双目IMU标定报告与参数应用

本文详细解析Kalibr双目IMU联合标定报告的核心参数与应用方法,涵盖重投影误差分析、IMU误差指标解读、关键变换矩阵原理及VINS-Fusion实战配置。通过手把手教学帮助开发者准确理解标定结果,解决VIO算法落地中的参数配置难题,提升视觉惯性里程计的系统稳定性与精度。

weixin_42699679的博客 336

“幂等”不等于“分布式锁”,也不得不考虑返回值

1. 概览在分布式系统中,幂等是一个非常重要的概念,常常与“重试”一起出现。当调用一个远程服务发生超时,调用方并不知道请求是否执行成功,这就是典型的“第三态”问题。对于这个问题最常见的解决方案便是进行主动重试,假如该操作是一个数据库插入操作,重试将对系统产生副作用(创建多条记录),这时我们常常会说,被调用接口需要保障幂等。1.1. 背景幂等可以简单定义如下:任意多次执行所产生的影响均与第一次执行的...

Java知音 854

介绍七种常见还危险的病毒(带样本)

简介:能够感染用户计算机bai系统中的.exe、.dll和.html文件,将自身加密以后缀加到目标文件中。样本(源文件):https://wwx.lanzoux.com/iJx4njrpz1c / https://wwx.lanzoui.com/iYRNLwd8ldc。英文名称:Virus.Win32.Viking.A(标准) / Worm.Win32.Fujack.A(标准)英文名称:Net-Worm.Win32.Blaster.A(标准)/ Lovesan.A/ Msblast.A。

2301_78858007的博客 8487

【面试精讲】如何保证接口的幂等性?常见的实现方案有哪些?

【面试精讲】如何保证接口的幂等性?常见的实现方案有哪些?

小明的Java问道之路 5882

huggingface高速下载模型的实战代码

本文主要介绍了huggingface高速下载模型的实战代码,尤其是无法通过国内源进行下载的huggingface模型,希望能对学习大模型的同学们有所帮助。需要特别说明的是,本文的代码是完全原创的,即能够最大限度利用宽度的速度,而且还能实现断点续传。 文章目录 1. 背景 2. 实战代码

herosunly的博客 29万+

K8S部署Java项目(Gitlab CI/CD自动化部署终极版)

每个人都有惰性,但不断学习是好好生活的根本,共勉!

感谢阅读 6954

什么是接口的幂等性以及如何实现接口幂等性

目录 1、接口调用存在的问题 2、什么是接口的幂等性 3、不做接口的幂等性会产生什么影响 4、什么情况下需要保证接口的幂等性 4.1 select:查询操作 4.2 insert:新增操作 4.3 delete:删除操作 4.3.1 绝对删除 具有幂等性 4.3.2 相对删除 不具有幂等性 4.4 update:更新操作 4.4.1 绝对更新 具有幂等性 4.4.2 相对更新 不具有幂等性 5、使用幂等的业务场景 5.1 前端重复提交 5.2 接口超时重试 5.3 MQ消息重

风暴计划 9722

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

接口幂等性问题和常见的解决方案

接口幂等性问题是指多个请求只能有一个生效, 其它不生效, 比如支付, 当第一次请求如果接口不满足幂等性,可能会产生脏数据,比如用户已经支付过了,因为网络等原因没有及时反馈导致用户多次点击支付按钮造成重复支付,这样肯定是不合理的。

霁晨晨晨的博客 3万+

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

接口幂等性解决方案

一、分布式锁解决方案 先说这种方案,在网上有一些文章说可以通过分布式锁来保证幂等性。但是我认为这种方案保证幂等性的缺陷比较多,基本不可取。看下面分析 ①、方案介绍 用户通过浏览器发起请求,服务端会收集数据,并且生成订单号code作为唯一业务字段。 使用redis的set命令,将该订单code设置到redis中,同时设置超时时间。 判断是否设置成功,如果设置成功,说明是第一次请求,则进行数据操作。 如果设置失败,说明是重复请求,则直接返回成功。 ②、问题分析 场景一、客户端连续发起两次请求(比如用户快速

wenpan的博客 1万+

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

接口幂等性详解

1.什么是接口幂等 接口幂等性就是用户对同一操作发起了一次或多次请求的对数据的影响是一致不变的,不会因为多次的请求而产生副作用。 副作用:可以认为多次请求操作,每一次对数据状态都会产生影响 。 注意这里并没有要求接口返回结果是一致的。 例如:update order set moeny = 100 where orderId = 2029282312 该操作无论执行多少次,对数据的影响都是一致的,不变的。 接口不做幂等处理会怎样? 支付场景:用户购买商品后,发起支付操作,支付系统处理支付成

qq_29978863的博客 2万+

接口幂等性校验

接口幂等性校验   一、概念 幂等(idempotent、idempotence)是一个数学与计算机学概念,常见于抽象代数中。 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。 这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,“getUsername()和set...

huchao_lingo的博客 1万+

接口幂等性

接口调用存在的问题 现如今我们的系统大多拆分为分布式SOA,或者微服务,一套系统中包含了多个子系统服务,而一个子系统服务往往会去调用另一个服务,而服务调用服务无非就是使用RPC通信或者restful,既然是通信,那么就有可能在服务器处理完毕后返回结果的时候挂掉,这个时候用户端发现很久没有反应,那么就会多次点击按钮,这样请求有多次,那么处理数据的结果是否要统一呢?那是肯定的!尤其在支付场景。 ...

mingwulipo的博客 4万+

接口设计之幂等性设计

幂等性设计 今天我们来聊聊接口的幂等性设计,所谓幂等,就是任意多次执行所产生的影响均与一次执行的影响相同。 幂等性接口是指可以使用相同参数重复执行,并能获得相同结果的接口。这里就不展开数学中的定义了,有兴趣的可以自行google。 为什么接口需要幂等呢? 我们都知道,作为接口的调用方,对于接口调用的结果,一般会返回成功、失败和超时。对于成功和失败,都是明确的状态,调用放可以根据结果做相应的处理,但...

pikaxiao的博客 3万+

接口的幂等性

最近跟朋友聊起这个话题,想深入了解下,于是学习总结,记录下来,此文章参考以下博客综合而来表示感谢: http://blog.brucefeng.info/post/api-idempotent http://825635381.iteye.com/blog/2276077 https://www.cnblogs.com/leechenxiang/p/6626629.html 1. 接口调用...

weixin_33806509的博客 2919
上一篇: 看我并发编程72变,掌握了这72道题(含详细解析),你还怕啥呢?
下一篇: 想用K8s,还得先会Docker吗?其实完全没必要
Java技术那些事儿
博客等级 码龄5年 2306粉丝 2584原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值