产生的原因
- 一种是由于用户在短时间内多次点击下单按钮，或浏览器刷新按钮导致。
- 另一种则是由于Nginx或类似于SpringCloud Gateway的网关层，进行超时重试造成的。
- 由于网速等原因造成页面卡顿，用户重复刷新提交页面
- 黑客或恶意用户使用 postman 等网络工具，重复恶意提交表单
解决方案
方案一：提交订单按钮置灰
这种解决方案在注册登录的场景下比较常见，当我们点击”发送验证码“按钮的时候，会进行手机短信验证码发送，且按钮就会有一分钟左右的置灰。
有些经验不太丰富的同学，通常会简单粗暴地把这个方案直接照搬过来。
但这种方案只能解决多次点击下单按钮的问题，对于Nginx或类似于SpringCloud Gateway的超时重试所导致的问题是无能为力的。
当然，这种方案也不是真的没有价值。它可以在高并发场景下，从浏览器端去拦住一部分请求，减少后端服务器的处理压力。
幂等性
接口幂等性是指：以相同的参数，对一个接口进行多次调用，所产生的结果和一次调用是完全相同的。
下面的情况就是幂等的：
student.setName("张三");
而这种情况就是非幂等的，因为每次调用，年龄都会增加一岁。
student.increaseAge(1);
现在我们的思路需要切换到幂等性的解决方案来。
同样是幂等性场景，“如何防止重复提交订单” 比 “如何防止订单重复支付” 的解决方案要难一些。
因为，后者在常规情况下，一个订单都是对应一笔支付单，所以orderID可以作为一个幂等性校验、防止订单重复支付的天然神器。
但这个方案在“如何防止重复提交订单”就不适用了，
方案二：预生成全局唯一订单号
- 后端新增一个接口，用于预生成一个“全局唯一订单号”，如：UUID 或 NanoID。
- 进入创建订单页面时，前端请求该接口，获取该订单号。
- 在提交订单时，请求参数里要带上这个预生成的“全局唯一订单号”，利用数据库的唯一索引特性，在插入订单记录时，如果该“全局唯一的订单号”重复，记录会插入失败。
该“全局唯一订单号”不能代替数据库主键，在未分库分表场景下，主键还是用数据库自增ID比较好。
优点：彻底解决了重复下单的问题；
缺点：方案复杂，前后端都有开发工作量，还要新增接口，新增字段。
网上还有同学说，要单独弄一个生成“全局唯一订单号”的服务，我觉得还是免了吧，这不是更麻烦了吗？
方案三：前端生成全局唯一订单号
- 用户进入下页面时，前端程序自己生成一个“全局唯一订单号”。
- 在提交订单时，请求参数里要带上这个预生成的“全局唯一订单号”，利用数据库的唯一索引特性，在插入订单记录时，如果该“全局唯一的订单号”重复，记录会插入失败。
优点：彻底解决了重复下单的问题，且技术方案做了一定简化；
缺点：前后端仍然都有开发工作量，且需要新增字段；
方案四：从订单业务的本质入手
订单就是某个用户用特定的价格购买了某种商品，即：用户和商品的连接。
那么，“如何防止重复提交订单”，其实就是防止在短时间内，用户和商品进行多次连接。弄明白问题本质，接下来我们就着手制定技术方案了。
可以用 ”用户ID + 分隔符 + 商品ID“ 作为唯一标识，让持有相同标识的请求在短时间内不能重复下单，不就可以了吗？而且，Redis不正是做这种解决方案的利器吗？
把”用户ID + 分隔符 + 商品ID“作为Redis key，并把”短时间所对应的秒数“设置为seconds，让它过期自动删除。
这样一来，整体业务步骤如下：
- 在提交订单时，我们可以把”用户ID + 分隔符 + 商品ID“作为Redis key，并设置过期时间，让它可以到期自动删除。
- 若Redis命令执行成功，则可以继续走下单的业务逻辑，执行不成功，直接返回给前端”下单失败“就可以了。
优点：彻底解决了重复下单的问题，且在技术方案上，不需要前端参与，不需要添加接口，不需要添加字段；
缺点：综合比较而言，暂无明显缺点，如果硬要找缺点的话，可能强依赖于Redis勉强可以算上吧；
结语
在真正的生产环境下，我们最终选择了 方案四 ,从订单业务的本质入手“。原因很简单，整体改动范围比较小，测试的回归范围也比较可控，且技术方案复杂度最低。这样做技术选型的话，也比较符合百度一直倡导的”简单可依赖“原则。
以上参考文章：如何防止重复提交订单？ - 掘金
方案五
下面我们以防止重复提交订单为例，向大家介绍最简单的、成本最低的解决办法。
我们先来看一张图，这张图就是本次方案的核心流程图。
实现的逻辑，流程如下：
- 当用户进入订单提交界面的时候，调用后端获取请求唯一ID，并将唯一ID值埋点在页面里面
- 当用户点击提交按钮时，后端检查这个唯一ID是否用过，如果没有用过，继续后续逻辑；如果用过，就提示重复提交
- 最关键的一步操作，就是把这个唯一ID 存入业务表中，同时设置这个字段为唯一索引类型，从数据库层面做防止重复提交
对于下单流量不算高的系统，可以采用这种请求唯一ID+数据表增加唯一索引约束的方式，来防止接口重复提交！虽然简单粗暴，但是十分有效！
方案六
这张图就是本次方案的核心流程图
实现的逻辑，流程如下：
- 1.当用户进入订单提交界面的时候，调用后端获取请求唯一 ID，同时后端将请求唯一ID存储到
redis中再返回给前端，前端将唯一 ID 值埋点在页面里面 - 2.当用户点击提交按钮时，后端检查这个请求唯一 ID 是否存在，如果不存在，提示错误信息；如果存在，继续后续检查流程
- 3.使用
redis的分布式锁服务，对请求 ID 在限定的时间内进行加锁，如果加锁成功，继续后续流程；如果加锁失败，说明服务正在处理，请勿重复提交 - 4.最后一步，如果加锁成功后，需要将锁手动释放掉，以免再次请求时，提示同样的信息；同时如果任务执行成功，需要将
redis中的请求唯一 ID 清理掉 - 5.至于数据库是否需要增加字段唯一索引，理论上可以不用加，如果加了更保险
引入缓存服务，防止重复提交的大体思路如上，实践代码如下！
…….
整套方案完全基于redis来实现，同时结合redis的分布式锁来实现请求限流，之所以选择redis，是因为它是一个内存数据库，性能比关系型数据库强太多，即使每秒的下单请求量在几千，也能很好的应对，为关系型数据库起到降压作用！
特别注意的地方：使用redis的分布式锁，推荐单机环境，如果redis是集群环境，可能会导致锁短暂无效！
随着下单流量逐渐上升，通过查询数据库来检查当前服务请求是否重复提交这种方式，可能会让数据库的请求查询频率变得非常高，数据库的压力会倍增。
此时我们可以引入redis缓存，将通过查询数据库来检查当前请求是否重复提交这种方式，转移到通过查询缓存来检查当前请求是否重复提交，可以很好的给数据库降压！
方案七
在上一篇文章中，我们详细的介绍了随着下单流量逐渐上升，为了降低数据库的访问压力，通过请求唯一ID+redis分布式锁来防止接口重复提交
每次提交的时候，需要先调用后端服务获取请求唯一ID，然后才能提交。
对于这样的流程，不少的同学可能会感觉到非常鸡肋，尤其是单元测试，需要每次先获取submitToken值，然后才能提交！
能不能不用这么麻烦，直接服务端通过一些规则组合，生成本次请求唯一ID呢？
答案是可以的！
今天我们就一起来看看，如何通过服务端来完成请求唯一 ID 的生成？
我们先来看一张图，这张图就是本次方案的核心流程图。
实现的逻辑，流程如下：
- 用户点击提交按钮，服务端接受到请求后，通过规则计算出本次请求唯一ID值
- 使用
redis的分布式锁服务，对请求 ID 在限定的时间内尝试进行加锁，如果加锁成功，继续后续流程；如果加锁失败，说明服务正在处理，请勿重复提交 - 最后一步，如果加锁成功后，需要将锁手动释放掉，以免再次请求时，提示同样的信息
引入缓存服务后，防止重复提交的大体思路如上，实践代码如下！
……
其中最关键的一个步就是将唯一请求 ID 的生成，放在服务端通过组合来实现，在保证防止接口重复提交的效果同时，也可以显著的降低接口测试复杂度！
小结
本次方案相比于上一个方案，最大的改进点在于：将接口请求唯一 ID 的生成逻辑，放在服务端通过规则组合来实现，不需要前端提交接口的时候强制带上这个参数，在满足防止接口重复提交的要求同时，又能减少前端和测试提交接口的复杂度！
以上参考文章
如何防止用户重复提交订单？（上） - 程序员志哥 - 博客园
如何防止用户重复提交订单？（中） - 程序员志哥 - 博客园
如何防止用户重复提交订单？（下） - 程序员志哥 - 博客园
