面试官：如何防止重复提交订单？

这个问题，在电商领域的面试场景题下，应该算是妥妥的高频问题了，仅次于所谓的“秒杀场景如何实现”。

说个题外话，有段时间“秒杀场景如何实现”这个问题风靡一时，甚至在面试的时候，有些做财务领域、OA领域公司的面试官也都跟风问。

大有一种”无秒杀，不面试“的感觉了。

重复提交原因

其实原因无外乎两种：

• 
  
• 一种是由于用户在短时间内多次点击下单按钮，或浏览器刷新按钮导致。
  
• 另一种则是由于Nginx或类似于SpringCloud Gateway的网关层，进行超时重试造成的。
  

常见解决方案

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

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

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

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

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

说到底，“下单防重”的问题是属于“接口幂等性”的问题范畴。

幂等性

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

下面的情况就是幂等的：

student.setName("张三");

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

student.increaseAge(1);

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

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

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

但这个方案在“如何防止重复提交订单”就不适用了，需要其他的解决方案，请继续看下文。

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

（1）后端新增一个接口，用于预生成一个“全局唯一订单号”，如：UUID 或 NanoID。

（2）进入创建订单页面时，前端请求该接口，获取该订单号。

（3）在提交订单时，请求参数里要带上这个预生成的“全局唯一订单号”，利用数据库的唯一索引特性，在插入订单记录时，如果该“全局唯一的订单号”重复，记录会插入失败。

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

方案二

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

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

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

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

这种方案是在借鉴了“方案二”的基础上，做了一些实现逻辑的简化。

（1）用户进入下页面时，前端程序自己生成一个“全局唯一订单号”。

（2）在提交订单时，请求参数里要带上这个预生成的“全局唯一订单号”，利用数据库的唯一索引特性，在插入订单记录时，如果该“全局唯一的订单号”重复，记录会插入失败。

方案三

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

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

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

先跟大家探讨一个概念，什么是订单？

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

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

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

Redis命令如下：

SET key value NX EX seconds

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

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

（1）在提交订单时，我们可以把”用户ID + 分隔符 + 商品ID“作为Redis key，并设置过期时间，让它可以到期自动删除。

（2）若Redis命令执行成功，则可以继续走下单的业务逻辑，执行不成功，直接返回给前端”下单失败“就可以了。

方案四

从上图来看，是不是实现方式越来越简单了？

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

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

结语

在真正的生产环境下，我们最终选择了”方案四：从订单业务的本质入手“。

原因很简单，整体改动范围比较小，测试的回归范围也比较可控，且技术方案复杂度最低。

这样做技术选型的话，也比较符合百度一直倡导的”简单可依赖“原则。