设计高并发库存系统需先明确防超卖机制，通过MySQL行级锁、乐观锁（version字段）和原子操作确保数据一致；库存表独立设计，包含总库存、可用库存、冻结库存及版本号字段；下单时扣减可用库存并增加冻结库存，支付后转为已售，取消或超时则释放冻结库存；推荐用消息队列异步处理状态流转，结合Redis缓存预减库存提升性能，同时分表分库应对热点商品，最终以MySQL为准保证一致性。
在高并发的电商系统中，商品库存管理是核心模块之一。设计不合理容易导致超卖、数据不一致等问题。本文结合 MySQL 实战经验，介绍如何设计一个稳定、可靠的库存系统。
库存表结构设计
库存信息通常单独建表，避免主商品表频繁更新影响性能。
基本字段包括：
- id：主键
- product_id：商品ID（唯一索引）
- total_stock：总库存（仓库实际数量）
- available_stock：可用库存（可售数量）
- frozen_stock：冻结库存（已下单未支付）
- version：版本号（用于乐观锁）
- updated_at：更新时间
示例SQL：
CREATE TABLE `product_stock` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `product_id` BIGINT NOT NULL UNIQUE, `total_stock` INT NOT NULL DEFAULT 0, `available_stock` INT NOT NULL DEFAULT 0, `frozen_stock` INT NOT NULL DEFAULT 0, `version` INT NOT NULL DEFAULT 0, `updated_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_product_id (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
防止超卖的关键机制
在秒杀或抢购场景中，多个用户同时下单可能导致库存扣减错误。常用解决方案：
-
数据库行级锁（悲观锁）：使用
SELECT ... FOR UPDATE锁定记录，确保串行执行。 - 乐观锁控制：通过 version 字段判断更新前后是否一致，避免覆盖。
- 原子操作扣减：利用 MySQL 的原子性，在 SQL 中直接判断并更新。
推荐写法（防超卖）：
UPDATE product_stock
SET available_stock = available_stock - 1,
frozen_stock = frozen_stock + 1,
version = version + 1
WHERE product_id = ?
AND available_stock > 0
AND version = ?
执行后检查受影响行数，若为0说明库存不足或版本冲突，需提示用户。
库存状态流转逻辑
真实业务中，库存不是简单减法。典型流程如下：
- 用户下单 → 扣减可用库存，增加冻结库存
- 支付成功 → 冻结库存转为已售，总库存减少
- 订单取消或超时 → 释放冻结库存回可用库存
建议用消息队列（如RocketMQ）异步处理解冻和出库，避免事务过长。
例如订单超时未支付，触发定时任务或延迟消息：
UPDATE product_stock
SET available_stock = available_stock + 1,
frozen_stock = frozen_stock - 1
WHERE product_id = ?
AND frozen_stock > 0;
性能与扩展建议
面对高并发请求，单一MySQL可能成为瓶颈。优化方向：
- 热点商品拆分独立库存表，按商品类目或ID分表
- 结合 Redis 缓存库存快照，减少数据库压力
- Redis 预减库存做第一层拦截，MySQL 做最终一致性校验
- 关键操作记录日志表（stock_log），便于对账和排查
注意：缓存方案需处理好缓存穿透、击穿、雪崩问题，必要时加本地缓存+限流。
基本上就这些。库存系统看似简单，但细节决定成败。合理利用MySQL的事务、锁机制和原子操作，配合应用层控制，才能保障数据准确。实战中建议先做小流量验证，再逐步上线。
