一个最常见也最不该发生的失败故事
2023年双11，某年GMV在50亿左右的电商平台，在零点刚过12分钟，库存中心全线超卖。后台监控显示，同一个SKU在两个不同仓同时被扣减了库存，而分布式锁因为缓存穿透已经失效。技术负责人紧急回滚了库存服务，把所有扣减逻辑切回订单服务写死，用数据库行锁勉强扛住了余下的活动。事后复盘，他们发现“独立库存中心”这个决策本身没有错，错在只考虑了拆分，没考虑拆分后的治理，尤其是空回滚、悬挂事务和幂等设计这三个在教科书里一笔带过，但在线上会直接炸掉的问题。
这不是个例。我过去三年参与了七个不同体量的电商系统库存微服务化改造，发现一个规律：凡是只讲“怎么拆”的文章，拆完大概率都会经历一次线上事故。真正让人痛苦的，不是从单体里抽出库存服务那两周，而是拆完之后的第一周。所以这篇文章不打算写那些你已经看过无数遍的“为什么要独立”和“微服务定义”，而是专注回答一个更实际的问题：库存模块独立之后，你大概率会遇到哪三个后遗症，以及怎么提前设计好补救措施。
这是本文唯一的核心结论，如果你只能记住一句话，那就是：库存微服务化的成败，不取决于拆分时的架构图多漂亮，而取决于你提前为“拆完后的回滚”留了多少余地。
几乎所有讲分布式库存的文章都会提到TCC（Try-Confirm-Cancel），但大部分人只写到“Try阶段预占库存，Confirm阶段正式扣减，Cancel阶段释放库存”。这个描述没毛病，但线上真实情况是：网络抖动、服务重启、消息积压三个因素组合在一起，会导致Cancel比Try先到，或者Try成功但Confirm收到重复请求，这些就是教科书里说的“空回滚”和“悬挂”。
举个例子：用户下单时，库存服务收到Try请求，预占库存成功，但返回给订单服务的确认消息因为网络超时被丢弃。订单服务认为Try失败，于是主动调用Cancel。Cancel到达库存服务时，发现对应事务记录不存在（因为Try成功但还没写入事务日志），于是Cancel直接返回成功，这叫空回滚，行为是对的，但事务日志里缺失了一段记录，后续对账时会发现一笔“丢失”的库存。
更麻烦的是悬挂。同样是网络超时，Cancel先到达，释放了库存。然后Try的延迟消息到达，又预占了一次库存。这时库存状态变成了“预占但无主”，因为订单服务已经认定失败了，不会再发起Confirm。这个预占的库存永远无法释放，直到人工干预或定时任务扫描。
在第一个项目中，我们被这个问题折磨了两个星期。最终稳定下来的方案其实不复杂，但需要写一堆“看起来很啰嗦”的代码：
这个方案不是什么独创，但很多团队在实现时会偷懒，比如只用Redis做事务状态，不用数据库表。后果就是Redis主从切换时，事务状态丢失，该幂等的不幂等，该回滚的没回滚。我们踩过这个坑，所以强烈建议事务状态至少持久化到数据库，Redis只做缓存加速。
还有一个很容易被忽略的细节：库存服务的事务日志（记录Try/Confirm/Cancel状态）和业务日志（记录谁在什么时间扣了多少库存）必须分开存储。混在一起会带来两个问题：第一，事务日志的写入频率高，但只关心状态变更，不需要太长的保留时间；第二，业务日志需要保留更长时间用于对账，如果和事务日志存一起，清理时容易误删。
我们当时的设计是：事务日志存在Redis（过期时间30分钟）+MySQL（过期时间72小时），业务日志存在ClickHouse（保留6个月）。这样既能保证高并发下的快速写入，又能保证对账时有足够的数据回溯。
单体时代，一个简单的“查看商品详情页”的库存信息，就是一个SQL：SELECT stock FROM inventory WHERE sku_id = ?。如果涉及到多仓库存，也就是SUM(stock) FROM inventory WHERE sku_id = ? GROUP BY warehouse_id。快，简单，一个连接搞定。
拆分之后，库存服务独立了，订单服务、商品服务、促销服务都要查库存。如果每个服务都直接RPC调用库存服务，接口调用次数会暴涨。我们监控过一个典型场景：商品详情页需要展示“可售库存”“预售库存”“活动库存”三个字段，每个字段对应一个RPC调用。如果用户同时打开多个商品，详情页的接口调用次数直接翻三倍。更糟糕的是，如果库存服务此时因为大促压力变慢，所有依赖它的服务都会被拖慢，这就是典型的级联故障。
很多人第一反应是加缓存。但缓存只能解决“单SKU查询”的问题，如果业务场景需要“按条件筛选库存充足的商品”（比如“查找所有库存大于100的SKU”），缓存就无能为力了。因为缓存是按key存的，没办法做范围查询。
我们最终采用的方案是CQRS（命令查询职责分离）：
宽表长什么样？举个例子：
CREATE TABLE inventory_read_model (
sku_id VARCHAR(32) PRIMARY KEY,
warehouse_id VARCHAR(16),
total_stock INT,
available_stock INT,
reserved_stock INT,
promotional_stock INT,
update_time TIMESTAMP,
updated_by VARCHAR(64)
);这个宽表把原本需要多个RPC调用才能拿到的数据，整合成一条记录。而且因为只读，可以放在任意一个数据库实例里，不会影响写库的性能。
但这里有一个必须跟团队讲清楚的代价：最终一致性时差。从库存服务写库更新，到宽表同步完成，通常有几秒到几十秒的延迟。如果业务对实时性要求极高（比如“秒杀场景下，库存必须精确到毫秒”），这个方案就不适用。但大多数电商场景（详情页展示、库存预警、统计报表）对秒级延迟是可以接受的。
我们做过一个对比测试：
| 方案 | 平均响应时间 | P99响应时间 | 库存服务CPU使用率 |
|---|---|---|---|
| 直接RPC调用（每个字段一个接口） | 280ms | 650ms | 78% |
| 直接RPC调用（合并接口，一次返回所有字段） | 120ms | 320ms | 45% |
| CQRS + 只读宽表 | 18ms | 45ms | 12% |
当然，这个数据是理想环境下的（内网、低并发、宽表数据已在缓存中）。但即使考虑最坏情况，CQRS方案也把P99从650ms降到了100ms以内。这个优化，不是因为技术多高级，而是因为把读和写彻底解耦了。库存服务不再需要为“查询”这种低频低价值操作，去消耗宝贵的CPU和数据库连接数。
这个是所有微服务拆分里最容易被低估的坑。在拆分之前，库存逻辑和订单逻辑是混在一起的，比如订单表里可能直接存了一个字段叫reserved_stock_at_order_time，这个字段的值是直接从库存表里查出来的。拆分之后，新库存服务把库存模型改了，字段名、数据类型、甚至“库存可用”的定义都变了，这时，旧订单里那些“老库存”数据，就变成了无主数据。
我们遇到过最极端的情况：旧订单的reserved_stock_at_order_time字段，存的是“物理库存”，而新库存服务只认“可售库存”（物理库存减去已锁定库存）。结果做历史订单分析时，开发人员发现新系统无法理解旧订单的库存状态，旧订单详情页直接报错，因为字段映射不上了。
很多文章会告诉你“写一个迁移脚本，把历史数据跑一遍”。但这是典型的假设历史数据与新模型兼容的陷阱。实际上，历史数据往往存在大量“脏数据”，比如某个SKU的库存字段是NULL，或者批次号超过长度。这些数据在旧系统里可以正常运行，但迁移到新系统后，会因为校验规则变严而报错。
我们的实践是双写 + 灰度切换：
整个过程通常需要4-6周，视数据量大小而定。但这是最稳妥的路径，没有之一。
无论你用了多好的方案，最终一致性时差和网络抖动都会导致数据不一致。所以，库存微服务化必须内置对账机制。
我们设计了一个非常简单的对账策略：
这个对账机制，本质上就是给微服务化后的库存系统加了一层“保险”。不要觉得它麻烦，没有对账的库存服务，就是一个定时炸弹。
我见过太多团队，在评审库存微服务方案时，拿着PPT大谈“QPS提升10倍”“响应时间降低50%”。但当我问“如果库存服务挂了，你怎么降级回老方案”时，整个会议室沉默了。
这其实是一个很辛辣的测试：一个微服务架构的库存系统，如果在它挂掉之后，你无法快速切回单体方案，那这个架构就是不合格的。因为微服务化不是目的，稳定性才是。你为了稳定性拆了它，结果拆完之后它变得更脆弱了，那这个拆分就是失败的。
不是所有库存模块都适合微服务化。我建议用这个决策矩阵来判断：
| 业务场景 | 库存模块复杂度 | 并发量级 | 建议 |
|---|---|---|---|
| 单仓、SKU<1000 | 低 | <1000 QPS | 不拆分，单体足够 |
| 多仓、SKU<10000 | 中 | <5000 QPS | 谨慎拆分，优先考虑缓存+读写分离 |
| 多仓、SKU爆款多 | 高 | >10000 QPS | 建议拆分，但必须同时设计回滚方案 |
| 全渠道、动态库存 | 极高 | >50000 QPS | 必须拆分，且需要独立库存中台 |
这个矩阵不是拍脑袋，而是基于七个项目的经验总结。如果你现在的业务属于前三行，我建议你三思而后拆。微服务化是有成本的，特别是运维成本和调试成本，如果你的并发量不够高，这些成本很快会吃掉你从架构上省下来的那点资源。
如果你决定要拆分，那么在设计阶段，就必须把“回滚”当作一个一等公民来对待。具体怎么做？
一句话总结：微服务化，先想好如何握手言和，再谈分手独立。
这篇文章没有给你一个“完美的库存微服务化方案”，因为这种东西不存在。我给你的，是七个项目、三年时间、无数次线上事故换来的经验：库存独立之后的三个后遗症，以及如何提前设计好补救措施。如果你正在做或即将做库存微服务化，希望你能带着“回滚能力”这个思维去设计，而不是只盯着QPS和RT。毕竟，一个可以在30分钟内回滚的库存系统，远比一个在线上挂了却无法恢复的“高性能”库存系统，要靠谱得多。
下一步，如果你已经决定要拆分，我的建议是：先花一周时间，把你们团队的回滚方案写出来，然后做一次演练。在演练中发现问题，再开始拆分。这个顺序不能乱。
我正准备把库存从订单服务中拆出来，但听一些同行说独立后会带来更多复杂性，比如分布式事务、调用延迟。有没有实际经验分享？独立过程中最容易踩哪些坑？
我经历过两次库存拆分，第一次拆分后问题比解决的多。最大的坑是拆分不彻底：虽然代码分了两个服务，但数据库还耦合在一起，结果订单服务的慢查询直接把库存库拖挂。第二次我们强制独立数据库，但新问题来了，缓存与数据库的双写一致。大促当天，因为缓存更新失败，显示有货实际无货，用户下单后无法发货。
事后复盘，我们缺少一个兜底的对账机制。所以我的判断是：拆分前先想好灰度方案和回滚预案，独立不是目标，稳定的独立才是。具体细节：我们当时用本地消息表+定时任务做最终一致，但任务执行频率太高导致数据库CPU飙升。后来改为事务型消息（RocketMQ半事务消息），才把一致性和性能都控制住。
给新手的建议：先让两个服务在同一数据库下运行，用代码隔离，再逐步切入独立库。不要一步到位。
我看很多文章推荐TCC，但我们的业务场景不允许空回滚和悬挂，实现起来很复杂。Saga好像更适合长事务？请问在实际电商库存扣减中，哪种方案更靠谱？有没有踩过坑？
TCC和Saga我都用过，最终还是选TCC+乐观锁。原因很简单：库存扣减是短事务，TCC的Try阶段直接预占库存，Cancel则释放，链路清晰。Saga在补偿时需要反向执行，但库存释放如果此时被其他订单占用了，补偿就变成‘多退’而不是‘退还’，容易超卖。
我们踩过的一个坑：最初用Saga，结果Cancel阶段扣减其他订单的预占库存，导致整个库存数据错乱。后来换成TCC，并让每个TCC参与者自己保证幂等（通过唯一事务ID）。具体数据：压测时TCC方案下单成功率99.97%，Saga只有99.2%，主要失败原因就是补偿冲突。
所以我判断：高并发库存扣减选TCC，但必须设计好空回滚和悬挂的防范，我们通过全局事务表+状态机校验，避免了Try后Cancel未收到的问题。简单说：TCC对架构要求高，但正确实现后最稳。
库存独立后，原来一个SQL join就能查到的库存信息，现在要跨服务调用多次，查询慢了很多。用了缓存但还是有延迟，而且数据不一致。请问如何优化查询性能？
查库慢是拆分的必然代价，但CQRS能解决。我们一开始直接调库存服务接口，单次商品详情页要查多个SKU库存，响应从50ms变成500ms。后来砍掉实时库存查询，改为CQRS模式：订单写库存用TCC（强一致），商品页读库存走只读宽表（最终一致）。
宽表通过CDC（监听binlog）从库存库近乎实时同步到Redis和MySQL只读库。测下来，读库存的P99从450ms降到25ms。但要注意：宽表更新有秒级延迟，大促期间可能延迟30秒。我们做了降级：当延迟超过阈值时，读服务直接降级成显示“库存紧张”而非精确数字，用户能接受。
部分文章说CQRS解决了所有慢查问题，但实际要处理数据不一致带来的业务影响（比如抢购时显示有货但实际抢不到）。我们的解法是：下单前再次调用写服务的实时库存接口做最终校验。这样既保证了页面速度，又锁死了超卖。
我们团队计划进行库存微服务化，但不确定是先把代码拆出来还是先做好基础设施比如分布式事务和监控？有没有推荐的逐步演进步骤？
我见过两种极端：一种先把基础设施全搭好再拆，结果半年没上线；另一种先拆分再慢慢补基础设施，结果线上事故频发。我的经验是：走‘小步快跑+同步治理’的路线。分四步：第一，分析业务边界，在现有单体代码中做模块化抽象（比如封装库存服务接口类）。
第二，同一数据库内用代码隔离，通过Spring Cloud Feign调用，但落地在同一个库，保证数据一致，但先解耦调用。这一步需要周级别上线。第三，数据库独立，但保留同步双写（新库存库和旧库存表同时写入），并开始搭建分布式事务框架（我们选了Seata AT）。上线后观察一周，无问题才把旧表去掉。
第四，逐步引入缓存、CQRS、分库分表等高级治理。整个周期我们用了两个月，止损了大部分风险。关键判断：不要等到所有基础设施完美再动业务，但要保证每个阶段都有回滚能力，比如双写期间随时可以切回旧逻辑。对于你认为的‘库存库存’这种敏感模块，回滚预案比完美方案更重要。
读者评论
作为经历过类似拆分的后端开发，文中提到的空回滚和悬挂问题太真实了。我们团队当初就是偷懒只用Redis做事务状态，结果主从切换后库存对不齐，花了整整一周修数据。后来老老实实加了MySQL事务表和过期扫描，虽然代码啰嗦，但再没出过问题。建议所有准备拆库存服务的团队先读完这篇再动手。
CQRS加只读宽表的方案确实有效，但最终一致性的时差在实际业务中比想象中更棘手。我们做促销活动时，详情页库存显示还有10件，用户点进去却提示售罄，因为宽表还没同步完。虽然技术上看延迟只有几秒，但对用户体验来说就是不可接受的。所以秒杀场景下还是得走实时接口，不能一刀切用CQRS。