今天我就把压箱底的库存抢购防超卖方案分享给你,从原理到实战,保证说得明明白白,就算是刚入行的同学也能听懂。
一、先搞懂:为什么会出现超卖少买?
库存抢购看似简单,实则藏着不少坑:
- 并发请求量大:秒杀活动瞬间可能有10万+QPS,数据库根本扛不住
- 读取库存延迟:用户看到的库存和实际库存不同步
- 更新库存冲突:多个用户同时抢购最后一件商品
- 业务逻辑漏洞:比如先创建订单后扣减库存
- 网络延迟:请求到达顺序和用户操作顺序不一致
举个例子:库存剩1件,用户A和用户B同时抢购。数据库先收到A的请求,查询库存还有1件,准备扣减;同时B的请求也来了,查询库存还是1件。结果就是A和B都成功下单,库存变成-1,超卖了!
二、架构设计:多层防护才能稳如泰山
解决超卖问题,靠单一方法肯定不行,必须上「组合拳」:
1. 前端层:过滤无效请求
- 限流:限制同一用户单位时间内的请求次数
- 防重复提交:禁止短时间内重复点击
- 倒计时同步:确保所有用户看到的倒计时一致
- 静态资源缓存:减少服务器压力
// 前端防重复提交示例 let isSubmitting = false; document.getElementById('buyBtn').addEventListener('click', function() { if (isSubmitting) return; isSubmitting = true; this.disabled = true; this.innerHTML = '抢购中...'; // 发送请求 fetch('/api/seckill', { method: 'POST', body: JSON.stringify({ productId: 123 }) }).then(response => { // 处理响应 }).finally(() => { isSubmitting = false; this.disabled = false; this.innerHTML = '立即抢购'; }); });
2. 后端层:核心业务逻辑防护
- 请求队列:使用Redis或Kafka将请求排队,依次处理
- 库存预扣减:先扣减库存,再创建订单
- 事务隔离:确保库存查询和扣减在同一事务中
- 库存校验:创建订单前再次校验库存
3. 数据层:最终保障
- 数据库锁:使用悲观锁或乐观锁
- 库存预热:将库存加载到Redis中
- Redis原子操作:使用Lua脚本确保库存扣减的原子性
三、核心技术点:解决超卖的3大杀器
1. 乐观锁:高并发场景的首选
乐观锁假设不会发生冲突,只有在提交时才检查冲突。适合读多写少的场景。
实现方式:给库存表加一个版本号字段
-- 乐观锁更新库存 UPDATE product_stock SET stock = stock - 1, version = version + 1 WHERE product_id = 123 AND stock > 0 AND version = #{version};
如果更新成功,说明没有冲突;如果更新失败,说明有其他请求已经修改了库存,需要重试或返回失败。
2. Redis原子操作:高性能保障
Redis的decr命令是原子的,可以用来扣减库存:
// Redis扣减库存示例 Long stock = redisTemplate.opsForValue().decr("product:stock:123"); if (stock >= 0) { // 库存扣减成功 return true; } else { // 库存不足,回滚 redisTemplate.opsForValue().incr("product:stock:123"); return false; }
更安全的方式是使用Lua脚本,确保库存检查和扣减在一个原子操作中完成:
-- Lua脚本扣减库存 local stock = redis.call('get', KEYS[1]) if not stock or tonumber(stock) <= 0 then return 0 end redis.call('decr', KEYS[1]) return 1
3. 队列削峰:将并发请求串行化
使用消息队列(如Kafka、RocketMQ)将抢购请求排队,然后由消费者按顺序处理:
// 发送抢购请求到队列 kafkaTemplate.send("seckill_topic", new SeckillMessage(userId, productId)); // 消费者处理抢购请求 @KafkaListener(topics = "seckill_topic") public void handleSeckill(SeckillMessage message) { // 扣减库存 boolean success = seckillService.reduceStock(message.getProductId()); if (success) { // 创建订单 orderService.createOrder(message.getUserId(), message.getProductId()); } else { // 返回库存不足 notificationService.sendFailMessage(message.getUserId()); } }
四、架构演进:从简单到复杂
- 初级阶段:只在数据库层面加锁,性能低
- 中级阶段:引入Redis缓存库存,提高读取性能
- 高级阶段:使用消息队列削峰,保护数据库
- 终极阶段:多级缓存+队列+分布式锁,支持百万级并发
五、实战经验:这些坑你必须避开
- 不要迷信强一致性:强一致性会牺牲性能,大部分场景最终一致性足够
- Redis不是万能的:必须考虑Redis故障的情况,有降级方案
- 库存不能只存在缓存中:必须同步到数据库,确保数据持久化
- 不要忽视超时问题:设置合理的超时时间,避免长时间阻塞
- 防刷单是关键:识别恶意请求,比如同一IP多次抢购
- 测试是王道:使用压测工具模拟高并发场景,提前发现问题
六、经典案例:某电商平台的秒杀系统
某头部电商平台的秒杀系统架构:
- 前端使用CDN缓存静态资源,减少服务器压力
- 接入层使用Nginx限流,过滤无效请求
- 应用层使用Redis预扣减库存,Lua脚本确保原子性
- 消息队列使用Kafka,将请求串行化处理
- 数据库使用分库分表,提高并发处理能力
- 建立了完善的监控体系,实时监控库存和订单情况
这套架构支持每秒10万+的并发请求,库存准确率100%,从未发生过超卖问题。