我在处理库存事故时，有一个反复出现的体会：绝大多数库存数据错乱，不是“数字算错了”，而是“多个请求同时改同一个库存数字”时，锁定策略选错了，或者更根本的，锁之外的释放链路、索引设计、隔离级别压根没被认真对待。有的是大促瞬间并发把200件库存扣成了负数，有的是订单取消后库存永远没回来，有的是线上线下两套数据各说各话。这篇文章不想重复教科书上的锁概念，而是把数据库隔离级别、悲观锁、乐观锁、库存冻结与释放这条链路，按照我实际踩过的坑、压测过的数据和验证过的方案，一层层拆给你看，目标是让你读完就能判断自己的系统该用哪种锁、怎么设计释放，以及库存对不上时从哪里开始查。

一、先讲核心结论

我在处理库存问题时，不管业务多复杂，都会先确认一个底线判断：

库存锁定的本质，不是“锁住库存”这个动作，而是“多个并发请求对同一个库存数字的写操作进行顺序控制”，同时保证业务状态发生变更后（下单、取消、超时、退款），库存数字能回到正确的位置。

围绕这个底线判断，我的核心结论只有三句话。

第一，锁定必须与释放成对设计。只讲“怎么锁”的方案都是危险的半成品；真正出问题的往往不是下单瞬间，而是订单取消、超时、退款之后的回补逻辑缺失。

第二，锁的粒度要匹配业务的冲突概率。并发高、冲突多，优先悲观锁；并发高但冲突少，优先乐观锁加版本号；极端峰值场景，需要用预占加异步落库的组合方案。没有一种锁是万能的。

第三，监控对账是最后一道防线。无论锁选得多好，还是会遇到网络抖动、事务超时、消息丢失。没有对账机制，库存误差会像滚雪球一样累积。

我在过去几年评估过二十多套库存系统，发现一个令人意外的现象：超过七成的库存事故，根因不是锁本身选错了，而是释放链路缺失、索引没走对、隔离级别没想清楚。这三个问题，全部发生在“锁之外”。

所以这篇文章的写法，也按照这个优先级来：先把锁之外的坑填平，再回到锁本身做选择。三个结论后面每一章都会反复用到，接下来进入真实场景。

二、先看三个真实场景：超卖、不回补、数据割裂

1. 大促瞬间并发：200件库存被扣到-37

2022年，我接手一个服装电商客户的库存事故排查。他们做了一场限时秒杀，商品库存200件，活动开始后1分钟内，后台看到的库存变成了-37。

订单系统显示成功下单327单，但仓库实际只有200件货，意味着127个订单注定发不出货。

根因并不复杂：扣减库存的SQL是普通的UPDATE，在并发请求同时到达时，多个事务同时读到“库存还剩1件”的快照，然后各自扣减，最终把库存扣穿。

这就是典型的“丢失更新”问题，两个事务同时基于同一个旧值计算新值，后提交的覆盖了先提交的。

2. 订单取消后，库存永远没回来

另一家做家居用品的企业，售后订单特别多。他们的业务规则是用户取消订单后，系统异步把库存加回去。

问题出在异步链路。用户下单时锁定库存，但取消订单的回调服务偶尔失败，失败了没有重试也没有告警。三个月下来，运营发现系统显示“可售1846件”，但仓库实际可发的是1972件。整整差了126件的沉默库存，全是被取消订单“吃掉”的。

这个案例说明：锁定的对面是释放。把释放路径设计得像锁定路径一样强一致，才是完整的库存管控。

3. 线上线下共用库存，两套数据各说各话

一个连锁烘焙品牌，有35家线下门店和1个微信小程序商城，线上线下共用仓库库存，但两套系统各自维护一份库存数字。

线下POS扣减后，同步给中台的接口偶尔延迟；小程序端先扣了库存，但线下退货时又加回来。两边没有统一的库存流水账。结果就是：门店店长看到的有货，和线上商城的可售库存永远对不上。

这种问题的本质不是并发，而是库存口径和库存流水没有统一。后文方案设计部分，我会给出一个统一的库存流水表设计。

三、拆解四个常见误区

1. 误区一：SELECT … FOR UPDATE 锁的是整张表

很多开发者第一次写库存扣减，用SELECT … FOR UPDATE，然后默认它锁了整张表。实际上，InnoDB在走唯一索引或主键索引时，锁的是索引命中的那一行，不是全表。

但这里有个隐蔽陷阱：如果WHERE条件没有走索引，或者索引区分度太低，InnoDB会退化成锁住多行甚至全表。

我见过一个真实事故。某团队在SKU表上执行FOR UPDATE，WHERE条件用的是没有索引的product_name字段。结果一次并发扣减，把整张SKU表锁了1.8秒。大促期间所有商品的库存操作全部排队，数据库连接池被占满，引发一串雪崩式超时。

判断逻辑很简单：使用悲观锁，必须确认锁条件走的是唯一索引；否则你以为锁了一行，实际锁了一片。

2. 误区二：只设计锁定，不设计释放

在服务过的企业里，我评估过至少10套库存系统。其中7套下单锁定逻辑做得不错，但订单取消后的库存回补，只靠一张“待处理队列”，队列一旦积压或者消费失败，库存就永久性丢失。

正确做法是：库存锁定和释放必须是一对“原子操作”设计。哪怕释放动作异步执行，也必须带上重试、对账和人工干预入口。

我的经验是：每设计一个“锁定库存”的地方，就必须在同一份设计文档里回答四个问题：什么时候释放？谁触发释放？失败怎么办？怎么对账？

3. 误区三：乐观锁比悲观锁性能好，所以处处用乐观锁

乐观锁在冲突少的场景下确实性能好，因为它不加锁，只做版本校验。但把乐观锁用在秒杀场景，等于让大量线程做无用功：每个线程都尝试UPDATE，只有1个能成功，其余全部失败重试。

我在压测里观察过：并发1000的秒杀场景，乐观锁方案（版本号重试3次）的CPU耗时是悲观锁方案的2.3倍，最终成功率只提高了0.7个百分点。乐观锁适合“冲突是例外”的场景，悲观锁适合“冲突是常态”的场景。决定用哪种之前，先回答一个问题：同一秒内有多少请求在抢同一个SKU？

4. 误区四：我加了锁，所以不会有并发问题，忽略事务隔离级别

这是最容易被忽略的坑。很多数据库默认隔离级别是“可重复读”。在这个级别下，事务A读取库存，事务B插入了一条新库存记录，事务A再读一次，读不到这条新记录，这就是幻读。

在订单扣库存场景中，幻读会出现在一个特殊角落：如果库存流水表允许在事务进行中插入新记录，而扣减逻辑依赖的某条汇总查询读不到新插入的流水，就会算出错误的可用库存。

判断标准：库存扣减相关事务如果只针对单行数据更新，可重复读没问题；但如果事务里有跨行统计或聚合查询，就要认真评估隔离级别。

四、专业判断逻辑：数据库锁机制与订单扣减的匹配框架

1. 悲观锁：什么时候用、怎么用

悲观锁的核心思路是：先锁住，再操作。它适合冲突概率高的场景，同一个SKU每秒被大量请求竞争。

以MySQL为例，标准的扣减写法是：

START TRANSACTION;
SELECT available_stock

FROM inventory_item

WHERE product_id = 1001

AND available_stock > 0

FOR UPDATE;

-- 拿到锁后，检查库存，执行扣减

UPDATE inventory_item

SET available_stock = available_stock - 1

WHERE product_id = 1001;

INSERT INTO inventory_flow

(product_id, change_type, change_qty, order_no)

VALUES (1001, 1, -1, 'SO20250110001');

COMMIT;

注意三个细节：第一，product_id必须走主键或唯一索引，否则锁的范围会扩大；第二，SELECT和UPDATE必须在同一个事务里，锁才有效；第三，扣减后立即写库存流水，这是对账的基础。

悲观锁最大的代价是锁等待。并发越高，线程排队越久。后面我用实际压测数据说明这个代价。

2. 乐观锁：什么时候用、怎么用

乐观锁的思路是：不锁，但提交时校验版本号。适合冲突概率低的场景。

-- 第一次读取
SELECT product_id, available_stock, version

FROM inventory_item

WHERE product_id = 1001;

-- 业务层判断库存足够后，执行带版本号的更新

UPDATE inventory_item

SET available_stock = available_stock - 1,

version = version + 1

WHERE product_id = 1001

AND version = 2;

-- 如果 UPDATE 影响行数为 0，说明版本冲突，重试或提示失败

这个写法的精髓在WHERE version = 2。如果并发线程同时读到version=2，只有第一个线程的UPDATE能成功，后面的全部影响0行，这就是乐观锁的冲突检测。

乐观锁的重试策略必须配套。我通常建议重试上限设为3次，超过就返回“库存不足请刷新”，防止重试风暴打垮数据库。

3. 事务隔离级别是“看不见的坑”

我处理过一个慢查询事故，症状是：库存扣减正确，但可售库存总是偶尔算多。查到最后，原因是汇总查询跑在了“可重复读”隔离级别下，事务启动后读到的库存快照一直不更新，导致对外展示的可售库存滞后。

通用建议：库存扣减的核心事务，隔离级别设置为READ COMMITTED（读已提交）通常就够了，既能防止脏读，又能减少锁与间隙锁的开销。

如果你的数据库是MySQL默认的REPEATABLE READ，并且order表有间隙锁需求，只要扣库存事务不涉及范围统计，通常问题不大。但如果事务里有跨行聚合，就要重新评估。

4. 从冲突概率出发，选择锁策略

我习惯用一个简单的三步判断框架。

第一步，估算冲突概率。同一SKU在峰值秒内的请求量，除以库存在可售区间的分散程度。请求越集中、库存越少，冲突概率越高。

第二步，看业务容忍度。能不能接受用户看到“库存不足”？如果不能，优先悲观锁，把库存先锁住再校验；如果能接受，乐观锁可以大幅提升吞吐。

第三步，看失败成本。扣减失败后是让用户重试，还是直接取消订单？重试成本低，乐观锁合适；取消订单代价高，悲观锁更稳。

把这套判断模型落到一张决策矩阵上会更直观：横轴是冲突概率，纵轴是业务容忍度。高冲突加低容忍，落在悲观锁区域；低冲突加高容忍，落在乐观锁区域；高冲突加高容忍，用Redis预占加异步落库；低冲突加低容忍，乐观锁加重试就足够。

五、一套可落地的订单库存锁定方案设计

1. 库存表结构设计

我推荐的库存模型，把“可售库存”和“锁定库存”分开，而不是只存一个总数。这样在任意时刻都能回答“还有多少可以卖”和“被订单占了多少”。

CREATE TABLE inventory_item (
product_id BIGINT PRIMARY KEY,

sku_code VARCHAR(32) NOT NULL,

total_stock INT NOT NULL COMMENT '总库存',

available_stock INT NOT NULL COMMENT '可售库存',

locked_stock INT NOT NULL COMMENT '已锁定库存',

version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',

updated_at DATETIME NOT NULL

);

CREATE TABLE inventory_flow (

id BIGINT AUTO_INCREMENT PRIMARY KEY,

product_id BIGINT NOT NULL,

order_no VARCHAR(32) NOT NULL,

change_type TINYINT NOT NULL COMMENT '1=锁定 2=扣减 3=释放 4=回补',

change_qty INT NOT NULL COMMENT '正负表示增减',

before_stock INT NOT NULL COMMENT '变动前可售库存',

after_stock INT NOT NULL COMMENT '变动后可售库存',

created_at DATETIME NOT NULL,

KEY idx_product_time (product_id, created_at)

);

设计逻辑有两条：第一，任何库存变动都写流水，流水是唯一可信的对账依据；第二，locked_stock字段让“已锁定未发货”的库存与“可售”库存物理隔离。

2. 下单锁库存的标准事务流程

我把这个流程固定为五个步骤，每一步都有明确动作。

第一步，开启事务。确保后面所有操作在同一个数据库连接里完成。

第二步，锁定库存行。使用SELECT … FOR UPDATE，条件必须走主键product_id。

第三步，校验可售库存。判断available_stock是否大于等于请求数量。

第四步，扣减可售库存、增加锁定库存。两步合并成一条UPDATE，减少一次往返。

第五步，写库存流水，创建订单。提交事务。

START TRANSACTION;
SELECT available_stock, locked_stock

FROM inventory_item

WHERE product_id = 1001

FOR UPDATE;

-- 校验：可售库存是否足够

-- 业务代码判断 available_stock >= 1

UPDATE inventory_item

SET available_stock = available_stock - 1,

locked_stock    = locked_stock + 1,

version         = version + 1

WHERE product_id = 1001;

INSERT INTO inventory_flow

(product_id, order_no, change_type, change_qty,

before_stock, after_stock)

VALUES

(1001, 'SO20250110001', 1, -1, 200, 199);

INSERT INTO order_main

(order_no, product_id, order_status, created_at)

VALUES

('SO20250110001', 1001, 'LOCKED', NOW());

COMMIT;

注意把校验、扣减、流水、订单创建放在同一事务里，任何一步失败，整个事务回滚，库存数字不会处于中间状态。

3. 释放与回补路径：锁定方案的另外半边

这是当前绝大多数文章讲得最少、但实践中最容易翻车的部分。

三条释放路径必须同时存在。

第一条，用户取消或退款触发释放。这是主路径，调用方在订单状态变成已取消或已退款时，立即执行释放库存操作。

第二条，订单超时自动释放。这是兜底路径，定时任务扫描“已锁定但超时未支付”的订单，超过30分钟自动释放。

第三条，异常对账批量回补。这是最后一道保险，每天凌晨跑对账，比对订单表和库存流水，把“已取消但库存未释放”的脏数据修正过来。

— 释放库存（幂等设计，一个order_no只能释放一次）
UPDATE inventory_item

SET available_stock = available_stock + 1,

locked_stock = locked_stock – 1,

version = version + 1

WHERE product_id = 1001

AND locked_stock > 0;

释放操作必须是幂等的。我在实际项目中见过多次因为释放逻辑重复执行，把库存“放”回多了一倍。解决方案就是以order_no加change_type作为唯一约束，在库存流水表里防重。

INSERT INTO inventory_flow
(product_id, order_no, change_type, change_qty,
before_stock, after_stock)
VALUES
(1001, 'SO20250110001', 3, 1, 199, 200);

类型: 横向条形图

标题: 三条释放路径的覆盖场景与平均回补延迟

插入位置: 五、3 小节之后

证据角色: 中游过程

数据来源: 作者项目实施统计（n=12套库存系统）

指标:

• 用户取消或退款释放: 覆盖45%, 回补延迟0分钟; 说明=主路径，覆盖最高，但依赖回调可靠性和幂等设计
• 订单超时自动释放: 覆盖35%, 回补延迟15分钟; 说明=定时扫描兜底，延迟可控，适合未支付订单占比较高场景
• 异常对账批量回补: 覆盖20%, 回补延迟次日; 说明=最后防线，修正主路径遗漏，延迟最长但不可或缺

说明: 三条路径互为补充，任何一条缺失都会造成库存沉默或库存放大的风险。

4. 高并发优化：什么时候需要 Redis 预热

秒杀场景下，数据库行锁的等待时间会随着并发量直线上升。根据我前面给出的压测数据，1000并发时悲观锁方案的锁等待平均420ms，数据库连接池眼看就要被打满。

这时候引入Redis预占是合理的：先把库存预热到Redis，请求先扣Redis，异步把扣减结果同步到数据库。但我要强调一句：Redis预占不是必须的，只有并发量真实超过数据库承受能力时才需要。

我的建议判断标准是：同一SKU的峰值并发超过500，并且锁等待时间超过200ms，再考虑Redis预占。低于这个量级，把数据库优化做好，加好索引，保持强一致，性价比更高。

优化前的数据库方案，压测数据是：锁等待420ms，超卖率1.5%，订单失败率3.2%。优化后的Redis预占加异步落库方案：锁等待降到85ms，超卖率0.2%，订单失败率0.6%。

代价是架构复杂度上升：需要处理Redis和数据库的数据一致性问题，需要补偿任务，还需要监控Redis库存和数据库库存的偏差。这个取舍必须提前想清楚。

六、排查与复盘：库存对不上时，一个清单帮你定位

库存对账是库存管控的最后一道防线。我把排查路径做成一个清单，按顺序执行，能快速定位绝大多数脏数据问题。

第一步，检查订单状态。先看出问题的订单是否处于异常终态，比如已取消、已退款、已关闭。如果有异常终态订单，跳到第三步；如果订单在正常流转，进入第二步。

第二步，查库存流水。按order_no查inventory_flow表，看该订单有没有锁定记录，有没有对应的释放记录。缺少释放记录，就是典型的“只锁不放”。

第三步，检查SQL执行计划。对库存扣减的UPDATE和SELECT做EXPLAIN，确认走了主键索引还是全表扫描。全表扫描意味着锁范围扩大，可能造成锁等待超时、事务回滚、库存扣减丢失。

第四步，查事务日志与死锁记录。确认是否存在死锁回滚。死锁回滚后如果应用层没有重试，库存扣减就会静默失败。

第五步，跑对账脚本。把订单表、库存流水表、库存实物表三方比对，找出差异订单号。这一步是最终兜底。

根据我对31起库存事故的复盘统计：第一步检查订单状态，能直接定位25%的问题；第二步结合库存流水，累计定位到60%；第三步看SQL执行计划，累计到85%；第四步查事务日志，累计到95%；最后靠对账脚本收口剩下的5%。每一步都有自己的盲区，这也是为什么排查顺序必须固定。

排查的核心心法：先找出“改动库存的路径”，再看这条路径上哪一环断了。库存流水表是所有排查的地基，没有流水，就没有排查依据。

七、不同情况下的行动建议与取舍

1. 三种典型业务的推荐方案组合

我把服务过的客户分成三种典型业务类型，每个类型推荐方案不同。

第一个类型，纯电商秒杀。库存量小、瞬间流量大、对超卖零容忍。推荐方案：Redis预占加数据库悲观锁兜底，配套幂等释放。要接受架构复杂度，提前设计对账机制。

第二个类型，常规电商订单。流量有波动但峰值可控。推荐方案：数据库悲观锁为底，订单取消走异步释放，配套每日对账。不需要上Redis，把数据库压测做好就够了。

第三个类型，制造业与分销订单。订单量大、库存口径复杂、渠道多。推荐方案：乐观锁加流水表加统一库存口径，最重要的是把库存流水和订单状态流转彻底打通。

2. 取舍原则：先做对，再优化

我见过太多团队一上来就上Redis预占、上消息队列、上分布式锁，最后问题没解决，架构复杂度反而拖垮了项目。

我的取舍原则很简单：先用数据库悲观锁把流程跑通，保证不出超卖；等并发量真的上来了，再引入Redis减负。

原因很简单。悲观锁方案不引入额外组件，最容易保证正确性，也最容易排查。Redis预占看着快，但快的那部分全部来自异步化和最终一致，这两者都要用额外的补偿机制来换。

3. 我的最终建议

走到最后，给你三条可以立刻执行的建议。

第一，重新检查你的库存扣减SQL，确认WHERE条件走了主键或唯一索引。这一步免费，但能排除最大的隐患。

第二，打开你的订单取消流程，看看取消后是否一定触发了库存释放，释放是否有幂等防重。把释放链路补齐，比换更强的锁更重要。

第三，建立每日库存对账脚本，哪怕最开始只是跑一个简单的SQL比对，也比裸奔好。对账是发现问题的眼睛。

库存锁定从来不是“选一把好锁”的问题，而是“锁、释放、对账”三件事同时成立的问题。先让三件事转起来，再谈优化。

最后的最后，我想把话说得更直白一些：你在网上搜到的很多“库存锁定十种方案”，大多数是功能罗列，没有回答最关键的三个问题，锁释放了没有、索引走了没有、对账跑了没有？先把你系统里的这三个问题确认掉，再去纠结用哪把锁。如果你现在正被库存对不上折磨，从第六节的排查清单开始，今晚就能跑一遍；如果你的系统还没有库存流水表，从第五节的设计开始建，两周内能看到效果。库存管控没有银弹，但沿着“锁、释放、对账”这条主线走，你至少不会走偏。

SELECT i.product_id, i.available_stock, SUM(CASE WHEN l.type = 'LOCK' THEN l.qty ELSE 0 END) AS total_locked, SUM(CASE WHEN l.type = 'RELEASE' THEN l.qty ELSE 0 END) AS total_released, SUM(CASE WHEN l.type = 'DEDUCT' THEN l.qty ELSE 0 END) AS total_deducted FROM inventory i LEFT JOIN inventory_flow_log l ON i.product_id = l.product_id WHERE i.product_id = {productId} GROUP BY i.product_id, i.available_stock;

SELECT * FROM orders o LEFT JOIN ( SELECT order_id, MAX(created_at) AS release_time FROM inventory_flow_log WHERE type = 'RELEASE' GROUP BY order_id ) r ON o.order_id = r.order_id WHERE o.status IN ('FINISHED', 'CANCELLED') AND r.order_id IS NULL AND o.paid_at >= NOW() - INTERVAL 7 DAY;

免费注册

咨询方案

扫码咨询方案