【浅谈电商】如何防止重复下单

【浅谈电商】如何防止重复下单

一、前言

最近正在做电商相关的项目，整理一下解决方案并帮助自己巩固知识点，此方案是结合了目前的业务环境，若有更好的解决的方式很高兴与大家一起讨论。

二、什么是重复下单

首先我们要知道什么时候是下单操作。以JD为例：

购物车 -> 结算页面 -> 下单页面

• 购物车：购物车
• 结算页面：此页面可以查看待支付金额，使用的优惠券，填写地址，运费等等。
• 下单页面：此页面可以选择结算方式，并且页面展示付款倒计时，也就是说订单已经创建完成。

在下单页面时，由于用户点击下单按钮多次、或者重试策略导致在订单服务中接收到了两次同样的下单请求。

三、如何处理重复下单

重复下单场景，第二次的下单会对数据进行打乱，导致系统整体数据异常

理想的情景：

找到了问题的根本原因就可以有针对性的去解决问题。

令牌桶

面对用户的多次点击/提交/刷新页面等操作时，我们可以添加一个防重令牌的操作。每次操作前，给当前用户一个一次性的令牌，点击提交时带着令牌一起，后端会先去校验令牌的有效性，这样来避免恶意刷提交。由于令牌的有效性就好比前朝的尚方宝剑也无法斩本朝的官^_

上述的操作在一定程度上可以解决重复提交的问题，假如当一个人的速度足够快，也是可以合理去提交一个一模一样的订单，这个时候就需要使用缓存的方式防重。

Redis

当用户下单时，去Redis中获取一个锁，即一个标识，同一时间只能有一个人能获取到。获取到之后才可以进行后续的逻辑，例如清除购物车、标记消费券等。若此时另外一个下单请求突破防线进入了系统，首先它需要去Redis获取锁，然而锁已经被占用了，它获取不到直接就返回失败。这里主要保证的是接口幂等性。

小结

• 令牌桶：可以防止用户很快的提交请求，主要解决的是防重。
• Redis：可以使同一时间只有一个下单逻辑在运行（同一用户下），主要解决的是接口幂等性。

ps:锁的含义更像一个标识，有了它你可以为所欲为，没有它什么也做不了。