客户端重复请求是Web系统中一类很常见的问题，有时我们会发现，前后端都增加了业务校验，但是数据库中仍然有重复数据，这个时候就要怀疑是不是用户重复点击了提交按钮。一些用户请求在某些情况下是可能重复发送的，如果是查询类操作并无大碍，但其中有些涉及写入操作，一旦重复了，可能会导致很严重的后果。例如交易接口如果重复请求，可能会重复下单。
重复的场景有可能有：
黑客重放攻击；
用户在很短时间内重复点击；
网络原因导致网关重发；
重复提交是“幂等”问题的一种，即指用户对于同一操作发起的一次请求或者多次请求的结果是一致的。“幂等”问题还有很大的讨论空间，本文主要讨论的是如何优雅地处理重复提交问题，包括在前端进行处理和在后端进行处理。
前端处理方式
1. UI限制
这是最常见也最简单的处理方式，当用户点击按钮时，将按钮置灰或添加一个页面遮罩（加载动画），直到请求返回后再解锁。
基本的步骤如下：
按钮置灰/添加页面遮罩
发送请求到服务器
接受请求响应
解锁按钮/遮罩
这种方式只能放置正常用户的误操作，无法抵御黑客攻击，黑客很容易就可以绕过前端的锁定。
使用此方式时请注意：
先锁定再发送请求，否则仍然存在时间差可以重复发送请求；
要考虑ajax 的各种返回事件如success, complete, error等，并正确处理返回结果，一旦出现bug，功能将不再可用。例如ajax遇到网络问题或400错误，就不会走到success方法里，这时建议在complete方法里统一解锁；
2. JS闭包节流函数
基本原理是请求设置一个很短时间的延迟发送，在这个延迟的时间范围内，闭包里的setTimeout 与clearTimeout方法,会把上一次连续点击处理的请求清掉，我们的 ajax请求会在最后一次点击后再发出。
示例代码如下：
3. 使用jquery的ajaxPrefilter()方法
使用jquery提供的ajaxPrefilter方法对ajax请求进行拦截，可以在公用的js里配置公用的ajaxPrefilter。全局维护1个request的列表，在ajaxPrefilter中判断要发送的请求是否已经存在，如不存在则发送并将发送中的请求存储到本地，同时覆盖掉传进来的options下的complete属性，在里面包裹上请求完成后踢出队列的处理。
示例代码如下：
后端处理
1. 方法锁
一般我们编写后台代码，都会判重的业务校验，但是极端情况下仍然会有重复提交问题，两个相同的请求可能同一时间通过了业务校验，但都还未入库。此时我们可以使用synchronized关键词，将业务校验+入库方法加锁，这样就算两个请求同时进来，两次请求依次通过，第二次请求也无法通过业务校验。但是此种方法会极大降低系统并发量，高并发系统请慎用。
2. 流水号校验
页面表单加入唯一流水号，后端添加拦截器，校验流水号是否被使用，单机环境可以使用静态map来存储流水号，分布式环境一般使用redis存储流水号。
可以借助redis的key失效功能，实现起来更为方便。我们可以编写一个自定义注解，在所有需要重复校验的地方都可以添加此注解。
具体实现步骤如下：
注解里定义当前用户对当前接口访问最小间隔时间。
用户访问时在拦截器通过redis设置一个key-value-time。Key为用户标识，value随意，time为当前接口上注解里设置的时间，即时间校验间隔。
校验时从redis里通过key获取value，如果能够获取到值，说明前一次请求仍然未超时，则返回被拦截提示。获取不到说明缓存已过期，访问间隔已超过拦截时间，则放行，并重新设置key-value-time拦截时间，预备下一次拦截。
注解核心代码如下：
3. Md5校验
md5校验和上一种方法类似，只不过校验的不是某个参数，而是整个请求url+参数。但是需要注意的是，对参数md5的时候需要将参数排好序，否则顺序不同也会导致md5不同。校验时添加时间校验，保证一定时间内相同请求url和参数只能出现一次。
总结
重复提交校验是web系统必要的功能，本文从前端到后端，介绍了多种实现方式。通常情况下，如果只是普通的web页面，那我们可以直接通过前端校验来解决，但如果是复杂系统或接口类系统，那就需要增加后台校验了。希望本文的内容能够帮助大家健壮自己的系统，少出bug。
作者 | 王月康
视觉 | 王朋玉
统筹 | 郑 洁
