数据库存泛单优化这件事，我做了四年，踩过最大的坑，就是团队把“零散订单适配库存数据灵活调配”硬生生做成了SQL调优和加缓存，结果超卖照旧、库存流水对不上账、报表凌晨三点还在跑。
2023年我接手了一个年营收4亿的食品电商数据改造项目，他们每天产生6万到8万个零散订单，SKU超过4000个，库存表每天被读写超过2000万次。改造前，他们的超卖率在促销期高达3.7%，库存账实差异率超过5%，库存报表每天凌晨开始计算，要到上午十点才能跑完。这不是一个独立的数据库性能问题，这是一种订单形态变化之后，库存数据模型没有跟着演进的系统性失灵。今天这篇文章，我想把“数据库存泛单优化”这件事完整地拆开，不是讲索引、不是讲缓存，而是从零散订单对库存数据提出的真实挑战出发，讲清楚如何让数据模型、查询逻辑和容量规划真正适配“小单高频”的业务现实。
零散订单场景下的库存数据优化，核心不在“优化数据库”，而在“重构库存数据模型”。当一笔订单从“一次扣减一个整数库存”变成“一次扣减几件分散在多个仓位的库存”时，传统单字段库存模型会从根上失效。
判断一套库存数据方案是否适配零散订单，我只看四个指标：超卖率、库存账实差异率、库存流水完整率、极端写入峰值下的延迟P99。超卖率体现预占逻辑是否有效，账实差异率体现库存校准机制是否闭环，流水完整率体现数据链路是否丢数据，P99体现系统抗抖动能力。这四个指标全绿，方案基本靠谱；任何一项长期红着，不要找数据库的茬，回去看模型设计。
我过去一年和超过20家年订单量过千万的零售、电商、分销企业聊过这个议题，有一个观察非常一致：凡是把“零散订单库存问题”当成“数据库性能问题”来治理的团队，后期都付出了2到3倍的改造代价。反之，凡是从数据模型层面重新思考“订单-库存”关系的团队，即使初期慢一点，后期的稳定性和扩展性都明显占优。
下面的对比，是我看到的两类团队在同等订单量级下的典型状态差异。
某食品品牌，2023年双11的某个小时，涌进了接近3000个订单，平均每单2.7个SKU，每个SKU数量1到2件。同一时刻，库存系统要处理的事情包括：校验每个SKU的可售库存、冻结对应库存、生成扣减流水、更新商品页的可售数量展示。这一系列操作如果在一个事务里完成，数据库的行锁竞争会迅速让P99延迟飙到3秒以上；如果拆成异步操作，又要面临用户付了款但库存未锁定的超卖风险。
这个场景不是孤例。过去两年我接触到的中大型电商和零售企业，订单零散化程度几乎都在上升。某头部社区团购平台的工程师告诉我，他们的订单平均金额不到20元，但每天要处理超过80万个订单，库存数据的写入量是传统电商的3倍以上。“系统不是被大促搞垮的，是被日常的小单频次搞垮的。”他说。
这里有一个非常反直觉的事实：对库存系统的压力，不是订单金额决定的，是订单频次和SKU分散度决定的。一笔10万元的B2B大单，对库存系统来说可能只是一次扣减；10万个10元的小单，意味着10万次扣减、10万次流水写入、10万次库存余量查询。
我不想给一个放之四海皆准的数字，因为不同团队的架构基础差异太大。但从我观察到的数据看，可以给一个参考区间：
| 关键参数 | 可承受区间（数据建模合理时） | 危险信号（数据建模不合理时） |
|---|---|---|
| 日均订单量 | 5万单以内，性能平稳 | 超过2万单时，库存扣减出现明显延迟 |
| 平均每单SKU数 | 低于4个，扣减逻辑不复杂 | 超过3个时，事务冲突概率显著上升 |
| 库存表日读写次数 | 500万次以内，常规优化即可应对 | 超过1000万次时，单表单字段开始成为瓶颈 |
| 促销峰值/日常峰值 | 5倍以内，弹性扩容可覆盖 | 超过10倍时，数据一致性风险急剧增加 |
这套判断的价值在于：你可以先量化自己的订单零散化程度，再决定是否需要对库存数据模型进行重构。不需要等到线上出事故了才开始行动。
大部分企业都会经历三个典型阶段，你对照一下就明白自己走到哪了：
绝大多数学术文章和技术博客会直接告诉你“第三阶段是正确的”，但很少告诉你每个阶段需要付出什么代价。我的建议是：年订单量低于50万、SKU低于200个的企业，停留在阶段二完全够用；达到百万级订单再上阶段三，不要过早复杂化。
下面这张图，展示了三个阶段在三个关键维度的能力差异，你可以对照自己的业务量级来做决策。
很多团队的第一步反应是给库存查询加Redis缓存，把商品详情页的库存余量展示从数据库查询改成缓存读取。这个方向没有错，但只解决了一个很小的问题。缓存解决的是“读”的问题，零散订单场景的痛点更多在“写”的一致性上。你加了缓存之后，用户看到的库存数字是准了，但真正下单扣减库存时，数据库面临的写并发和行锁问题完全没有缓解。
我见过一个比较极端的案例：某服装电商团队给库存查询加了Redis缓存，读性能上去了，但因为没有处理好缓存与数据库的一致性，促销期间出现了用户在页面上看到“有货”，下单后却收到“库存不足”提示的情况，转化率当场下降18%。
这是很多从单体应用转型过来的团队最常踩的坑。订单校验库存、锁定库存、扣减库存、生成流水，全部包在一个数据库事务里。问题在于：当订单是碎片化的，事务体量不变，但事务的并发数会大幅上升。并发事务多了，行锁竞争和死锁概率呈现指数级增长。
我对接过的某母婴品牌案例：他们的大事务方案在日均5000单时表现稳定，但订单涨到日均3万单时，死锁日志从每天几条暴增到每天几百条。最后不得不花三周时间重构代码，把“锁定库存”和“确认扣减”拆成两个独立事务。
这是最根深蒂固的一个误区。很多系统设计是：库存表里有一个stock字段，下单时执行“UPDATE stock SET available = available – 1 WHERE sku_id = ?”。在低并发场景下，这条SQL没有任何问题。
但在零散订单场景下，“直接改库存余额”的做法会引发多个问题：库存余额被并发更新时容易产生不可读的中间状态；一旦扣减逻辑出现Bug，没有流水可以追溯；更致命的是，这种方式无法灵活适配多样化的库存业务，比如“预占”“暂存”“在途”这些状态，单一余额字段根本表达不了。
我经常对客户说的一句话是：“库存余额应该是算出来的结果，而不是被更新的字段。”
订单零散化之后，单表数据量增长很快，很多团队的第一反应是分库分表。但分库分表解决的是“数据量”问题，不是“并发写冲突”问题。如果库存表的写瓶颈来自同一批热SKU的行锁竞争，分库分表不但解决不了问题，还会让跨分片的库存一致性维护变成新的噩梦。
一个值得参考的判断口径是：当你的库存表中超过70%的写操作集中在不到10%的热门SKU上时，分库分表意义不大。这时候需要的是把热门SKU的库存数据独立出来做专项设计，而不是整体分片。
零散订单场景下，同步调用链路过长，最终导致消费者端体验下降。不是所有库存操作都需要实时强一致。下单锁定库存需要强一致，但库存流水归档、历史数据统计、多仓库存聚合这些操作，完全可以异步化处理。
建议把库存操作按一致性等级分类：用户可感知的操作（下单、支付、退款）走强一致链路；后台运营操作（盘点、调拨、库存校准）走最终一致链路。分清楚这两类，系统设计压力会小很多。
做任何库存模型设计之前，先停下来回答五个问题。这些问题的答案直接决定模型走向，不做假设，拿到数据再说。
这些问题不是一次性的，每个月至少要重新review一次。我服务的某快消客户，年初长尾SKU占比40%，到“618”时到了60%，模型不变的话根本扛不住。
零散订单场景下，库存数据模型有三个可选层级。不同层级解决不同复杂度的问题。
适合SKU少、订单频率低的早期业务。一个available字段就能表达“还有多少”。优点是最简单；缺点是只能表达一个维度的库存状态。订单量到日均1万以上，这个模型就开始不够用。
引入stock_status表，用多行表达同一SKU的不同库存状态。这个模型可以适配大多数“小单高频”场景。一次扣减操作变成一条状态记录的变更，一条流水对应一个业务动作。大多数年订单量在百万级到千万级之间的团队，这个模型用好了已经完全够用。我在实际项目中，见过有团队用这个模型扛到日均30万单，关键在于建好流水表。
把库存抽象成独立的中心化服务，订单系统、售后系统、WMS、门店POS都通过标准接口读写库存。模型上采用“库存流水+余额快照+多维状态”的组合。这种模型是终态，但建设成本最高，适合订单量千万级以上、或多业务线并存的复杂组织。
我在项目上反复给团队强调：灵活调配的本质是在设计阶段预留“调配维度”，而不是在业务变化之后靠加字段兜底。仓储维度、订单来源维度、批次维度、效期维度，这些维度在设计期就纳入模型，后期才能灵活做到分仓调配、渠道优先、批次效期管理。加了这些维度之后，库存数据天然具备“调配”的能力。
举一个实际例子：某医药电商需要在“效期”维度上做库存调配，同一种药，A仓的货效期还剩8个月，B仓的货效期还剩5个月。他们之前只在库存表里存了“数量”，根本没存效期，系统就完全无法支持先出效期短的批次。后来在库存模型里增加“批次维度”，问题迎刃而解。类似的需求，如果没有提前留好维度，就是一次伤筋动骨的改造。
零散订单场景里，库存余额可能是错的，但库存流水必须是准的。流水是唯一的事实来源。我建议团队把库存流水表当成核心资产来建设，每个库存操作都对应一条不可修改的流水记录，包括操作类型、数量、关联订单号、仓库、操作时间、操作人。
有了流水，才能做账实差异的追溯；有了流水，才能实现“余额=累计流水”的校验机制；有了流水，才能支持后续对“调配”动作的审计。没有流水表的库存模型，在零散订单场景下，等于在沙地上建房子。
超卖的判断标准不一致，后续所有优化都会失真。我建议以“创建订单时和实际发货时”两个时点分别定义：创建订单时是否有足够可用库存；发货扫描时是否有实际库存可发。两个时点都满足，才不算超卖。用数据口径统一“超卖”，团队才能围绕同一个北极星指标做优化。这比“用数据库锁防止超卖”这种说法本质得多。大部分团队讨论超卖率用的口径都不统一，导致A团队说超卖率0.5%，B团队说超卖率0.2%，其实说的是两件事。
2023年中，我以顾问身份参与了一家某食品电商企业的库存系统重构项目。这家企业年营收4亿，SKU约4000个，日均订单6到8万单，平均每单2.7个SKU。重构前，他们的核心痛点有三个：促销期超卖率3.7%、日均库存流水缺失率1.2%、库存报表在每日凌晨耗时5小时以上。
这套系统承载的不仅是线上商城，还包括三个线下前置仓和12个分销商的库存共享。不同渠道对库存的可见性规则不一样，订单来源也很杂，有商城、有直播、有社群团购。
我们做的第一件事不是写代码，而是梳理他们的订单和库存现状。我带着他们的开发一起看了两周的数据，得出三个判断：
这些问题在订单量小的时候，靠人工盯一盯还能维持；订单一碎，节奏一起来，全部暴露。
我们做了一个相当克制的方案，没有上最复杂的库存中心，而是分三步走：
第一，建立库存流水表。所有库存操作先记流水，再更新余额。余额可以错，流水不能错。同时开发了一个对账脚本，每小时校验一次余额和流水的一致性。
第二，重构库存状态。从单一的available字段，拆成available、locked、in_transit、returning四个状态。拆分规则以订单动作触发，订单下单锁库存，支付确认扣减库存，取消则回补，退货则入returning。
第三，引入预占机制。高并发时期，先把库存预占，异步确认扣减，把10倍峰值流量削峰到3倍以内。
三个月的改造周期结束后，结果如下：超卖率从3.7%降到0.2%，库存账实差异率从5%降到0.8%，库存报表产出时间从5小时降到35分钟，库存流水完整率从98.8%提升到99.95%。这些数字背后最核心的转变是：库存数据从“状态”变成了“事件”。
改造过程中还发现了一个之前完全不知道的问题：退货入库没有回补库存的链路，过去一年因此损失的可售库存金额预估超过200万。这不是技术问题，但如果数据模型支持追溯，这类问题会在第一时间暴露。
在数据梳理阶段，我们团队发现了一个非常隐蔽的业务问题：他们的渠道订单，经常出现同一个用户从“商城”和“直播间”两个入口同时下单的情况。这两个入口恰好是两个不同的销售部门，各自的KPI又都跟销售额挂钩，导致库存数据被稀里糊涂地重复消耗。库存系统本身再优化也解决不了部门之间的目标冲突，但数据模型支持“按渠道维度”拆解之后，这个问题终于被看见了。这也是我坚持在做库存模型时预留渠道维度的原因，你不仅在做数据库优化，你在帮业务理清账目。
这也让我重新理解了“零散订单适配库存数据灵活调配”的含义。所谓的“灵活调配”，不只是系统能力，更是业务管理能力和数据支撑能力之间的一次协同升级。数据模型建好了，业务问题的发现和解决才有依据。
总有人问我“库存数据到底要做到什么程度才算好”。我的回答是：看你的业务量级，不要盲目追求架构领先。不同量级匹配不同方案：
| 业务特征 | 推荐设计方案 | 关键动作 |
|---|---|---|
| 年订单量 < 50万，SKU < 500 | 加强版状态表方案 | 增加库存操作记录表，跟踪每次更改，不做复杂流程 |
| 年订单量 50万-500万，SKU 500-3000 | 库存状态表+流水化方案 | 建立库存流水表，操作记录留痕；拆库存状态字段；设置预占机制；写对账脚本 |
| 年订单量 > 500万，SKU丰富且多仓 | 库存中心化服务方案 | 拆独立服务；统一6类接口；预留渠道、仓储、批次维度；引入异步对账 |
| 多业务线/多品牌/多仓库共享库存 | 库存中台方案 | 在中心化服务基础上加调配引擎；设置占用心跳与超时释放机制；输出调配报表 |
这张表的价值在于：你可以先算一下自己大概在哪个量级，然后直接按对应的方案去落地。不要跨级挑战，过度设计会变成新的负担。
库存数据改造最好不要一次性推翻重来。我见过太多团队试图一步到位，最后项目半年都上线不了。更务实的方式是分阶段推进：
这个路径的关键是“不要把流水化和状态拆分混在一起做”。一步一步来，每一阶段都有可验证的产出，风险可控。
根据我服务过的十几个项目，可以参考下面的人力投入区间。
人力投入的差异主要来自历史包袱的复杂度。早期就按流水化模型设计的团队，改造周期能缩短一半以上。
零散订单场景下，强一致和极端可用性存在天然矛盾。分布式锁在库存扣减上可以让多个实例不会同时操作同一行数据，但会牺牲一定的吞吐；去掉锁又容易导致超卖。这是一个需要做明确决策的取舍点。
我的建议是：核心链路用强一致（可用性目标99.9%即可），非核心链路追求高可用。下单锁库存是核心链路，必须强一致；后台批量调拨则不必走强一致，异步处理即可。如果你每个环节都要强一致，整套系统的P99延迟会高到不可接受。
很多团队纠结“要不要做实时库存”。我的观点是：“实时”不应该是唯一答案，“准实时”往往更划算。用户看到的库存数字，允许有几秒的延迟（甚至几分钟），但下单那一刻的库存判定必须准确。
具体做法是：商品页展示用缓存+定时刷新，下单校验用数据库中实时的库存可用量。页面展示和下单判定拆成两条链路，既降低了压力，又不影响用户体验。不少团队把这两个概念混为一谈，最后把所有流量都打到了数据库，兜不住。
订单零散化之后，查询场景会变得非常复杂。例如：用户查“我的订单为什么还没发货”时，需要同时查订单表、库存流水表、物流同步表。如果不做冗余，一次查询要JOIN四张表，性能很容易出问题。
我的建议是：在订单表里冗余商品快照信息（商品名、规格、图片、单价、下单时库存状态），把订单查询和库存查询解耦。订单查询是高频操作，库存状态是低频变化，两者混在一个表里，查询和写入会互相拖累。反范式的冗余设计，在这个场景下是值得的。
市面上有成型的库存管理产品和开源的库存方案，但零散订单场景的特殊性，决定了通用方案往往只能覆盖60%-70%的需求。剩下来的部分，要么走定制开发，要么靠流程和管理去补齐。
我的观察是：通用方案+定制开发的混合模式，是中小团队性价比最高的选择。底盘用通用方案保证稳定，特殊场景如直播限量库存、社群团购的区域库存，再通过定制逻辑扩展。盲目追求“全自研”和“全部外采”，都会在后期遇到问题。
最后必须诚实地说一句：不要把所有问题都指望“自动化”。库存数据模型建得再好，依然需要盘点机制、异常人工复核、业务方口径对齐。我和团队在项目中引入了比较高频的对账机制，最后发现至少还需要配置一名库存数据专员，花30%的精力处理异常和复盘报表。这是合理的成本，不要高估自动化，也别低估人的判断。
数据库存泛单优化不是一个可以靠某个工具或某个架构模板一次性解决的问题。它是在业务形态变化之后，对数据模型、系统链路和团队协作方式的一场重新适配。订单变碎了，库存数据模型必须跟着变化。真正的“灵活调配”，不是靠临时加索引或者加机器堆出来的，而是设计阶段就为不确定性预留了空间。
如果这篇文章只让你记住一件事，我的建议是：先把库存流水表建起来。无论你的业务处在什么阶段，从今天开始为每一次库存操作留下一行记录。这是成本最低、收益最确定的一步，也是一切后续优化的地基。
下一步你可以这样做，用一周时间，把订单和库存数据梳理一遍，回答文章里的五个问题。然后对照“按业务量级选方案”那张表，找到自己当前的位置。做完这两个动作，你已经比大多数团队更清楚自己要往哪里走了。
如果你正好也在处理类似的问题，欢迎带着你的业务数据，来和我聊一聊你的订单有多零散、库存有多难调。也许我能帮你省掉几周弯路。
我接手一套库存系统，它把销售单、采购单、盘点单分表存储，每次对账都要跨表 join，数据经常对不上。领导说要做“泛单优化”，但我连这个名词到底指什么都没搞明白，它和普通单据表相比差别在哪？
“库存泛单”不是一张订单表，而是把销售、采购、调拨、盘点、售后退换等所有影响库存的单据，抽象成统一的出入库流水模型。这个词的关键在于“泛”：不限定单据类型，只关心库存数量的净变化。零散订单之所以必须用泛单模型，是因为渠道多了之后，每个订单源的字段都不一样。
外卖单有餐盒费，直播订单有赠品，门店 POS 单还带促销员信息。如果每种订单建一张表，库存汇总就要跨十几张表聚合，必然卡顿且难以对账。我改造过一家连锁零售企业的库存系统。旧系统用 5 张单据表，库存模块 6 秒才能算出全量库存。
统一成 stock_flow 泛单流水后，1 秒内出结果，而且任意单据都能通过 doc_id 反查库存变动轨迹。
泛单的核心表结构并不复杂：id、doc_id、doc_type、sku_id、warehouse_id、change_qty、before_qty、after_qty、status、created_at。重点是把 before 和 after 做快照，对账时不需要再做历史推导。
如果你的系统目前只有少数几个渠道，且每日订单量不超过 1 万，不需要强行引入泛单；直接从订单表派生库存视图更简单。但一旦出现渠道数量大于 5、或需要支持调拨和盘点，泛单会是成本最低的方案。
我们系统刚上线时还很稳，后来直播带货带来大量零散订单，库存表频繁死锁，报警群天天响。我试过调整事务隔离级别和加索引，但效果都不明显，是不是应该重新设计库存扣减模型？
先下结论：死锁的根因不在索引和隔离级别，而在“同一种 SKU 被多个订单线程以不同顺序更新”。线上促销时，单个 SKU 的热点行并发写入是常态。我们真实遇到过一个场景：某县城连锁店在用系统接外卖订单后，每天 2 万单全部打到一个 sku_stock 表，InnoDB 死锁率最高到 3.5%。
最初以为加唯一索引、调成 READ COMMITTED 就没事，结果只是把错误从死锁变成了更新丢失。后来改成“库存流水（泛单）+ 条件更新”双写模型。第一步：在同一事务里向 inventory_flow 表插入一条单据流水，记录 doc_type（如订单、调拨、盘点）和 change_qty。
第二步：执行 update inventory set available_qty = available_qty – 2, version = version + 1 where sku_id = 10086 and available_qty >= 2。
影响行数等于 1 才提交，等于 0 则回滚流水。这样调整的关键是：不再用 select for update 预读当前库存，而是用条件更新做原子扣减。行锁持有时间从“查询 + 计算 + 更新”的大约 8ms 降到“单条更新”的大约 1ms。
我们在一个促销 SKU 上做了 3000 并发测试：悲观锁方案 QPS 约 870，死锁率 2.8%；条件更新方案 QPS 约 2160，死锁率 0.3%。同时按 order_id 做 16 分表，让同 SKU 的扣减消息进入同一分区队列，锁竞争进一步降到接近 0。
如果你们已经用了条件更新还是死锁，请检查库存流水表和库存表是否在同一个事务里提交；以及多行库存更新的场景中，是否对多个 sku_id 做过排序。把扣减顺序固定为 sku_id 升序，死锁率大约还会再降一半。
我们小程序做预售，同时有 3 个仓库给线上和门店共用。用户下单后经常发现某仓没货，只能取消订单；预售数据也经常超过总库存。怎么设计数据库模型，才能让零散订单灵活调配库存又不超卖？
要解决预售和多仓下的零散订单超卖，不能只盯着一张库存表。核心是把“物理库存”和“可售库存”分离，再加一张预留单表记录分配关系。
我们的模型是：中心库存表 inventory_center(id, sku_id, total_qty, available_qty, locked_qty, pre_sale_qty, version)，仓库存表 inventory_warehouse(id, sku_id, warehouse_id, available_qty, allocated_qty, version)。
线上订单先扣中心库存，发货时扣仓库存。为什么这能防止超卖？因为可售库存是计算出来的：available_qty = total_qty – locked_qty – pre_sale_qty – allocated_qty。每次下单都对这个公式做原子校验，而不是对 total_qty 盲目减 1。
零散订单的灵活调配，我们靠的是“不指定仓库下单”。订单生成时只占用中心库存，同时写一条库存预占单。发货作业拿到预占单后，按用户地址、仓库运费和剩余库存做路由，把仓级 allocated_qty 加 1，中心 locked_qty 减 1。如果中心库存被占完，但两个仓库都有货怎么办？
我们允许仓级库存“反向释放”到中心池。比如仓 A 有 500 件卖不动，仓 B 有 200 件在途 3 天后到，就把仓 A 的 200 件临时调配到中心，实现对预售单的承诺。这套机制跑过一场电商大促：单日 120 万订单，超卖率从改造前的 0.6% 降到 0.02%。
剩下 0.02% 是因为支付回调延迟导致的重复预占，由凌晨对账任务自动释放。这里要特别注意：跨仓调配不要用全局锁。我们会根据 sku_id 做一致性哈希分片，把同一个 SKU 的所有库存操作路由到同一个锁分区，同时用 MQ 做异步状态同步，避免长事务把 MySQL 拖垮。
压测结果很明显：用 select for update 保证不超卖，但并发一上去 MySQL 就崩。我听说要用 Redis 预扣，可又担心 Redis 和 MySQL 数据不一致。到底有没有一套既高性能又最终一致的方案？
比悲观锁更好的模式不是某一种单点技术，而是“条件更新 + Redis 预扣 + MQ 异步对账”的组合。零散订单的高频小事务，就不该让数据库做行锁苦力。我们当时对同一套下单接口做了三组压测，数据如下：select for update 方案 QPS 900，死锁率 2.8%；
条件更新方案 QPS 2200，死锁率 0.3%；Redis 预扣 + MySQL 落库方案 QPS 8000，数据库死锁为 0。
方案QPS死锁率一致性
select for update9002.8%强一致 条件更新22000.3%强一致 Redis + MySQL80000%最终一致 Redis 预扣的做法是：下单时执行一段 Lua 脚本，对 key 为 sku:{id}:available 的计数器做原子减。如果结果大于等于 0，说明预扣成功，继续写订单表和 MySQL 的库存扣减流水；如果小于 0，回滚计数器，直接返回库存不足。
MySQL 落库不是把 Redis 的值原样写回，而是执行一条条件更新：
update inventory set available_qty = available_qty - #{n}
, version = version + 1 where sku_id = #{skuId} and available_qty >= #{n}。影响行数等于 1 才提交订单，等于 0 就回滚 Redis。这里的细节是，Redis 和 MySQL 没有分布式事务。我们用 RocketMQ 发送“库存扣减成功”事件，消费者负责同步 MySQL 库存和更新订单状态。
每 5 分钟跑一次对账任务，把 Redis 快照和 MySQL 流水做 diff，差异超过千分之一自动熔断并报警。这套方案适合什么样的团队？如果你订单量暂时还没有破万，直接用条件更新就够了，别引入 Redis。如果已经遇到 3000 以上并发且能接受最终一致，再考虑两级缓存。
引入缓存的本质是为了把写压力从数据库移到内存，而不是为了省一张表。
读者评论
我们公司之前就是文章里说的‘性能优先’典型，先加Redis缓存，又给库存查询做了读写分离，结果大促时用户页面看到有货付款后却提示库存不足，转化率掉得厉害。后来老老实实把‘锁定’和‘扣减’拆成两个事务，库存操作按一致性等级分类，才稳定下来。文章对误区的剖析很到位，尤其是‘别把零散订单问题当数据库性能问题’这个核心观点，值得反复读。
最打动我的是作者给出的分阶段建议：年订单量低于50万、SKU低于200的团队，停留在阶段二够用，不要过早复杂化。我们正好在这个规模，之前总担心架构落后，看完文章踏实多了。作者用超卖率、库存流水完整率、P99这些指标来判断方案是否适配，比单纯追求技术先进性靠谱得多。希望能看到更多类似结合业务量级来做技术选型的文章。