一、前言

1.1 写作初衷

在电商26篇完整架构体系中，库存中心是资损风险最高、线上事故最多、并发最难控、面试权重最重的核心模块，没有之一。

前面七篇我们打通了微服务底座、用户、商品、购物车、价格营销、订单交易全链路，所有交易链路的最终卡点全部收敛在库存扣减与释放。订单可以失败、价格可以微调、购物车可以重试，但库存一旦出错，直接引发超卖资损、库存负数、假性售罄、对账不平、用户投诉、平台赔付等致命线上事故。

绝大多数初级开发对库存的认知只有简单的「库存-1」，完全不懂生产级库存的核心逻辑：预扣、锁定、释放、回滚、可售、冻结、已销、预热、兜底、对账全套机制。

大促秒杀场景下，上万并发同时争抢少量库存，普通数据库扣减逻辑直接击穿、超卖严重；同时订单超时、支付失败、退款售后，又会引发库存重复释放、库存脏数据、数据不一致等问题。

本文承接上篇订单中心架构，从零落地企业级分布式库存中心架构，彻底拆解电商标准库存模型、分层库存设计、高并发防超卖方案、分布式锁机制、库存回滚策略、冷热预热、全量对账闭环，根治99%的库存线上故障，完全适配亿级大促流量。

1.2 本文核心收益

读完本文，你将彻底掌握：

• 库存中心DDD限界上下文与领域边界，彻底解耦订单、商品、营销服务

• 电商标准四层库存模型，理清可售、冻结、已售、预留库存逻辑

• 大促高并发防超卖完整方案，Redis+DB双层兜底零超卖

• 库存锁定、扣减、释放、回滚全流程生产级机制

• 分布式场景下库存并发竞争解决方案（分布式锁+Lua原子脚本）

• 大促库存预热、热点隔离、流量削峰高阶优化方案

• 库存脏数据修复、定时对账、异常兜底闭环机制

• 库存高频线上事故根治方案与大厂面试高分架构话术

1.3 前置链路回顾

承接前七篇完整链路：用户下单 → 购物车结算 → 价格引擎核算实付金额 → 订单服务创建待支付订单 → 库存中心执行预扣锁定 → 支付成功真实扣减 → 订单取消/退款库存释放。库存中心是交易链路的最后一道资损防线，也是高并发流量的最终承压点。

二、库存中心DDD领域边界（架构师红线）

2.1 限界上下文定义

库存领域核心职责：统一管控全平台商品SKU库存数据，实现库存预热、预扣锁定、真实扣减、超时释放、退款回滚、库存对账、脏数据修复，保障全场景库存数据精准一致，杜绝超卖、少卖、库存错乱，支撑大促高并发交易场景。

2.2 领域绝对边界（核心解耦）

2.2.1 归属库存领域

商品库存初始化、大促库存预热、库存预锁定、支付后真实扣减、订单超时库存释放、退款售后库存回滚、库存数据统计、库存对账、异常库存兜底修复、库存缓存一致性维护。

2.2.2 绝不归属库存领域

• 商品基础信息维护：归属商品中心（库存仅关联SKU维度）

• 订单创建、状态流转：归属订单中心（库存只响应订单事件）

• 价格计算、优惠叠加：归属价格营销中心

• 支付扣款、资金清算：归属支付中心

• 活动规则、限购校验：归属营销中心（库存只做最终数量拦截）

架构黄金原则：库存中心只负责「数量管控与数据一致性」，不参与业务计算、不处理交易逻辑，做到单一职责、极致稳定、高并发可用。

三、电商标准四层库存模型（彻底杜绝库存错乱）

所有库存超卖、库存负数、假性售罄、库存对不上的问题，本质都是没有分层库存模型，所有库存数量混为一谈，逻辑混乱无法追溯。

大厂生产级统一采用四层分层库存模型，层层隔离、各司其职，是所有库存架构的核心底座。

3.1 总库存（total_stock）

商品SKU初始配置的原始总库存数量，为静态基准值，仅在商家新增库存、补货时变更，不随下单、支付、取消订单变动。

3.2 可售库存（available_stock）

用户可正常下单购买的有效库存，核心交易库存。参与所有下单预扣、并发拦截、库存校验，是前端展示、下单拦截的唯一可信库存数值。

3.3 冻结库存（frozen_stock）

用户下单成功、未支付期间临时锁定的库存。该部分库存不可被其他用户购买，用于防止并发超卖；订单支付成功转为已售库存，订单超时/取消则释放回可售库存。

3.4 已售库存（sold_stock）

用户支付成功、交易履约完成的真实消耗库存，为最终统计数据，不可逆、不回滚（正常售后退款除外）。

3.5 四层库存核心公式（对账基准）

总库存 = 可售库存 + 冻结库存 + 已售库存

所有库存对账、兜底修复、异常校验，全部基于此公式，确保数据绝对闭环、无偏差。

四、库存完整生命周期（下单-支付-取消-退款）

库存不是单一扣减动作，而是全生命周期流转，每个节点对应不同库存变更逻辑，也是面试高频考点。

4.1 正常交易链路

用户下单 → 可售库存扣减、冻结库存增加（预锁定） → 用户支付成功 → 冻结库存扣减、已售库存增加（真实扣减） → 交易完成。

4.2 异常取消链路

用户下单未支付/手动取消/超时关单 → 冻结库存清零释放 → 可售库存回补恢复 → 库存数据复原。

4.3 退款售后链路

用户发起退款/退货 → 已售库存扣减 → 可售库存回补（恢复可购买） → 库存数据修正。

架构核心：所有库存变更都是双向流转、有据可查、状态闭环，杜绝单向扣减无法回滚的脏数据问题。

五、亿级大促高并发防超卖架构（零超卖生产方案）

5.1 传统库存方案致命缺陷

普通开发者使用数据库 stock > 0 then stock-1 逻辑，无并发控制。大促万级并发下，数据库事务隔离级别无法拦截热点竞争，直接导致超卖、库存负数、资损事故，完全无法生产可用。

5.2 大厂五层防超卖架构（Redis前置 + DB兜底）

采用缓存前置、原子扣减、异步落库、数据库兜底的分层防护，支撑十万级QPS库存并发，实现线上零超卖。

5.2.1 大促库存预热（前置铺垫）

大促活动开始前，将所有热点SKU库存数据全量预热至Redis，避免大促瞬间缓存穿透、DB击穿，所有并发请求优先命中缓存。

5.2.2 Redis Lua原子预扣（核心防超卖）

所有下单库存校验、预扣逻辑，通过Lua脚本原子执行，一次性完成库存判断、扣减、冻结，杜绝并发竞争问题。Redis单线程模型天然解决并发安全，是大促防超卖的核心关键。

5.2.3 分布式锁兜底（精准控并发）

针对超级热点商品，新增SKU维度分布式锁，同一SKU串行处理库存请求，彻底杜绝极端并发场景下的缓存偏差问题。

5.2.4 MQ异步落库解耦

Redis预扣成功后，发送MQ消息异步更新数据库库存，主链路不阻塞DB操作，极大提升并发吞吐量，避免数据库压力过载。

5.2.5 数据库乐观锁最终兜底

异步更新DB时，通过库存乐观锁+字段校验兜底，确保数据库库存不会出现负数、超卖，形成最终闭环防护。

六、库存缓存一致性解决方案（根治数据不一致）

6.1 核心痛点

Redis缓存库存与数据库库存不一致，导致前端展示有库存、下单提示无库存，或展示无库存、实际可下单，引发大量用户客诉。

6.2 生产级一致策略

• 更新DB、同步更新缓存：库存变更后实时更新Redis，保证实时一致性

• 失效兜底机制：商品活动结束、库存清零、补货变更时，主动淘汰旧缓存

• 定时巡检兜底：后台定时任务比对Redis与DB库存差异，自动修复偏差数据

• 读多写少场景缓存常驻，写频繁场景实时同步+短时过期兜底

架构取舍：库存场景优先保证最终一致性，牺牲瞬时极致性能，杜绝展示与实际库存不符的体验问题。

七、生产级库存表结构设计（标准分层模型）

以下为阿里系电商通用生产库存表结构，严格贴合四层库存模型，字段无冗余、索引适配高并发、支持对账兜底。

7.1 商品库存主表 goods_stock

-- 商品SKU库存主表（核心库存数据表）
id              BIGINT    雪花主键ID
sku_id          BIGINT    商品SKU唯一ID
total_stock     INT       总库存数量
available_stock INT       可售库存（可下单）
frozen_stock    INT       冻结库存（下单未支付）
sold_stock      INT       已售库存（支付完成）
version         INT       乐观锁版本号（防并发更新）
create_time     DATETIME  创建时间
update_time     DATETIME  更新时间
deleted         TINYINT   逻辑删除标识

-- 核心索引
PRIMARY KEY (id)
UNIQUE KEY idx_sku_id (sku_id)          -- SKU库存唯一匹配，极速查询
INDEX idx_update_time (update_time)     -- 库存变更时间追溯、对账筛选

7.2 库存变动流水表 stock_log

-- 库存变动流水表（对账核心、可追溯）
id              BIGINT    主键ID
sku_id          BIGINT    商品SKU ID
order_no        VARCHAR   关联订单号（无则为空）
change_type     TINYINT   变动类型（1-下单冻结 2-支付扣减 3-取消释放 4-退款回补 5-商家补货）
change_num      INT       变动数量
before_stock    INT       变动前可售库存
after_stock     INT       变动后可售库存
remark          VARCHAR   变动备注
create_time     DATETIME  变动时间

-- 核心索引
PRIMARY KEY (id)
INDEX idx_sku_time (sku_id,create_time) -- 商品库存流水查询
INDEX idx_order_no (order_no)           -- 订单维度库存追溯

设计亮点：流水表永久留存，所有库存变动有据可查，是库存对账、异常排查、资损追溯的唯一核心依据。

八、库存定时对账与脏数据修复闭环

8.1 对账核心价值

长期运行的系统，会因MQ消息丢失、重试异常、缓存偏差、数据库超时等问题，产生微量库存脏数据，日积月累引发大额资损，必须建立自动对账修复机制。

8.2 双层对账机制

8.2.1 日级全量对账

每日凌晨低峰期，定时任务遍历所有SKU，校验总库存=可售+冻结+已售公式，筛选异常库存数据。

8.2.2 流水对账修正

基于库存流水表重算真实库存，自动修正主表异常数据，无法自动修复的异常数据推送人工告警核对。

8.3 脏数据自动修复规则

• 可售库存负数 → 强制归零修复，记录异常日志

• 冻结库存长期未释放 → 定时扫描超时冻结库存，自动回补可售库存

• 库存公式不匹配 → 基于流水重算校正主表数据

九、大促库存高阶优化：热点隔离与流量削峰

9.1 超级热点商品痛点

大促秒杀爆款商品，单SKU瞬时十万级QPS，极易引发缓存热点、DB热点、服务线程池打满问题。

9.2 热点库存隔离方案

• 独立缓存Key隔离：爆款SKU单独缓存，避免热点Key过期击穿批量失效

• 单机本地缓存兜底：短时本地缓存拦截重复无效请求，降低Redis压力

• 限购规则前置拦截：用户维度限购校验前置，拦截黄牛批量刷库存流量

• 流量分层削峰：网关限流、服务熔断、队列缓冲，保护核心库存逻辑

十、生产高频踩坑复盘（真实库存资损事故）

10.1 坑点1：并发超卖，库存负数资损

现象：大促爆款商品库存1000件，最终成交1200件，库存负数。

根因：纯数据库扣减，无Redis原子控制、无并发锁，竞争穿透导致超卖。

根治方案：Redis Lua原子预扣 + 数据库乐观锁双层防护。

10.2 坑点2：订单超时未释放，库存假性售罄

现象：商品显示无库存，但大量用户未支付订单占用冻结库存，无法正常下单。

根因：延迟消息丢失、无定时兜底扫描，冻结库存长期不释放。

根治方案：延迟消息精准释放 + 定时巡检兜底双机制。

10.3 坑点3：缓存与DB库存不一致，用户大面积客诉

现象：页面显示有库存，下单提示库存不足。

根因：库存更新DB未同步更新缓存，旧缓存残留。

根治方案：库存变更实时同步缓存 + 定时对账修复偏差。

10.4 坑点4：退款订单库存不回补

现象：用户退款成功，商品库存不恢复，库存总量持续亏损。

根因：退款异步消息消费异常，无重试兜底机制。

根治方案：退款事件可靠投递 + 流水对账自动修复。

十一、大厂面试高频考点 & 架构师高分话术

1. 电商如何彻底解决库存超卖问题？说说你的双层防护架构？

2. 为什么大促库存必须用Redis Lua，不能直接操作数据库？

3. 冻结库存如何释放？如何避免库存长期占用、假性售罄？

4. Redis缓存库存和DB不一致怎么解决？如何保证最终一致？

5. 长期运行的库存脏数据如何发现、如何自动修复？

高分架构思路：先讲四层库存模型规范数据定义 → 再讲Redis原子防超卖核心方案 → 再讲库存全生命周期流转机制 → 最后讲缓存一致+定时对账兜底闭环，体现完整库存架构体系思维。

十二、本篇总结 & 下篇预告

12.1 本篇总结

本文承接前七篇交易链路，完整落地了亿级高并发库存中心生产架构，从DDD领域边界、四层库存模型、全生命周期流转、大促防超卖架构、缓存一致性、对账兜底、踩坑复盘多维度，彻底解决电商库存所有核心难题，补齐交易链路最后一块核心短板。

核心架构思维：库存的核心是精准与兜底，高并发靠缓存原子能力，数据一致靠全链路闭环，杜绝一切资损与脏数据。

12.2 下篇预告

本专栏总计26篇亿级电商架构持续连载中，下一篇第九篇：支付与清算中心架构落地，深度拆解第三方支付对接、支付回调幂等、退款闭环、资金清算、对账体系、资损防控、支付高可用架构，打通电商资金链路完整闭环。