1. 先把库存这本账算清楚：三个字段背后是四层口径

库存管理这个话题，我在不同团队里见过太多次同样的开局：产品经理说"商品表里加个 stock 字段不就行了"，开发顺手加了一个 int，上线三个月后开始出现"明明显示有货，下单却提示售罄"和"库存扣成负数"两类工单同时飞来。问题从来不是代码写错了，而是从一开始就没把"库存"到底是什么说清楚。电商交易系统里的库存管理与库存预警，本质上不是一个字段的加减法，而是一套账本体系加一套决策机制：账本负责"每一件货现在在哪、被谁占着"，决策机制负责"什么时候该补货、补多少"。这篇内容我按实际落地顺序拆开讲，包括库存口径怎么划分、超卖的并发缝隙在哪、缓存与数据库怎么配合、预警阈值怎么算才不是拍脑袋，以及大促前后容易翻车的细节，适合正在做交易链路的后端、做供应链系统的研发，也适合想搞明白"为什么我们库存总对不上"的产品同学。

1.1 一个 sku_id 对应的库存，从来不是一个数字

新手最容易犯的错，是把库存当成"仓库里还有多少件"这一个数。真实业务里至少同时存在四个口径，而且它们必须能互相对上账：

关键恒等式是：可用库存 = 实物库存 − 占用库存 − 已冻结（如质检、锁仓）数量。很多人会再引入一个"在途"算进可售，那是预售场景的玩法，普通现货不建议混进来，一旦混了，客服会天天接到"你们页面说有货结果发不出"的投诉。我建议的做法是物理上拆两张表：一张stock存实物与占用，一张stock_in_transit存在途，业务上通过视图或服务层组合，而不是把五个数字塞进同一行记录里——塞进去之后，任何一次并发更新都会牵扯出一堆字段互相覆盖的问题。

1.2 下单减、支付减、发货减：三种时机的真实代价

这是库存管理里第一个必须做决策的地方，而且没有"最优解"，只有"你能承受哪种代价"。

• 下单减库存：用户提交订单瞬间就占用库存。好处是绝对不会超卖，坏处是恶意占库、拍下不付款会把库存锁死，需要配套的订单超时自动取消 + 库存回滚。
• 支付减库存：付款成功才扣。好处是转化率高、不会锁死，坏处是大促时会出现"付了钱没货发"，属于业务事故级别，必须配超卖兜底方案。
• 发货减库存：实物出库才扣。适合自营仓、预售、定制类目，因为发货前一切皆可变，但页面可售量就得靠预估，很容易失真。

我参与过的几个交易系统最终都收敛到下单减库存 + 超时未支付自动取消回滚这条路上，原因是它在"用户体验"和"运营风险"之间最平衡。但要注意一个细节：回滚必须是幂等的，订单取消、支付超时、风控拦截、退款这四个入口都可能触发回滚，如果没做幂等，库存会被加回去好几次，于是出现"库存越卖越多"的灵异现象——这个坑后面第 3 节会专门讲。

1.3 库存流水表：所有对不上的账，最后都靠它查

我在任何系统里都会强制要求一张stock_flow流水表，字段大致是：id, sku_id, warehouse_id, biz_type, biz_no, change_qty, before_qty, after_qty, operator, create_time。每一次库存变动，无论是扣减、回滚、盘点调整、报损，都必须写一条流水，且(biz_type, biz_no, sku_id)建唯一索引。

这张表的价值不在业务功能，而在出问题的时候。当运营说"昨天这个 SKU 卖了 300 件，库存怎么只掉了 280"，你唯一能靠的就是流水：把当天的流水按 biz_type 分组求和，立刻能看出是回滚多写了、还是盘点覆盖了。没有流水表的系统，排查这类问题只能靠翻日志，翻到天亮也未必能定位。我个人的经验是，流水表的数据量会很大，按天或按月分区，保留 6 到 12 个月足够，历史数据归档到冷存储即可。

2. 超卖的根因不在代码，在这三处并发缝隙

几乎所有人都知道"库存要防超卖"，但实际排查下来，超卖往往不是发生在你以为的那一处。我见过最典型的三种成因：一是先查后改的两步操作中间被人插了队；二是缓存和数据库的扣减结果不一致；三是同一笔订单被重复消费扣了两次或者回滚了两次。这三个问题的解法完全不同，混在一起讨论只会越聊越乱。这一节先把并发扣减这条最核心的链路讲透。

2.1 从"查询后扣减"到"条件更新"：一行 SQL 的改造

新手写法长这样：

// 错误示范：查询与更新之间存在并发窗口 Stock stock = stockMapper.selectBySku(skuId); if (stock.getAvailableQty() >= num) { stock.setAvailableQty(stock.getAvailableQty() - num); stockMapper.updateById(stock); }

两个线程同时读到 1 件，都判断通过，都执行更新，最终卖出 2 件。这就是最经典的超卖。改成条件更新，把判断和减法压进一条 SQL，让数据库的行锁来保证原子性：

UPDATE stock SET available_qty = available_qty - #{num}, locked_qty = locked_qty + #{num}, version = version + 1, update_time = NOW() WHERE sku_id = #{skuId} AND warehouse_id = #{warehouseId} AND available_qty >= #{num};

然后判断affectedRows，等于 0 就说明库存不足，直接抛业务异常。这一行 SQL 里有两个点必须注意：available_qty >= #{num}这个条件不能少，它是防负库存的最后一道闸；warehouse_id必须进 WHERE 条件，否则多仓场景下会扣错仓。我见过因为漏了仓条件，导致 A 仓卖空、B 仓明明有货却显示售罄的案例，排查了半天以为是缓存问题。

2.2 三种并发控制方案的适用边界

条件更新不是唯一解，实际选型要看并发量级和一致性要求：

必须说清楚一件事：乐观锁在秒杀场景下是负优化。因为同一 SKU 的所有请求都读同一个版本号，只有一个能成功，其余全部重试，重试再失败，CPU 全耗在循环里。这种场景要么上 Redis 预扣，要么在应用层做请求排队，指望数据库扛是不现实的。

2.3 一段可落地的 Redis 预扣减实现

大促链路我一般用这样的组合：Redis 存"可售余量"，Lua 脚本保证原子性，扣减成功后发消息异步落库，同时写流水。

-- deduct_stock.lua -- KEYS[1] = stock:available:{skuId} -- ARGV[1] = 扣减数量 local available = tonumber(redis.call('GET', KEYS[1])) if available == nil then return -1 -- 未预热 end local num = tonumber(ARGV[1]) if available < num then return 0 -- 库存不足 end redis.call('DECRBY', KEYS[1], num) return 1 -- 成功

返回值约定成三态很重要：-1表示 Key 不存在（未预热或已过期），这时候必须回源查数据库并回填，绝不能当成"库存无限"放过去；0表示不足；1表示成功。我踩过的坑就是早期只判断了返回值是否大于 0，结果 Redis 重启后所有 Key 丢失，所有请求都返回 -1，被当成了扣减成功，瞬间超卖上万单。

落库环节要注意：异步落库意味着数据库的available_qty有延迟，任何以数据库为准的查询都可能读到旧值。所以展示层的可售量在活动期间应该只读 Redis，数据库只作为最终账本和对账基准，两套口径不能混着用。

3. 缓存与数据库的双写：库存一致性的取舍表

库存这个数据和普通商品详情完全不是一类东西。商品标题可以缓存十分钟，用户看到旧标题不会出事；库存缓存十分钟，用户下单时才发现没货，投诉电话就打进来了。所以库存的缓存策略必须单独设计，不能复用通用的"读多写少 + 过期兜底"那套。这一节讲清楚缓存怎么参与扣减、异步落库之后怎么保证最终一致、以及回滚为什么比扣减更容易出事故。

3.1 为什么库存不能用"更新数据库再删缓存"的老套路

通用缓存方案是"写库 → 删缓存 → 下次读回源"。放到库存上会出问题：删缓存之后，大量读请求同时回源查库，而数据库里那个值可能还没被异步扣减更新，于是雪崩式地把旧值重新写回缓存，造成"库存回弹"。更麻烦的是，库存的读和写都极其频繁，删除缓存的窗口里必然有并发。

我在实际项目里的处理原则是三条：

1. 扣减路径不与缓存双写混用。要么全程走数据库条件更新，要么全程走 Redis 预扣 + 异步落库，选一条，别混。
2. 展示路径允许短暂偏差，但要有兜底校验。详情页和购物车显示的可售量可以来自缓存，但下单校验必须走权威扣减接口，不能信任页面传上来的"还有货"。
3. 缓存过期时间要短且有主动刷新。我一般设 30 到 60 秒，同时在下单成功后主动刷新对应 Key，减少用户看到旧值的概率。

3.2 异步落库的补偿链路怎么设计

Redis 预扣成功之后，用消息队列把扣减事件投出去，消费者负责更新数据库并写流水。这条链路必须解决两个问题：消息丢了怎么办、消息重复了怎么办。

丢消息的兜底靠定时对账。每 5 分钟跑一次比对任务，把 Redis 中的余量和数据库中"实物 − 占用"算出来的理论值对齐，差异超过阈值就告警并落事件表人工介入。对账任务要按 SKU 分批处理，避免一次扫全表把数据库拖垮。

重复消费的兜底靠幂等键。每个扣减事件携带biz_no（订单号），流水表对(biz_type, biz_no, sku_id)建唯一索引，重复插入直接捕获唯一键冲突并跳过。这比"先查有没有处理过再插入"可靠得多，因为后者本身也有并发窗口。

注意：对账发现的差异不要自动修复。自动修复会掩盖真实的 bug，我见过的案例是自动补正把一次严重的重复回滚给"抹平"了，等到大促当天问题集中爆发才发现。差异应该告警 + 记录，人工确认后走专用的调整接口，调整本身也要写流水。

3.3 回滚比扣减更容易出事：四个入口一个都不能漏

扣减只有一个入口（下单），回滚可能有四个：用户主动取消、支付超时自动关单、风控拦截、售后退款。这四个入口如果没有统一的幂等控制，就一定会出现重复加库存。

我的做法是把回滚收敛到一个内部服务方法，签名带上bizType + bizNo，内部先查流水表判断"这笔业务是否已经回滚过"，没回滚过才执行UPDATE stock SET available_qty = available_qty + n, locked_qty = locked_qty - n WHERE sku_id = ? AND locked_qty >= n。这里同样有条件locked_qty >= n，防止占用库存被扣成负数。同时要注意执行顺序：先更新数据库，再删 Redis 对应 Key（或者把 Redis 余量加回去），两个动作的失败要分别有重试和告警。

还有一个隐蔽的坑：部分退款该不该回滚库存。如果用户买 3 件退 1 件，库存加 1 是对的；但如果商品已经发出，退回的货需要质检才能重新入库，这时候应该加"待检库存"而不是直接加可售。这个区分必须在业务建模阶段就想好，事后补极其痛苦。

4. 库存预警不是设个阈值就完事：从静态水位到动态补货点

库存预警这块，我见过最多的实现是"库存低于 10 就发钉钉通知"。上线第一周很新鲜，第二周开始被无视，第三周就被屏蔽了。原因很简单：固定阈值无法适配不同 SKU 的销售速度。日销 500 件的爆款，库存剩 10 件才开始预警，等货到早就断货半个月了；日销 1 件的长尾品，库存剩 10 件能卖十天，天天被预警只会造成噪音。真正有用的库存预警，核心不是"低于多少报警"，而是"什么时候必须下单采购"。

4.1 三种预警算法各自的适用面

实践中我建议把三者组合使用：以日均消耗法作为主逻辑，用安全库存做下限兜底，用固定水位做绝对红线。也就是说最终的预警线取三者中的最大值，这样既不会因为日均销量掉到 0 而完全失去预警，也不会因为固定阈值太低而在爆款上失效。

4.2 安全库存与补货点的完整算法与算例

先把公式列清楚，这两个数不能混：

• 安全库存 SS = Z × σ_d × √L，其中 Z 是服务水平对应的系数（95% 服务水平取 1.65，99% 取 2.33），σ_d 是日销量的标准差，L 是采购提前期（天）。
• 补货点 ROP = 日均销量 d̄ × L + SS。
• 建议补货量 Q = 目标覆盖天数 × d̄ − 当前可用库存 − 在途库存。

举个具体算例：某 SKU 过去 30 天销量为[12, 15, 9, 20, 18, 11, 14, 16, 13, 17, ...]，算出来日均 d̄ = 14.5 件，标准差 σ_d ≈ 3.6 件，采购提前期 L = 7 天，取 95% 服务水平 Z = 1.65。

• SS = 1.65 × 3.6 × √7 ≈ 1.65 × 3.6 × 2.646 ≈ 15.7，取整 16 件。
• ROP = 14.5 × 7 + 16 ≈ 117.5，取整 118 件。

也就是说，当可用库存 + 在途库存降到 118 件以下时，就该启动采购了。如果目标覆盖 30 天，当前可用 60 件、在途 0，则建议补货量 = 30 × 14.5 − 60 − 0 = 375 件，再按供应商起订量（比如 50 的倍数）取整到 400 件。

用 Python 跑这套计算很直接：

import math import statistics def calc_reorder_point(daily_sales, lead_time_days, service_level_z=1.65, cover_days=30, available=0, in_transit=0, moq=50): d_bar = statistics.mean(daily_sales) sigma = statistics.pstdev(daily_sales) if len(daily_sales) > 1 else 0.0 safety_stock = service_level_z * sigma * math.sqrt(lead_time_days) rop = d_bar * lead_time_days + safety_stock suggest_qty = cover_days * d_bar - available - in_transit if suggest_qty <= 0: return {"rop": round(rop), "safety_stock": round(safety_stock), "suggest_qty": 0} # 按最小起订量向上取整 suggest_qty = math.ceil(suggest_qty / moq) * moq return {"rop": round(rop), "safety_stock": round(safety_stock), "suggest_qty": int(suggest_qty)}

提示：新品没有历史数据时 σ 算不出来，不要用 0 顶替，那会让安全库存归零，等于没有缓冲。常见做法是取同类目同价格带的平均 σ 作为冷启动值，跑满 14 天再切换到自身数据。

4.3 预警触达：去重、抑制、分级、升级

算法算出来的预警线只是"该报警了"，能不能让人看到、看到之后会不会行动，靠的是触达设计。我把这块分成四层：

去重：同一 SKU 同一预警等级，24 小时内只推送一次，用一个(sku_id, level, date)的 Redis Key 做标记。

抑制：如果 SKU 已经在采购流程中（存在未完结的采购单），同等级的预警静默处理，只进日报不实时推送。这一条极其重要，否则采购下完单之后每天被同样的预警轰炸，人就会麻木。

分级：按"剩余可售天数 = 可用库存 / 日均销量"分级，比按绝对数量分级合理得多。

升级：黄色超过 24 小时未处理自动升红，红色超过 12 小时未确认升级到上一级。升级逻辑要配"确认人"字段，谁点了确认谁负责，不然预警永远悬着没人认领。

我还建议加一个反向预警：库存超过 90 天都卖不完的 SKU 也要提示，这是资金占用和滞销风险。很多团队只做缺货预警不做滞销预警，结果仓库堆满卖不动的货，采购还在按公式补货。

5. 大促前后的库存隔离与削峰实践

日常流量下跑得通的方案，放到大促当天大概率会崩。原因不在于代码有没有 bug，而在于流量形态完全变了：平时一个 SKU 每秒几个请求，活动开始瞬间可能几万个请求压向同一个库存行。这一节讲三件在大促中真正救命的事：库存分池、预热与限流、以及超卖之后的兜底处理。

5.1 活动库存与共享库存必须物理隔离

只要做过一次大促就会明白，活动库存和生活库存共用一个池子是灾难。活动卖超了，直接影响日常销售；日常订单占用了库存，活动承诺的量就兑不出来。我的做法是在stock表里按warehouse_id + stock_type做维度扩展，stock_type区分NORMAL（日常）和ACTIVITY（活动），活动开始前从日常池划拨一批过去，形成独立的可售量。

划拨要记录流水，活动结束后剩余量要回拨，回拨同样要幂等。另外必须配置限购规则：单用户限购 N 件，在 Redis 里用INCR计数实现，超过就拒绝。没有限购的限量活动，货基本都会被少数账号扫走，这个不做，前端的各种防刷都是白费。

5.2 预热、限流、排队三件套的组合顺序

大促的标准链路我一般这样组织：

1. 活动开始前 30 分钟预热：把活动 SKU 的可用量写入 Redis，Key 带上活动 ID，同时记录预热时间和预期量，方便事后核对。
2. 入口限流：在网关层按用户维度和全局维度双限流，全局 QPS 上限设为预估峰值的 1.2 倍，超出直接快速失败返回"活动太火爆"。这里宁可快速失败，也不要让请求堆积在队列里超时，超时重试会放大流量。
3. 服务端排队：对超热 SKU，可以用本地队列或者分布式队列做一次请求串行化，消费速率控制在数据库能承受的范围内，消费时再执行 Redis 预扣。
4. 异步落库与对账：前面讲过，不再重复。

一个容易被忽略的点是限流阈值要按 SKU 维度而不是只按接口维度。热门 SKU 的请求量可能是冷门 SKU 的上百倍，如果只做接口级限流，一个爆款就能把整个下单接口的额度吃光，其他商品全被误伤。

5.3 超卖发生之后的处理预案

必须承认一个现实：任何方案都有极小概率超卖。真正专业的团队不是号称"我们绝不超卖"，而是提前写好超卖之后的处理预案。我建议预案分三层：

第一层，自动识别。订单创建但库存扣减失败的记录，进一张异常单表，立刻告警。不要等到发货环节才发现没货。

第二层，优先级排序。超卖的订单按支付时间排序，先付先得，后面的走协商。协商话术、补偿方案（换货、优惠券、全额退）要在活动前就和客服对齐，不能临时讨论。

第三层，责任归因。每次超卖都要复盘到具体原因：是预热数据算错了、还是对账没跑、还是回滚重复执行。不复盘的团队会年年犯同样的错。

6. 上线之后真正会咬人的几个细节

方案设计得再漂亮，落到生产环境还是会被细节咬。这一节把我自己踩过、也见过别人踩的几个点列出来，都属于"文档里不会写、但一定会遇到"的类型。

第一个，时区与定时任务的时间漂移。预警任务一般按天跑，如果服务器时区和业务时区不一致，会出现"昨天算的预警线今天才生效"的问题，促销前一天特别致命。我的习惯是所有业务时间统一存 UTC 时间戳，展示层再转本地时区，定时任务显式指定时区，别依赖运行环境默认值。

第二个，库存调整接口没有权限分级。盘点调整、报损、强制置零这些接口，如果和生产环境的订单接口共用一个权限模型，出事只是时间问题。我给这类接口单独做了审批流：调增量超过 100 件的必须二级审批，所有调整必须填原因码，原因码进流水。这看起来很重，但它是防止内部误操作的最后一道墙。

第三个，Redis 内存淘汰策略把库存 Key 淘汰了。这是我最惨痛的一次。库存 Key 没有设过期时间，但 Redis 配的是allkeys-lru，内存压力上来之后把库存 Key 淘汰了，于是扣减脚本返回-1（Key 不存在），如果代码没处理这个分支，就等于放行。修法有两步：库存 Key 单独分配实例或者用独立 DB，淘汰策略改成noeviction；同时代码里-1必须走回源逻辑，绝不能当成功。

第四个，浮点数算库存。有些品类按重量卖，库存存成decimal没问题，但如果代码里用double参与计算，0.1 + 0.2 != 0.3会导致对账永远差一点点，天天报差异。金额和重量一律用整数最小单位或者BigDecimal，这条没有例外。

第五个，预警消息没有区分环境。测试环境的预警任务连的是生产 IM 群机器人，一跑压测就往群里发几百条"库存告急"，运维直接把机器人禁言，顺带把生产预警也屏蔽了。配置里必须强制带环境标识，测试环境的消息发到测试群，这个开工第一天就该做。

第六个，历史数据迁移时的库存快照。系统重构迁移库存表时，光迁当前值是不够的，必须同时迁"占用库存"和对应的未完结订单。我见过只迁了可用量、没迁占用量的迁移，上线后所有在途订单取消时都回加了一次库存，凭空多出一批货。

第七个，对账任务本身把数据库打挂。全表扫描加实时比对，在数据量上百万之后会在业务高峰期拖慢主库。解决办法是按更新时间增量对账 + 分片并行，并且只对"当天有变动的 SKU"做比对，没变动的跳过。这个优化做完，对账任务从 20 分钟压到 90 秒。

我个人的体会是，库存管理与库存预警这套东西，难的地方从来不是某个算法或者某段代码，而是口径统一和责任闭环。口径不统一，四个部门会拿着四个数字开会吵一整天；责任不闭环，预警发了没人认领，采购下了单没人跟踪到货。把账本建清楚、把流水记全、把预警落到具体的人头上，剩下的技术问题都是可以解决的。