没想到，秒杀系统就这么被阿里两份文档给”安排“的明明白白的_黑名单校验兜底 方案

前言

之前一直有小伙伴私信我问我高并发场景下的订单和库存处理方案，我最近也是因为加班的原因比较忙，就一直没来得及回复。今天好不容易闲了下来想了想不如写篇文章把这些都列出来的，让大家都能学习到，说一千道一万都不如满满的干货来的实在，干货都下面了！

介绍

前提：分布式系统，高并发场景
商品A只有100库存，现在有1000或者更多的用户购买。如何保证库存在高并发的场景下是安全的。
预期结果：1.不超卖 2.不少卖 3.下单响应快 4.用户体验好

下单思路：

1. 下单时生成订单，减库存，同时记录库存流水，在这里需要先进行库存操作再生成订单数据，这样库存修改成功，响应超时的特殊情况也可以通过第四步定时校验库存流水来完成最终一致性。
2. 支付成功删除库存流水，处理完成删除可以让库存流水数据表数据量少，易于维护。
3. 未支付取消订单，还库存+删除库存流水
4. 定时校验库存流水，结合订单状态进行响应处理，保证最终一致性

（退单有单独的库存流水，申请退单插入流水，退单完成删除流水+还库存）

什么时候进行减库存

• 方案一：加购时减库存。
• 方案二：确认订单页减库存。
• 方案三：提交订单时减库存。
• 方案四：支付时减库存。

分析：

• 方案一：在这个时间内加入购物车并不代表用户一定会购买,如果这个时候处理库存，会导致想购买的用户显示无货。而不想购买的人一直占着库存。显然这种做法是不可取的。唯品会购物车锁库存，但是他们是另一种做法，加入购物车后会有一定时效，超时会从购物车清除。
• 方案二：确认订单页用户有购买欲望，但是此时没有提交订单，减库存会增加很大的复杂性，而且确认订单页的功能是让用户确认信息，减库存不合理，希望大家对该方案发表一下观点，本人暂时只想到这么多。
• 方案三：提交订单时减库存。用户选择提交订单，说明用户有强烈的购买欲望。生成订单会有一个支付时效，例如半个小时。超过半个小时后，系统自动取消订单，还库存。
• 方案四：支付时去减库存。比如：只有100个用户可以支付，900个用户不能支付。用户体验太差，同时生成了900个无效订单数据。

所以综上所述：
选择方案三比较合理。

重复下单问题

1. 用户点击过快，重复提交。
2. 网络延时，用户重复提交。
3. 网络延时高的情况下某些框架自动重试，导致重复请求。
4. 用户恶意行为。

解决办法

1. 前端拦截，点击后按钮置灰。
2. 后台：
   (1）redis 防重复点击，在下单前获取用户token，下单的时候后台系统校验这个 token