如何避免重复提交问题

一、简述

所谓幂等性,就是一个接口,多次发起同一个请求,该接口得保证结果是准确的,比如不能多扣款、不能多插入一条数据、不能将统计值多统计 1。这就是幂等性。

1️⃣在编程中常见的幂等
①select 查询天然幂等
②delete 删除也是幂等,删除同一个多次效果一样
③update 直接更新某个值的,幂等
④update 更新累加操作的,非幂等
⑤insert 非幂等操作,每次新增一条

2️⃣产生原因:由于重复点击或者网络重发
①点击提交按钮两次
②点击刷新按钮
③使用浏览器后退按钮重复之前的操作,导致重复提交表单
④使用浏览器历史记录重复提交表单
⑤浏览器重复的 HTTP 请求
⑥nginx 重发等情况
⑦分布式 RPC 的 try 重发等

二、理解

1️⃣问题背景
分布式系统中的接口,如何保证幂等性?做分布式系统的时候,这是一个必须要考虑的生产环境的技术问题。
假如有个服务提供付款接口,结果这服务部署在了 5 台机器上。然后用户在前端上操作的时候,不知道为啥,总之就是一个订单不小心发起了两次支付请求,然后该请求分散在了这个服务部署的不同的机器上,结果一个订单扣款两次。
或者是订单系统调用支付系统进行支付,结果不小心因为网络超时了,然后订单系统走了重试机制,支付系统收到一个支付请求两次,而且因为负载均衡算法落在了不同的机器上,问题由此而生。

2️⃣问题剖析
这个不是技术问题,这个没有通用的一个方法,这个应该结合业务来保证幂等性。其实保证幂等性主要是三点:

  1. 对于每个请求必须有一个唯一的标识。举个例子:订单支付请求,肯定得包含订单 id,一个订单 id 最多支付一次。
  2. 每次处理完请求之后,必须有一个记录标识这个请求处理过了。常见的方案是在数据库中记录个状态,比如支付之前记录一条这个订单的支付流水。
  3. 每次接收请求需要进行判断,判断之前是否处理过。比如说,如果有一个订单已经支付了,就已经有了一条支付流水,那么如果重复发送这个请求,则此时先插入支付流水,orderId 已经存在了,唯一键约束生效,报错插入不进去的。然后系统就不用再扣款了。

3️⃣实际运作
实际运作过程中,需要结合自己的业务来,比如说利用 Redis,用 orderId 作为唯一键。只有成功插入这个支付流水,才可以执行实际的支付扣款。

要求是支付一个订单,必须插入一条支付流水。order_id 建 unique key。用户在支付一个订单之前,先插入一条支付流水,order_id 就已经进去了。系统就可以写一个标识到 Redis 里面去,set order_id payed,下一次重复请求过来了,先查 Redis 的 order_id 对应的 value,如果是 payed 就说明已经支付过了,用户就可以避免重复支付了。

三、解决方案

1️⃣前端 js 提交禁止按钮:可以用一些js组件

2️⃣使用Post/Redirect/Get模式
在提交后执行页面重定向,这就是所谓的 Post-Redirect-Get (PRG) 模式。简言之,当用户提交了表单后,去执行一个客户端的重定向,转到提交成功信息页面。这能避免用户按F5导致的重复提交,而且也不会出现浏览器表单重复提交的警告,也能消除按浏览器前进和后退导致的同样问题。

3️⃣在 session 中存放一个特殊标志

在服务器端,生成一个唯一的标识符,将它存入 session,同时将它写入表单的隐藏字段中,然后将表单页面发给浏览器,用户录入信息后点击提交,在服务器端,获取表单中隐藏字段的值,与 session 中的唯一标识符比较,相等说明是首次提交,就处理本次请求,然后将 session 中的唯一标识符移除;不相等说明是重复提交,就不再处理。

4️⃣其他借助使用 header 头设置缓存控制头 Cache-control 等方式

比较复杂,不适合移动端 APP 的应用。

5️⃣借助数据库

insert 使用唯一索引。update 使用乐观锁 version 法。这种在大数据量和高并发下效率依赖数据库硬件能力,可针对非核心业务。

6️⃣借助悲观锁

使用 select … for update 这种和 synchronized 锁住先查再 insert or update 一样,但要避免死锁,效率也较差。针对单体应用,请求并发不大,可以推荐使用。

四、自定义注解@RreventReSubmit

在传统的 web 项目中,防止重复提交,通常做法是:后端生成一个唯一的提交令牌(uuid),并存储在服务端。页面提交请求携带这个提交令牌,后端验证并在第一次验证后删除该令牌,保证提交请求的唯一性。

思路没有问题,但是需要前后端都稍加改动,如果在业务开发完再加这个的话,改动量未免有些大了。无需前端配合,纯后端处理,是最清爽的。设计思路如下:

自定义注解@RreventReSubmit标记所有 Controller 中的提交请求。通过 AOP 对所有标记@RreventReSubmit的方法拦截。在业务方法执行前,获取当前用户的 token(或者JSessionId)+ 当前请求地址,作为一个唯一 KEY,去获取 Redis 分布式锁(如果此时并发获取,只有一个线程会成功获取锁)。当有请求调用接口时,到 Redis 中查找相应的 key,如果能找到,则说明重复提交,如果找不到,则执行操作。业务方法执行后,释放锁。

1️⃣导入aop依赖

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

2️⃣自定义注解

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RreventReSubmit {
}

3️⃣定义切面类:切面类需要使用@Aspect和@Component这两个注解做标注。

@Aspect
@Component
@Slf4j
public class UserAspect {
    @Resource
    private RedisUtil redisUtil;
    @Value("${user.session.key}")
    private String userSessionKey;

    @Pointcut(value = "@annotation(com.xxp.annotation.RreventReSubmit )")
    public void annotationPointCut() {
    }

    @Around("annotationPointCut()")
    public Object NoReSubmit(ProceedingJoinPoint joinPoint) {
        ServletRequestAttributes attributes = 
(ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
        //获取request
        HttpServletRequest request = attributes.getRequest();
        HttpSession session = request.getSession();
        //从session中获取登录的user对象,如果为null,则要求重新登录
        Object sessionUser = session.getAttribute(userSessionKey);
        if (sessionUser == null) {
            return Response.FAIL("页面超时,请重新登录");
        }
        User user = (User) sessionUser;
        Integer userId = user.getId();
        //获取接口的请求参数,如果时Article类型,则保存为Article对象,使用Article对象里的title属性
        Object[] args = joinPoint.getArgs();
        Article article = null;
        for (Object object : args) {
            if (object instanceof Article) {
                article = (Article) object;
            }
        }
        if (args == null) {
            return Response.FAIL("请求参数错误");
        }
        //组装redis key 从redis中获取对应的值
        String key = userId + "_" + article.getTitle();
        Object flag = redisUtil.getStr(key);
        //如果redis中不存在对应的值,则执行原有的代码逻辑(插入文章操作)
        if (flag == null) {
            //redis设置key,value值为1
            redisUtil.setStr(key, "1");
            //设置有效期为5分钟
            redisUtil.strSetExpireSeconds(key, 5 * 60L);
            try {
                return joinPoint.proceed();
            } catch (Throwable throwable) {
                redisUtil.delStr(key);
                return Response.FAIL("系统错误,请联系管理员!");
            }
        } else {
            //如果redis中存在对应的值,则证明重复提交,返回对应的信息
            log.info("{}:重复提交", key);
            return Response.FAIL("重复提交");
        }
    }
}

在想要防止重复提交的接口上添加注解即可使用。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,980评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,178评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,868评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,498评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,492评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,521评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,910评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,569评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,793评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,559评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,639评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,342评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,931评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,904评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,144评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,833评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,350评论 2 342