如何防止重复提交订单

产生的原因

• 一种是由于用户在短时间内多次点击下单按钮，或浏览器刷新按钮导致。
• 另一种则是由于Nginx或类似于SpringCloud Gateway的网关层，进行超时重试造成的。
• 由于网速等原因造成页面卡顿，用户重复刷新提交页面
• 黑客或恶意用户使用 postman 等网络工具，重复恶意提交表单

解决方案

方案一：提交订单按钮置灰

这种解决方案在注册登录的场景下比较常见，当我们点击”发送验证码“按钮的时候，会进行手机短信验证码发送，且按钮就会有一分钟左右的置灰。

有些经验不太丰富的同学，通常会简单粗暴地把这个方案直接照搬过来。

但这种方案只能解决多次点击下单按钮的问题，对于Nginx或类似于SpringCloud Gateway的超时重试所导致的问题是无能为力的。

当然，这种方案也不是真的没有价值。它可以在高并发场景下，从浏览器端去拦住一部分请求，减少后端服务器的处理压力。

幂等性

接口幂等性是指：以相同的参数，对一个接口进行多次调用，所产生的结果和一次调用是完全相同的。

下面的情况就是幂等的：

student.setName("张三");

而这种情况就是非幂等的，因为每次调用，年龄都会增加一岁。

student.increaseAge(1);

现在我们的思路需要切换到幂等性的解决方案来。

同样是幂等性场景，“如何防止重复提交订单” 比 “如何防止订单重复支付” 的解决方案要难一些。

因为，后者在常规情况下，一个订单都是对应一笔支付单，所以orderID可以作为一个幂等性校验、防止订单重复支付的天然神器。

但这个方案在“如何防止重复提交订单”就不适用了，

方案二：预生成全局唯一订单号

1. 后端新增一个接口，用于预生成一个“全局唯一订单号”，如：UUID 或 NanoID。
2. 进入创建订单页面时，前端请求该接口，获取该订单号。
3. 在提交订单时，请求参数里要带上这个预生成的“全局唯一订单号”，利用数据库的唯一索引特性，在插入订单记录时，如果该“全局唯一的订单号”重复，记录会插入失败。

该“全局唯一订单号”不能代替数据库主键，在未分库分表场景下，主键还是用数据库自增ID比较好。

优点：彻底解决了重复下单的问题；

缺点：方案复杂，前后端都有开发工作量，还要新增接口，新增字段。

网上还有同学说，要单独弄一个生成“全局唯一订单号”的服务，我觉得还是免了吧，这不是更麻烦了吗？

方案三：前端生成全局唯一订单号

1. 用户进入下页面时，前端程序自己生成一个“全局唯一订单号”。
2. 在提交订单时，请求参数里要带上这个预生成的“全局唯一订单号”，利用数据库的唯一索引特性，在插入订单记录时，如果该“全局唯一的订单号”重复，记录会插入失败。

优点：彻底解决了重复下单的问题，且技术方案做了一定简化；

缺点：前后端仍然都有开发工作量，且需要新增字段；

方案四：从订单业务的本质入手

订单就是某个用户用特定的价格购买了某种商品，即：用户和商品的连接。

那么，“如何防止重复提交订单”，其实就是防止在短时间内，用户和商品进行多次连接。弄明白问题本质，接下来我们就着手制定技术方案了。

可以用 ”用户ID + 分隔符 + 商品ID“ 作为唯一标识，让持有相同标识的请求在短时间内不能重复下单，不就可以了吗？而且，Redis不正是做这种解决方案的利器吗？

把”用户ID + 分隔符 + 商品ID“作为Redis key，并把”短时间所对应的秒数“设置为seconds，让它过期自动删除。

这样一来，整体业务步骤如下：

1. 在提交订单时，我们可以把”用户ID + 分隔符 + 商品ID“作为Redis key，并设置过期时间，让它可以到期自动删除。
2. 若Redis命令执行成功，则可以继续走下单的业务逻辑，执行不成功，直接返回给前端”下单失败“就可以了。

优点：彻底解决了重复下单的问题，且在技术方案上，不需要前端参与，不需要添加接口，不需要添加字段；

缺点：综合比较而言，暂无明显缺点，如果硬要找缺点的话，可能强依赖于Redis勉强可以算上吧；

结语

在真正的生产环境下，我们最终选择了 方案四 ,从订单业务的本质入手“。原因很简单，整体改动范围比较小，测试的回归范围也比较可控，且技术方案复杂度最低。这样做技术选型的话，也比较符合百度一直倡导的”简单可依赖“原则。

以上参考文章：如何防止重复提交订单？ - 掘金

---

方案五

下面我们以防止重复提交订单为例，向大家介绍最简单的、成本最低的解决办法。

我们先来看一张图，这张图就是本次方案的核心流程图。

实现的逻辑，流程如下：

1. 当用户进入订单提交界面的时候，调用后端获取请求唯一ID，并将唯一ID值埋点在页面里面
2. 当用户点击提交按钮时，后端检查这个唯一ID是否用过，如果没有用过，继续后续逻辑；如果用过，就提示重复提交
3. 最关键的一步操作，就是把这个唯一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 的生成？

我们先来看一张图，这张图就是本次方案的核心流程图。

实现的逻辑，流程如下：

1. 用户点击提交按钮，服务端接受到请求后，通过规则计算出本次请求唯一ID值
2. 使用redis的分布式锁服务，对请求 ID 在限定的时间内尝试进行加锁，如果加锁成功，继续后续流程；如果加锁失败，说明服务正在处理，请勿重复提交
3. 最后一步，如果加锁成功后，需要将锁手动释放掉，以免再次请求时，提示同样的信息

引入缓存服务后，防止重复提交的大体思路如上，实践代码如下！

……

其中最关键的一个步就是将唯一请求 ID 的生成，放在服务端通过组合来实现，在保证防止接口重复提交的效果同时，也可以显著的降低接口测试复杂度！

小结

本次方案相比于上一个方案，最大的改进点在于：将接口请求唯一 ID 的生成逻辑，放在服务端通过规则组合来实现，不需要前端提交接口的时候强制带上这个参数，在满足防止接口重复提交的要求同时，又能减少前端和测试提交接口的复杂度！

以上参考文章

如何防止用户重复提交订单？（上） - 程序员志哥 - 博客园

如何防止用户重复提交订单？（中） - 程序员志哥 - 博客园

如何防止用户重复提交订单？（下） - 程序员志哥 - 博客园

---