我记得上个月双十一，有个朋友在商场买鞋，导购说没货了，他掏出手机一看，官方商城明明显示库存还有2双。当场发飙。说实话，这种破事儿我见得太多了。线上线下一体化喊了多少年，结果库存都搞不同步，还谈什么体验？
今天不聊概念。就拆库存同步这个最要命的环节，看看它到底卡在哪。
物理层的真相：你以为是实时同步？其实全是延迟
多数人想象中，库存就像个共享的水池，线上线下同时舀水。天真了。物理世界有天然的时延——哪怕你用Paxos算法，也逃不过光速限制。门店POS机扫完码，数据要经过边缘网关、专线、中心服务、再同步到电商中台，这一圈下来，200ms算快的。而用户在app上点“立即购买”的期待，是毫秒级响应。
所以架构上必须做取舍。我们早年踩过大坑：用分布式事务强一致，压测时QPS不到300，数据库锁等待直接拖垮整个集群。后来老老实实改成最终一致，配合库存预留机制——就像火锅店的桌位预定。客人打电话说半小时到，老板会把桌子先划掉，但隔壁老王如果直接进店，还是能抢走，除非老板足够强势。线上订单创建时，先扣一个“虚拟池”的额度，物理门店的库存异步冲减。虚拟池怎么算？经验值加预测模型。第一次上线时我们用了最简单的线性回归，结果预测偏差超过30%，后来换成LSTM加实时销量流，才把误差压到5%以内。
看一个真实压测案例。去年大促，我们同时跑了三套方案：方案A纯数据库行锁，方案B Redis分布式锁，方案C基于本地缓存+定时同步。数据说话：
- 方案A：单表支撑212 TPS，CPU飙升到85%，平均响应时间870ms，开始出现死锁。
- 方案B：Redis锁粒度到SKU级，1250 TPS，响应时间骤降至160ms，但锁超时配置搞错了批次，导致一场线上事故——有一个SKU多了卖空3分钟，损失近5万。这就是第二个坑点，后面会细说。
- 方案C：最土但最稳，4800 TPS，响应时间40ms以内。代价是库存精度从秒级退化到分钟级，对高并发品类可接受，但对限量款就是灾难。
那三个让你半夜惊醒的陷阱
踩坑无数，总结三个最要命的，以及怎么爬出来。
陷阱一：分布式锁不是银弹。 刚才说了，Redis锁配了5秒超时，以为足够业务执行，结果那天下单流程里突然插入一个风控调用，耗时飙到8秒。锁自动释放，第二个请求进来又扣了一遍库存。解决方案是锁续期（watch dog），但我们团队又踩了另一个坑：红锁算法在Redis集群漂移时居然失效了！最后换成了基于ZooKeeper的临时顺序节点，加上本地版本号乐观锁。丑但可靠。记住，锁一定要配合数据库的版本号或库存余量做双重校验，别信任何单点保障。
陷阱二：网络分区时的数据冲突。 门店突然断网，POS机还在卖。等网络恢复，上传的销售流水和中心库存合并时，必然出现冲突。我们第一版用“最后写入胜出”策略，结果丢了一笔重要客户的订单——他明明在实体店买了，系统却判定为无效退回库存，线上又卖了一次。后来改成基于操作时间的冲突检测，配合人工审核队列。一个更难搞的是，业务要求“顾客体验优先”，意味着冲突要自动合并，算法复杂得让人头秃。CRDT数据结构了解一下？我们用G-counter实现了可收敛的库存计数器，但性能损耗不小，小团队慎用。
陷阱三：热点库存打爆系统。 爆品抢购时，单一SKU的读写请求能把数据库或Redis分片打穿。本地缓存+定时同步方案在上面测出4800 TPS，但它也有命门：如果缓存更新不及时，超卖依然发生。我们的终极大招借鉴了CPU的MESI协议思想：库存分割技术。把总库存拆成若干槽位，每个节点独占几个槽位，扣减时只动本地槽位，异步上报。槽位分配有试探算法，类似一致性哈希。大促实战中，单SKU扛住了2.3万TPS，延迟中位数11ms。代价是什么？库存碎片化，总可用库存可能少于实际，需要定期归并。但比起当机，这完全能接受。
工程美学的落地：简单即是美
看过很多花里胡哨的架构图，最后活下来的都是最简单粗暴的设计。我们的线上线下一体化库存系统，现在核心方案就四个字：预扣+对账。线上订单生成时，按SKU硬编码的虚拟池比例预扣；线下销售通过离线流水上传，准实时对账刷新池子水位。对账引擎用Flink，滑动窗口10秒，任何差异触发钉钉告警。数据库选型？TiDB好不好？好，但我们实测发现，库存场景写多读少，最终用了MyRocks引擎的MySQL分库分表，配合异步刷盘和批量合并写入，写入延时从平均40ms降到8ms。简单。但管用。
别总想一步到位。什么中台战略、全域营销，底层不扎实都是空话。先把你那库存弄同步了，再谈花活。
