利用Redis实现防止接口重复提交功能

Posted 2023-05-08

参考技术A

在划水摸鱼之际，突然听到有的用户反映增加了多条一样的数据，这用户立马就不干了，让我们要马上修复，不然就要投诉我们。

这下鱼也摸不了了，只能去看看发生了什么事情。据用户反映，当时网络有点卡，所以多点了几次提交，最后发现出现了十几条一样的数据。

只能说现在的人都太心急了，连这几秒的时间都等不了，惯的。心里吐槽归吐槽，这问题还是要解决的，不然老板可不惯我。

其实想想就知道为啥会这样，在网络延迟的时候，用户多次点击，最后这几次请求都发送到了服务器访问相关的接口，最后执行插入。

既然知道了原因，该如何解决。当时我的第一想法就是用 注解 + AOP 。通过在自定义注解里定义一些相关的字段，比如过期时间即该时间内同一用户不能重复提交请求。然后把注解按需加在接口上，最后在拦截器里判断接口上是否有该接口，如果存在则拦截。

解决了这个问题那还需要解决另一个问题，就是怎么判断当前用户限定时间内访问了当前接口。其实这个也简单，可以使用Redis来做，用户名 + 接口 + 参数啥的作为唯一键，然后这个键的过期时间设置为注解里过期字段的值。设置一个过期时间可以让键过期自动释放，不然如果线程突然歇逼，该接口就一直不能访问。

这样还需要注意的一个问题是，如果你先去Redis获取这个键，然后判断这个键不存在则设置键；存在则说明还没到访问时间，返回提示。这个思路是没错的，但这样如果获取和设置分成两个操作，就不满足原子性了，那么在多线程下是会出错的。所以这样需要把俩操作变成一个原子操作。

分析好了，就开干。

这里为了简单一点，只定义了一个字段 expire ，默认值为3，即3s内同一用户不允许重复访问同一接口。使用的时候也可以传入自定义的值。

我们只需要在对应的接口上添加该注解即可

自定义好了注解，那就该写拦截器了。

拦截器定义的切点是 NoRepeatCommit 注解，所以被 NoRepeatCommit 注解标注的接口就会进入该拦截器。这里我使用了 account + "_" + sessionId + "_" + url + "_" + pg 作为唯一键，表示某个用户访问某个接口。

这样比较关键的一行是 boolean isSuccess = redisLock.tryLock(key, key + sessionId, expire); 。可以看看 RedisLock 这个类。

上面讨论过了，获取锁和设置锁需要做成原子操作，不然并发环境下会出问题。这里可以使用Redis的 SETNX 命令。

在加锁的时候，我使用了 String result = jedis.set(lockKey, userId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime); 。set方法如下

在key不存在的情况下，才会设置key，设置成功则返回OK。这样就做到了查询和设置原子性。

需要注意这里在使用完jedis，需要进行close，不然耗尽连接数就完蛋了，我不会告诉你我把服务器搞挂了。

其实做完这三步差不多了，基本够用。再考虑一些其他情况的话，比如在expire设置的时间内，我这个接口还没执行完逻辑咋办呢？

其实我们不用自己在这整破轮子，直接用健壮的轮子不好吗？比如 Redisson ，来实现分布式锁，那么上面的问题就不用考虑了。有看门狗来帮你做，在键过期的时候，如果检查到键还被线程持有，那么就会重新设置键的过期时间。

Springboot 使用AOP实现防止接口重复提交

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

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

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

切面类需要使用@Aspect和@Component这两个注解做标注。

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