如何避免重复提交问题

一、简述

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

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

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

二、理解

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

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

对于每个请求必须有一个唯一的标识。举个例子：订单支付请求，肯定得包含订单 id，一个订单 id 最多支付一次。
每次处理完请求之后，必须有一个记录标识这个请求处理过了。常见的方案是在数据库中记录个状态，比如支付之前记录一条这个订单的支付流水。
每次接收请求需要进行判断，判断之前是否处理过。比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，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 或者 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 PreventReSubmit {
}

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

@Aspect
@Component
@Slf4j
public class UserAspect {@Resourceprivate 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();//获取requestHttpServletRequest 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值为1redisUtil.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("重复提交");}}
}