库存管理看似只是“增减数字”的简单操作，实则是衔接订单、支付、物流的关键枢纽。哪怕是0.1%的库存数据偏差，都可能引发超卖、漏发等直接影响用户体验与平台信誉的事故。我们团队在为某生鲜电商搭建季节性商品库存系统时，就曾遭遇一场因“分布式事务未闭环”导致的大规模超卖—当平台推出“限时秒杀”活动，上万用户同时下单时，库存数据在多服务交互中出现“幽灵扣减”，最终导致实际发货量超出库存近300单。这场事故不仅让平台承担了高额的赔偿成本，更暴露了库存系统在高并发场景下的设计漏洞。此次复盘，我们将从问题爆发到体系重构的全过程拆解，为电商领域的库存防护提供可落地的技术方案。
该生鲜电商的库存系统，核心需求是支撑“多仓发货+预售+限时秒杀”三大业务场景。系统架构采用“微服务拆分”模式，库存服务独立于订单、支付服务，负责实时更新商品库存、校验库存可用性；订单服务在用户下单时调用库存服务的“预扣减”接口锁定库存，待用户支付完成后，再调用“确认扣减”接口正式减少库存；若用户超时未支付，则触发“库存释放”逻辑。为应对生鲜商品“短保质期、高周转”的特性，系统还需支持“临期库存预警”“跨仓调拨实时同步”功能，确保库存数据与实际仓储情况一致。技术选型上，库存核心数据存储于MySQL，采用“商品ID+仓库ID”双主键设计，并通过Redis缓存热门商品的实时库存，减少数据库访问压力。上线前的压测中，我们模拟了5000用户/秒的下单场景，库存扣减响应时间稳定在50ms内，未出现任何数据异常，所有人都认为这套方案足以应对秒杀活动的压力。
然而在首场“草莓秒杀”活动中，问题却在活动开始后10分钟集中爆发。客服后台突然涌入大量“下单成功却被通知无货”的投诉，部分用户甚至晒出了订单截图与客服的“缺货致歉”消息，在社交平台引发讨论。技术团队紧急核查库存数据，发现后台显示某规格草莓的库存为“-287”，而实际仓库中的该规格草莓早已售罄。更诡异的是，订单系统显示有321单已支付订单关联该规格草莓，但库存系统的“确认扣减”记录仅298条，存在23条“支付完成却未扣减库存”的异常数据。同时，部分用户反馈“下单时显示有库存，点击支付后却提示库存不足”，但订单却被强制生成，陷入“待支付却无法支付”的僵局。这场超卖不仅让平台不得不向287位用户支付“缺货赔偿券”，更因“库存显示混乱”导致后续1小时内该商品的下单转化率骤降40%，直接损失超10万元。更棘手的是，初期排查时，我们反复回放活动日志，却发现库存服务的“预扣减”“确认扣减”接口均返回“成功”，没有任何报错信息，数据异常仿佛凭空出现。
为找到根因，我们成立专项小组，从“接口调用链路”“数据交互时序”“事务完整性”三个维度展开深度排查。第一轮排查聚焦接口调用日志，我们将订单服务、库存服务、支付服务在活动期间的日志按时间戳拼接，发现部分订单存在“支付完成后，库存确认扣减接口被重复调用”的情况—某用户的同一笔订单，支付服务在100ms内连续向库存服务发送了2次“确认扣减”请求，而库存服务均返回“扣减成功”，导致该订单对应的库存被重复扣除。进一步分析发现，这是因支付服务的“异步回调重试机制”设计不合理：当支付平台回调通知超时，支付服务会立即发起重试，且未设置“幂等校验”，导致重复回调触发多次库存扣减。第二轮排查针对“库存预扣减超时”场景，我们发现当用户下单后超时未支付，库存服务的“释放库存”接口偶尔会执行失败—日志显示“释放库存时，数据库行锁等待超时”。原来在高并发下，大量“预扣减”操作占用了数据库行锁，导致“释放库存”的SQL因等待锁超时被中断，而代码中未对“释放失败”场景做重试处理，造成部分被锁定的库存无法及时释放，形成“库存幽灵锁定”，实际可用库存被虚减，间接导致后续下单时的库存判断失真。第三轮排查则锁定了“Redis缓存与数据库数据不一致”的问题：库存服务在更新数据库库存后，会异步更新Redis缓存，但在活动高峰时，部分“数据库更新成功、Redis更新失败”的情况未被捕获—因Redis连接池耗尽，缓存更新请求被丢弃，而代码中未设置“缓存更新失败重试”或“缓存与数据库一致性校验”逻辑，导致Redis中显示的库存高于实际数据库库存，用户看到“有库存”下单，实际却因数据库库存不足导致超卖。
找到三大核心问题后，我们没有停留在“补丁式修复”，而是从“事务闭环”“幂等防护”“数据一致性”三个维度构建完整的库存防护体系。首先，针对“重复扣减”问题，我们为所有库存操作接口添加“幂等校验”机制：在调用“确认扣减”“释放库存”接口时，必须传入唯一的“业务流水号”（如订单号、支付流水号），库存服务将流水号与操作类型（扣减/释放）作为联合唯一键存储在MySQL，若检测到重复的流水号请求，直接返回“操作成功”，不执行实际库存变更。同时，优化支付服务的回调重试策略，将“立即重试”改为“指数退避重试”（间隔1秒、3秒、5秒），并在重试前先查询库存服务的操作结果，避免无效重试。其次，针对“库存释放失败”问题，我们重构了库存事务逻辑：将“预扣减库存”“释放库存”操作封装为数据库事务，并引入“分布式事务框架”（Seata）确保跨服务操作的原子性；同时，为“释放库存”操作添加“定时补偿任务”—每5分钟扫描一次“预扣减超过30分钟未确认”的库存记录，自动执行释放逻辑，并记录补偿日志，由运维人员定期核查。对于数据库行锁问题，我们优化了库存表的索引设计，将“商品ID+仓库ID”的联合主键索引，改为“商品ID+仓库ID+库存状态”的复合索引，减少锁竞争范围，同时将库存扣减SQL改为“乐观锁”实现（通过版本号控制），避免长时间占用行锁。最后，针对“缓存与数据库不一致”问题，我们设计了“缓存更新双保障”机制：一是采用“先更新数据库，再删除缓存，最后异步重建缓存”的策略，避免更新缓存时的并发问题；二是新增“缓存一致性校验任务”，每10分钟抽取10%的热门商品，对比Redis缓存与数据库库存数据，若偏差超过1%，立即触发全量缓存重建，并发送告警信息。同时，优化Redis连接池配置，设置“连接超时重试”与“队列缓冲”，避免高并发下连接池耗尽导致的缓存更新失败。
这场超卖事故的复盘，让我们深刻意识到：电商库存系统的“稳定性”，本质是“数据一致性”与“事务完整性”的双重保障。在高并发场景下，任何一个未闭环的事务、未校验的请求、未同步的数据，都可能成为引发事故的“蝴蝶效应”起点。基于此次经验，我们提炼出三条电商库存系统设计的核心原则。其一，“所有接口必做幂等”—在分布式环境中，网络延迟、服务重试、回调重复等情况无法完全避免，必须通过唯一标识、状态校验等方式，确保重复请求不会引发数据异常，这是防护的“第一道防线”。其二，“事务必须闭环”—库存的“预扣减-确认-释放”是完整的事务链路，任何一个环节的失败都需有对应的补偿机制，不能依赖“默认成功”的乐观假设，通过定时任务、分布式事务等手段，确保事务最终一致性。其三，“缓存不能替代数据库”—Redis缓存的核心价值是“性能加速”，而非“数据存储”，必须设计缓存与数据库的一致性校验、失败重试机制，避免因缓存数据失真导致业务决策错误。
