【场景题】如何防止重复下单

1. 如何防止重复下单

当网络出现了阻塞用户不断点击下单按钮，出现了重复下单，应该如何去防止呢?
普通的下单流程，首先会由用户发起一个下单操作，然后会由订单服务去保存一条订单信息，此时订单的状态是【未支付】，然后再由用户去确认订单。由支付服务把当前这条订单修改为【待支付】，然后再跳转到支付界面，接着由用户去选择对应的支付方式，来进行钱包支付。支付完成之后呢，由支付平台进行回调，回调到支付服务，再去调用订单服务，修改状态为【已支付】。

哪一步会出现重复操作，而出现幂等性操作呢？
只有在用户下单的哪一步会出现这个问题！

2. ✅ 方案一：数据库唯一索引

适用场景：同一个用户 + 同一个业务条件 只能有一个订单

例如：

UNIQUEKEYuk_user_product(user_id,product_id,biz_type)或者：UNIQUEKEYuk_order_no(order_no)

Java 代码：

try{orderMapper.insert(order);}catch(DuplicateKeyExceptione){// 已存在订单，直接查询返回returnorderMapper.selectByBizKey(...);}

✅ 优点：

• 简单
• 绝对可靠
• 不怕并发

❗注意：
一定要以数据库为最终裁决者。

3. ✅ 方案二：前端防抖（只是辅助）

• 提交后按钮 disabled
• loading
• 防抖 1~2 秒

但这只是体验优化，不是安全方案。

4. ✅ 方案三：Token 防重复提交（常见）

流程：

1. 用户进入下单页
2. 服务端生成一个 UUID token
3. 存 Redis（有效期 5 分钟）
4. 下单时必须携带该 token
5. 使用 Lua 脚本原子校验并删除

Redis Lua：

ifredis.call('get',KEYS[1])==ARGV[1]thenreturnredis.call('del',KEYS[1])elsereturn0end

Java 逻辑：

• 如果返回 1 → 允许下单
• 如果返回 0 → 重复请求

✅ 优点：

• 抗前端重复点击
• 抗接口重试

❗缺点：

• 不能防止真正的并发写库冲突
• 还是要配合数据库唯一索引

==============================================
优雅的使用Redission来解决问题

1. 先说清楚：Token 防重复提交在干嘛？
   同一个页面，在短时间内，用户重复点“提交”按钮。
   流程本质是：

① 页面加载 → 后端生成一个 token ② token 存 Redis（设置过期时间） ③ 用户提交时必须带这个 token ④ 后端校验 token 是否存在 ⑤ 校验成功 → 删除 token → 继续执行 ⑥ 再次提交 → token 不存在 → 拒绝

核心点：token 必须“校验 + 删除”原子执行 否则会并发通过。

2. 标准 Redisson 实现

第一步：生成 token

@GetMapping("/order/token")publicStringgenerateToken(){Stringtoken=UUID.randomUUID().toString();RBucket<String>bucket=redissonClient.getBucket("order:token:"+token);bucket.set("1",5,TimeUnit.MINUTES);returntoken;}

第二步：下单时校验 token
⚠️ 关键点：必须原子删除
Redisson 有一个非常好用的方法：

// 这是原子的！！！bucket.getAndDelete()

最终代码

@PostMapping("/order")publicStringcreateOrder(@RequestParamStringtoken){RBucket<String>bucket=redissonClient.getBucket("order:token:"+token);Stringvalue=bucket.getAndDelete();// 原子操作if(value==null){thrownewRuntimeException("请勿重复提交");}// 执行业务逻辑return"下单成功";}

为什么 getAndDelete 是安全的？

Redis内部执行： GET key DEL key 但在Redisson中是用Lua保证原子执行的。 所以： 第一次请求 → 拿到值 → 删除成功 第二次请求 → key 已不存在 → 返回null不会出现并发穿透。

4. ✅ 方案四：订单状态机控制（核心）

订单必须有明确状态：

INIT → PAYING → PAID → CANCELLED

创建订单前：

select*from order where user_id=?and product_id=?and status in('INIT','PAYING')

存在则直接返回已有订单。这是业务级幂等。

5. ✅ 方案五：分布式锁（高并发场景）

RLocklock=redisson.getLock("order:"+userId);lock.lock();try{// 查询是否已有订单// 创建订单}finally{lock.unlock();}

适用场景：

• 秒杀
• 抢购
• 打车平台
• 库存扣减
  ❗但要注意锁粒度（不要锁全局）

6. 真正生产级推荐组合方案

前端防抖(置灰) + Token 防重复 + 数据库唯一索引 + 订单状态机控制

7. 不同业务推荐方案