正如本文标题所言，今天我们来聊一聊在Java应用系统中如何防止接口重复提交；简单地讲，这其实就是“重复提交”的话题，本文将从以下几个部分展开介绍：
1.“重复提交”简介与造成的后果
2.“防止接口重复提交”的实现思路
3.“防止接口重复提交”的代码实战
一、“重复提交”简介与造成的后果
对于“重复提交”，想必各位小伙伴都知晓它的意思，简单的理解，它指的是前端用户在间隔很短的时间周期内对同一个请求URL发起请求，导致前端开发者在很短的时间周期内将同一份数据（请求体）提交到后端相同的接口 多次，最终数据库出现多条主键ID不一样而其他业务数据几乎一毛一样的记录；
仔细研究上述整个过程，会发现如果发起的多次请求的时间间隔足够短，即时间趋向于无穷小 时，其过程可以归为“多线程并发导致并发安全”的问题范畴；而对于“并发安全”的话题，debug早在此前自己录制的课程以及之前的文章中介绍过多次了，在此不再赘述；
上述在对“重复提交”的介绍中隐约也提及它所带来的的后果：
（1）数据库DB出现多条一毛一样的数据记录；
（2）如果重复发起的请求足够多、请求体容量足够大，很可能会给系统接口带来极大的压力，导致其出现“接口不稳定”、“DB负载过高”，严重点甚至可能会出现“系统宕机”的情况；
因此，我们需要在一些很可能会出现“重复提交”的后端接口中加入一些处理机制（附注：前端其实也需要配合一同处理的，其处理方式在本文就不做介绍了~）；
二、“防止接口重复提交”的实现思路
对于“重复提交”，想必各位小伙伴都知晓它的意思，简单的理解，它指的是前端用户在间隔很短的时间周期内对同一个请求URL发起请求，导致前端开发者在很短的时间周期内将同一份数据（请求体）提交到后端相同的接口 多次，最终数据库出现多条主键ID不一样而其他业务数据几乎一毛一样的记录；
仔细研究上述整个过程，会发现如果发起的多次请求的时间间隔足够短，即时间趋向于无穷小 时，其过程可以归为“多线程并发导致并发安全”的问题范畴；而对于“并发安全”的话题，debug早在此前自己录制的课程以及之前的文章中介绍过多次了，在此不再赘述；
上述在对“重复提交”的介绍中隐约也提及它所带来的的后果：
（1）数据库DB出现多条一毛一样的数据记录；
（2）如果重复发起的请求足够多、请求体容量足够大，很可能会给系统接口带来极大的压力，导致其出现“接口不稳定”、“DB负载过高”，严重点甚至可能会出现“系统宕机”的情况；
因此，我们需要在一些很可能会出现“重复提交”的后端接口中加入一些处理机制（附注：前端其实也需要配合一同处理的，其处理方式在本文就不做介绍了~）；
值得一提的是，绝大部分情况下，只有POST/PUT/DELETE的请求方式才会出现“重复提交”的情况，而对于GET请求方式，只要不是出现人为的意外情况，那么它就具有“幂等性”，谈不上“重复提交”现象的出现，因此，在实际项目中，出现“重复提交”现象比较多的一般是POST请求方式；
而在实际项目开发中，“防止接口重复提交”的实现方式有两类，一类是纯粹的针对请求链接URL的，即防止对同一个URL发起多次请求：此种方式明显粒度过大，容易误伤友军；另一类是针对请求链接URL + 请求体 的，这种方式可以说是比较人性化而且也是比较合理的，而我们在后面要介绍的实现方式正是基于此进行实战的；
为了便于小伙伴理解，接下来我们以“用户在前端提交注册信息”为例，介绍“如何防止接口重复提交”的实现思路，如下图所示为整体的实现思路：
从该图中可以得知，如果当前提交的请求URL已经存在于缓存中，且 当前提交的请求体 跟 缓存中该URL对应的请求体一毛一样 且 当前请求URL的时间戳跟上次相同请求URL的时间戳 间隔在8s 内，即代表当前请求属于 “重复提交”；如果这其中有一个条件不成立，则意味着当前请求很有可能是第一次请求，或者已经过了8s时间间隔的 第N次请求了，不属于“重复提交”了。
三、“防止接口重复提交”的实现思路
照着这个思路，接下来我们将采用实际的代码进行实战，其中涉及到的技术：Spring Boot2.0 + 自定义注解 + 拦截器 + 本地缓存（也可以分布式缓存）；
更多请见：http://www.mark-to-win.com/tutorial/51079.html
