高并发下防超卖的核心是保证扣减原子性与库存非负，需数据库行锁+乐观锁兜底、Redis+Lua原子预扣减、分布式锁+状态机协同控制。

高并发下库存扣减与防超卖，核心是保证“扣减操作的原子性”和“库存不出现负数”。不能只靠应用层加锁或简单判断，必须结合数据库、缓存、分布式协调等多层手段协同控制。

数据库层面：利用行锁 + 乐观锁兜底

直接在数据库执行带条件的更新是最可靠的基础防线。例如 MySQL 中用 UPDATE ... WHERE stock > 0，并检查影响行数是否为 1：

• SQL 示例：UPDATE item SET stock = stock - 1 WHERE id = ? AND stock > 0
• 执行后判断 affectedRows == 1，否则说明库存不足或已被抢完
• 配合唯一索引或主键，确保 InnoDB 对单行加行级写锁，避免并发更新覆盖
• 若业务允许版本控制，可加 version 字段实现乐观锁：WHERE id = ? AND stock > 0 AND version = ?，更新成功后 version + 1

Redis + Lua：原子化预扣减（适合秒杀类场景）

把库存放在 Redis 中，用 Lua 脚本保证“读-判-减”三步不可分割，避免网络延迟导致的超卖：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 脚本示例：if redis.call('get', KEYS[1]) >= tonumber(ARGV[1]) then return redis.call('decrby', KEYS[1], ARGV[1]) else return -1 end
• 用 EVAL 执行该脚本，KEYS 是商品 key，ARGV 是扣减数量
• 返回 -1 表示库存不足；返回新值表示成功，后续再异步落库或发 MQ 补充校验
• 注意：Redis 库存只是“快照”，需搭配定时任务或监听 binlog 做 Redis 与 DB 库存一致性补偿

分布式锁 + 状态机：控制关键路径串行化

对强一致性要求极高、且不允许任何超卖的场景（如银行级库存），可在关键入口加分布式锁，但要避免性能瓶颈：

立即学习“Java免费学习笔记（深入）”；

• 推荐用 Redisson 的 RLock 或 ZooKeeper 临时顺序节点实现公平锁
• 锁粒度尽量小：按商品 ID 加锁，而非全局锁；锁持有时间务必短（建议
• 更优做法是结合状态机：订单创建 → 预占库存（Redis）→ 支付成功 → 扣减 DB 库存 → 释放预占；超时未支付自动回滚预占
• 避免在锁内做远程调用、DB 查询等耗时操作，防止锁堆积

降级与兜底：熔断、队列、异步校验

技术再强也需面对突发流量，系统必须有容错能力：

• 接入 Sentinel 或 Hystrix，在库存服务异常时快速熔断，返回“库存繁忙，请稍后再试”
• 前端加按钮置灰、请求排队（如用 Redis List + 消费者 Worker 模型），削峰填谷
• 所有扣减操作记录日志或发 MQ，后台启动对账任务，每分钟比对 Redis/DB/订单表库存，发现不一致自动告警并修复
• 预留少量“缓冲库存”，用于应对最终一致性延迟（如 DB 更新慢于 Redis），避免刚扣完就显示售罄