库存扣减系统最危险的时刻，不是缓存宕机，而是缓存、数据库主库和只读副本都“正常工作”，却在不同时间返回了不同答案。一个请求在缓存中看到库存为 1，另一个请求也看到库存为 1；其中一笔已经在主库扣减成功，读请求却从尚未追平的副本读到旧库存，随后又把旧值回填进缓存。结果可能不是简单的“页面显示慢”，而是重复售卖、订单成功但库存不足，甚至人工无法判断究竟哪一笔请求应该保留。

数据库存：架构师标准化教程：用缓存同步复制保证扣减一致性

先给出本文最重要的判断：缓存同步、数据库复制和库存扣减一致性不是同一个问题，前两者都不能单独保证第三者。缓存解决访问速度和流量削峰，数据库复制解决数据传播与容灾，真正决定“能不能超卖”的，是扣减事务、条件更新、幂等控制、读写路由、失败补偿和对账机制共同形成的闭环。

一、先讲核心结论：缓存不能替代库存事实源

1. 库存一致性首先是业务规则，不是缓存技巧

很多方案一开始就讨论“先更新缓存还是先更新数据库”“要不要延迟双删”“Redis 是否使用 Lua”，但这些问题都排在一致性目标之后。如果业务没有先定义“什么必须严格一致、什么可以短暂不一致”，任何架构讨论都会变成组件偏好。

库存系统至少要区分四个目标。第一，库存不能被扣成负数；第二，同一个业务请求不能被重复扣减；第三，订单、库存和库存流水最终必须能够相互解释；第四，用户查询、运营报表和风控校验是否允许看到短暂旧值。

其中，前两个目标通常属于强约束。库存不能为负，重复请求不能重复扣减，这些结果一旦发生，后续很难依靠缓存刷新完全挽回。第三个目标通常通过事务记录、可靠消息和对账完成。第四个目标才是缓存一致性最常讨论的范围。

2. 推荐的职责分工

在大多数订单库存系统中，我更倾向于采用以下职责分工：数据库主库保存最终业务事实，缓存承担快速查询和无效请求拦截，数据库副本用于报表或非关键查询，消息系统负责异步传播状态变化，库存流水负责解释每一次库存变化。

这并不意味着所有扣减都必须直接打数据库。极高并发场景可以先在内存型存储中进行原子预扣，但此时该存储已经不再是普通缓存，而是实时库存状态的一部分。系统必须额外承担持久化、故障恢复、主从切换、落库失败和数据重建责任。

架构评审时，我通常会先问一句：“如果缓存和数据库里的库存数字冲突，最终以谁为准？”如果没有明确答案，就不应该继续讨论缓存更新顺序。因为没有事实源的系统，所谓“缓存一致性”只是让两个不可靠的数字暂时看起来相同。

3. “同步复制”到底能保证什么

同步复制通常意味着主库提交事务时，需要等待一个或多个副本确认接收或写入日志。它可以降低主库故障后数据丢失的概率，也可以提高某些容灾场景下的数据完整性，但它并不自动保证缓存已经删除，更不保证订单服务已经完成状态转换。

即使主库和副本已经同步，仍然可能发生以下情况：应用在数据库提交成功后进程崩溃，缓存删除没有执行；消息已经发送但消费者重复处理；客户端因超时再次提交同一个请求；查询服务从另一个延迟副本读到了旧版本。复制一致不等于业务链路一致。

二、真实场景：最后一件库存为什么会被卖两次

1. 一条看似合理的扣减链路

假设商品 SKU-A 初始可售库存为 1，缓存中保存 stock=1，数据库主库和只读副本都保存 stock=1。用户甲和用户乙几乎同时发起购买请求。系统先访问缓存，看到库存大于零后继续执行数据库扣减。

如果数据库使用带条件的原子更新，最终只有一笔请求能够成功，另一笔请求因为影响行数为 0 而失败。这是相对稳妥的结果。但如果应用采用“先查询库存，再在应用层判断，最后执行普通更新”的方式，两个请求都可能在判断阶段认为库存充足。

SELECT available_stock
FROM inventory

WHERE sku_id = 'SKU-A';

-- 应用层判断 available_stock > 0 后再执行

UPDATE inventory

SET available_stock = available_stock - 1

WHERE sku_id = 'SKU-A';

这段逻辑的危险之处在于，查询和更新之间没有形成不可分割的业务判断。两个请求都读到 1，随后各自执行减一，数据库最终可能得到 -1，也可能因为其他逻辑出现订单数大于库存数。问题不在 SQL 写法是否简短，而在“库存是否足够”的判断没有放进原子更新条件中。

2. 复制延迟如何制造旧值回填

更隐蔽的事故发生在数据库扣减已经正确完成之后。请求甲在主库成功扣减，库存从 1 变为 0；此时副本复制延迟 80 毫秒。请求乙的查询被路由到副本，仍然读到库存 1，查询层又把这个旧值写回缓存，缓存重新变成 stock=1。

如果扣减接口仍然相信缓存中的数字，后续请求就会继续通过前置校验。即使最终数据库条件更新能够阻止超卖，也会产生大量无效请求、错误的库存展示和不必要的重试压力；如果扣减接口直接以缓存扣减结果作为成功依据，则可能进一步造成订单与库存不一致。

3. 一个请求超时，不代表扣减失败

库存系统中最容易被忽略的状态是“结果未知”。客户端在等待 2 秒后超时，并不能说明数据库事务没有提交。可能的实际过程是：数据库已经提交，应用在返回响应前发生网络中断；客户端没有收到成功结果，于是携带同一个业务请求再次重试。

如果系统没有幂等控制，第二次请求可能再次扣减。如果系统简单地把超时请求标记为失败，后续对账又会发现库存已经少了一件。正确做法不是看到超时就重新执行扣减，而是先根据 request_id 查询原始处理记录，再决定返回成功、失败还是进入人工或自动补偿状态。

4. 订单与库存不在一个事务中的典型矛盾

如果库存服务先扣减成功，订单服务随后创建订单失败，库存已经减少但没有订单占用。反过来，如果订单先创建成功，库存扣减失败，就会出现订单存在但无法履约。两者不一定要强行放进一个跨服务分布式事务，但必须设计状态机和补偿路径。

我在方案评审中更关注“失败后系统能否自我解释”。一笔库存扣减至少应该能够回答：谁发起的、扣了哪个 SKU、扣了多少、关联哪张订单、扣减前后是多少、当前状态是什么、失败后是否已经释放。只有数字，没有流水，就无法稳定完成故障定位。

三、常见误区：看起来能同步，实际上没有形成闭环

1. 误区一：缓存和数据库同时更新，就叫一致性

同时更新两个系统并不能提高一致性，反而增加了部分成功的可能。缓存写成功、数据库写失败，会出现缓存领先；数据库写成功、缓存写失败，会出现缓存落后；两个写操作都成功但顺序相反，会出现旧请求覆盖新请求。

一致性设计的关键不是让两个组件“同时变化”，而是让系统在任意一个步骤失败后仍然有明确的恢复方式。通常更容易控制的是：数据库先完成事实提交，提交成功后删除缓存，删除失败则通过重试队列和对账机制恢复。

2. 误区二：延迟双删可以保证强一致

延迟双删的基本思路是先删除缓存，再更新数据库，等待一段时间后再次删除缓存，试图清除并发读请求回填的旧值。它在降低缓存旧值概率方面有价值，但不能把它描述为严格强一致方案。

如果数据库更新耗时超过预设延迟，第二次删除可能仍然早于事务提交；如果删除请求丢失，缓存仍然会保留旧数据；如果多节点缓存之间存在复制或网络延迟，也可能有节点继续提供旧值。延迟时间必须通过实际写入耗时、缓存访问耗时和复制延迟分布来校准，而不是固定写成 500 毫秒或 1 秒。

3. 误区三：加分布式锁就不会超卖

分布式锁可以降低同一 SKU 的并发写冲突，但它并不自动解决锁过期、客户端宕机、锁误释放、数据库提交结果未知和消息重复消费。更重要的是，如果所有扣减都要竞争同一把锁，吞吐量会被最热 SKU 的锁串行化。

对于数据库已经能够通过条件更新完成原子扣减的场景，我通常不会把分布式锁作为第一选择。锁可以用于保护复杂的跨表业务流程，但简单库存扣减更应该优先依靠数据库条件更新、唯一约束和事务。

4. 误区四：同步复制等于读写强一致

同步复制解决的是主库提交时副本是否已经接收或持久化的问题，但应用读请求可能仍然访问了错误的副本，也可能访问了另一套缓存。若读写路由没有绑定，写入主库后的下一次读取仍可能落到延迟节点。

对库存扣减后的关键查询，应采用主库读取、会话级读主、基于日志位点等待副本追平，或携带数据版本进行校验。对商品详情、排行榜和非关键运营报表，则可以接受副本延迟。

5. 误区五：Redis 原子扣减成功就是下单成功

Redis 的原子操作或脚本可以保证多个请求对同一个计数器的并发修改不会互相覆盖，但“缓存中的数字减一”仍然只是一个状态变更。它不代表订单已经创建，不代表库存流水已落库，也不代表服务重启后这个数字一定能被准确恢复。

如果采用内存型存储作为前置库存，必须给每次预扣分配唯一预扣单号，并记录预扣状态、落库状态和释放状态。落库失败不能无限重试扣减，而应重试“确认这笔预扣是否已经落库”，避免把同一个业务动作执行两遍。

6. 误区六：只监控缓存命中率，不监控一致性结果

缓存命中率很高，只能说明请求被缓存处理得很好，不能说明库存正确。库存系统更需要监控条件更新影响行数、幂等冲突、缓存删除失败、复制延迟、消息积压、订单与库存差异以及补偿成功率。

如果只看 QPS 和响应时间，系统可能在“错误地快速返回”。一致性监控必须覆盖结果，而不只是性能。

四、专业判断逻辑：先定边界，再选实现

1. 第一步：把“库存”拆成可售、锁定和已占用

只有一个 available_stock 字段，往往无法解释订单流程。更清晰的模型通常至少区分可售库存、锁定库存和已占用库存。用户下单时可能先锁定，支付成功后转为占用，取消或超时则释放回可售库存。

例如，库存总量为 100，已占用 60，锁定 15，则可售库存可以定义为 25。不同业务对“扣减”的定义不一样：秒杀系统可能在下单瞬间直接扣减可售库存，普通电商可能在订单创建时锁定库存，仓储系统则可能要等拣货或出库节点才改变实物占用。

available_stock = total_stock – locked_stock – occupied_stock
— 创建锁定记录时，必须保证可售库存足够

UPDATE inventory
SET locked_stock = locked_stock + :quantity,
available_stock = available_stock - :quantity,
version = version + 1
WHERE sku_id = :sku_id
AND available_stock >= :quantity;

把库存状态拆开后，补偿逻辑也会更准确。订单取消不是“再执行一次加库存”这么简单，而是要确认这笔订单当前是否处于锁定状态；如果已经转为已占用，就不能按锁定库存释放，否则会形成重复回补。

2. 第二步：明确哪些读请求必须读主库

不是所有读都需要主库。商品列表、营销页面和普通库存展示可以接受短暂延迟，但扣减结果确认、写后立即查询订单、库存释放前的状态判断，通常不应依赖普通只读副本。

我建议将读请求分为三类。第一类是强一致读，例如扣减结果、订单履约判断和释放前校验；第二类是会话一致读，例如用户刚提交订单后查看自己的订单；第三类是最终一致读，例如运营报表和商品列表。三类请求应该使用不同的路由策略，而不是全站统一读缓存或统一读副本。

3. 第三步：判断是否需要缓存参与扣减

缓存参与扣减的价值主要是降低数据库在热点 SKU 上的压力，而不是提升一致性。可以先用缓存判断“明显无库存”的请求，减少无效数据库访问；但最终能否扣减成功，仍由数据库条件更新或经过完整设计的实时库存服务确认。

如果数据库单行条件更新已经能够承受目标流量，优先选择“数据库扣减成功后删除缓存”通常更容易维护。只有当热点商品的并发量明显超过数据库写入能力，或者业务已经接受预扣与最终落库之间存在短暂状态差异时，才考虑 Redis 原子预扣或库存分片。

4. 第四步：把失败分成“明确失败”和“结果未知”

数据库返回条件不满足，属于明确失败，可以直接返回库存不足。数据库连接断开但事务结果未知，则不能直接判断失败。缓存删除超时也不代表数据库扣减失败，消息消费超时也不代表消息没有处理。

不同状态必须对应不同动作。明确失败可以结束请求；明确成功可以返回成功；结果未知必须先查询幂等记录、订单记录或库存流水，再决定是否重试。把结果未知当成失败，是库存系统重复扣减的常见根源。

5. 第五步：建立版本号，而不是只比较库存数字

库存数字相同，并不代表状态相同。库存从 10 变成 9，再释放回 10，数字最后可能仍是 10，但它已经经历了不同业务动作。如果只把 stock=10 写入缓存，很难判断这个值是初始库存、释放后的库存还是旧数据回填。

建议为库存记录增加单调递增版本号，缓存对象、消息事件和库存流水都携带版本。更新缓存时，如果事件版本小于当前缓存版本，就拒绝覆盖。这样可以防止消息乱序或旧读结果覆盖新状态。

{
"sku_id": "SKU-A",

"available_stock": 9,

"locked_stock": 2,

"occupied_stock": 89,

"version": 2048,

"updated_at": "2026-09-16T10:20:31Z"

}

五、标准实现：数据库扣减、缓存失效与幂等闭环

1. 使用条件更新保证库存不变负

最基础、也最容易被忽略的保护是条件更新。库存扣减必须在同一条更新语句中完成“减少数量”和“库存足够”的判断，不能把判断放到应用层再执行一条无条件更新。

UPDATE inventory
SET available_stock = available_stock - :quantity,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND status = 'ACTIVE'

AND available_stock >= :quantity;

执行后必须检查影响行数。影响行数为 1，表示条件满足且扣减成功；影响行数为 0，可能是库存不足、SKU 不存在或状态不可售。生产代码不应把所有 0 行都直接转换成“库存不足”，否则会掩盖商品状态或数据问题。

2. 用幂等记录拦截重复请求

幂等记录可以独立建表，也可以和订单业务表共享唯一约束。关键字段通常包括 request_id、order_id、sku_id、quantity、状态、版本和处理时间。request_id 必须由业务方生成，并且生命周期要覆盖客户端、网关和消息系统的最长重试窗口。

CREATE TABLE inventory_deduct_record (
id BIGINT PRIMARY KEY,
request_id VARCHAR(64) NOT NULL,
order_id VARCHAR(64) NOT NULL,
sku_id VARCHAR(64) NOT NULL,
quantity INT NOT NULL,
status VARCHAR(20) NOT NULL,
before_stock INT,
after_stock INT,
version BIGINT,
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_request_id (request_id)
);

处理请求时，先查找 request_id 是否存在。已成功的请求直接返回原结果；已明确失败的请求直接返回失败；处于处理中且超时的请求，不应盲目再次扣减，而要进入状态确认流程。

3. 事务内写事实，事务外处理缓存

在数据库作为最终事实源的方案中，推荐把库存变化和库存流水放在同一事务内。事务提交成功后，再删除缓存或投递可靠的缓存失效事件。不要在数据库事务尚未提交时就把新库存写入缓存，否则事务回滚后缓存会提前暴露不存在的结果。

BEGIN;
— 1. 创建幂等记录，request_id 必须唯一

INSERT INTO inventory_deduct_record
(request_id, order_id, sku_id, quantity, status, created_at, updated_at)
VALUES
(:request_id, :order_id, :sku_id, :quantity, 'PROCESSING', NOW(), NOW());

— 2. 条件扣减

UPDATE inventory
SET available_stock = available_stock - :quantity,
version = version + 1,
updated_at = NOW()
WHERE sku_id = :sku_id
AND available_stock >= :quantity;

— 3. 根据影响行数写入成功或失败状态

— 4. 写库存流水

— 5. 与订单状态建立关联

COMMIT;

— 提交成功后执行

DELETE FROM cache WHERE cache_key = :stock_cache_key;

这里的 DELETE 不是数据库 SQL，而是示意性的缓存删除动作。真正实现时，缓存删除失败必须进入重试队列，不能因为删除失败就回滚已经提交的库存事务。否则每次缓存故障都会反向影响数据库核心写入。

4. 为什么通常选择删除缓存，而不是直接更新缓存

删除缓存的优点是逻辑简单：数据库提交成功后让缓存失效，下一次查询从可靠数据源重新加载。直接更新缓存则需要保证写入值与数据库提交结果一致，还要处理多个并发请求的到达顺序。

例如请求甲先读取库存 20，执行扣减较慢；请求乙读取库存 20，先扣减成功并将缓存写成 19；请求甲随后扣减成功并把缓存写成 19。这个例子数字恰好相同，但在不同数量、释放库存和多操作混合时，旧请求就可能覆盖新状态。

删除缓存并不等于没有竞争窗口，但它把缓存从“主动维护的第二事实源”降级为“可重建的读取副本”，恢复责任明显更清晰。

5. 缓存删除失败的处理方式

缓存删除失败时，不建议在主请求线程里进行多次长时间重试。主请求应该尽快返回数据库已经确认的结果，同时将 SKU、版本、失败原因和重试次数写入可靠队列。

后台重试需要具备退避策略，例如第一次延迟 100 毫秒，随后逐步延长到秒级或分钟级，并设置最大重试次数。超过最大次数后进入死信或人工处理队列。每次修复都应记录审计日志，避免缓存修复过程本身成为新的不可追溯操作。

六、复制延迟：不要让副本旧值重新污染缓存

1. 先测量复制延迟分布，而不是凭经验设置阈值

复制延迟不是一个固定常数。低峰时可能只有几毫秒，高峰、批量写入、网络抖动或副本磁盘压力下，延迟可能迅速扩大。只监控平均延迟也不够，因为库存事故往往发生在 P99 或更高分位。

建议至少记录平均值、P95、P99、最大值和连续超过阈值的持续时间。比如团队观察到平均延迟 12 毫秒，并不能证明 99.9% 的请求都能在 20 毫秒内读到新数据。路由策略应该依据分位数和业务容忍度，而不是平均数。

2. 关键读请求采用读主或版本等待

最简单的策略是扣减成功后的关键查询直接读主库。它的代价是增加主库读压力，但实现和验证都比较容易。对于访问量很大的系统，可以让请求携带最近一次写入的版本号，只有当副本达到该版本后才允许副本返回，否则暂时读主库。

不同数据库对复制位点、日志序号和会话一致性的实现方式不同。MySQL 环境可能结合 GTID 或复制位点，PostgreSQL 环境可能使用 WAL LSN 等机制。这里不能把某一种数据库的接口名称直接套用到所有产品，必须以实际数据库版本和驱动能力为准。

3. 禁止用副本旧值回填关键库存缓存

查询服务从副本获取商品详情时，可以将结果用于普通页面展示，但不应无条件把它写入扣减链路使用的库存缓存。至少需要满足以下条件之一：副本已确认追平、结果版本不低于缓存版本、请求不是写后读场景，或者该缓存只用于非关键展示。

if (replicaVersion // 拒绝用副本旧值覆盖缓存

return readFromPrimary(skuId);

}

if (result.version >= cacheVersion) {

cache.set(stockKey, result, result.version);

}

版本比较必须在缓存写入端再次执行，而不能只依赖调用方判断。因为从读取副本到写缓存之间仍然存在网络延迟，另一个更新可能在这段时间内已经产生更高版本。

4. 同步复制的成本不能被忽略

同步复制会把部分副本网络、磁盘和故障状态传导到主库提交路径。副本不可用时，系统是继续写入、切换为异步、还是暂停关键写入，必须提前定义。否则高峰期间一次副本故障可能直接放大成全站库存写入不可用。

因此，是否使用同步复制，不应只回答“数据更安全”，还要回答：同步确认级别是什么、允许多少副本确认、故障时是否降级、降级期间是否允许扣减、恢复后如何校验数据。复制策略与业务一致性策略必须一起评审。

七、并发、幂等和补偿：真正决定系统能否恢复

1. 同一 SKU 的并发扣减

对于普通库存表，条件更新通常已经能够解决“两个请求同时扣最后一件”的核心问题。数据库会对目标行进行并发控制，最终只有满足条件的一方成功。应用只需根据影响行数决定后续流程，并记录清晰的失败原因。

如果一个请求要同时扣减多个 SKU，情况会复杂很多。应考虑固定加锁顺序，避免事务之间互相等待；或者先建立扣减意图，再按统一顺序更新库存。多 SKU 扣减是否必须全成功，也要提前定义：是全部回滚，还是允许部分成功后补偿。

2. 客户端和网关重试

客户端重复点击、网关超时重试、消息重新投递和任务调度重复执行，都会产生相同业务动作的多个入口。接口参数中的商品和数量并不能作为幂等条件，因为同一个用户可能合法购买同一商品多次。

可靠的幂等键应该代表一次业务意图，例如 order_id 或 request_id。对于“提交结果未知”的请求，客户端应调用查询接口确认原处理结果，而不是生成新的幂等键重新提交。

3. 消息重复消费与乱序

库存事件通常包含扣减、释放、占用和修正等动作。消息至少一次投递意味着消费者可能重复收到同一事件，因此消费端必须以事件 ID 或业务流水号去重。

乱序问题更容易被忽略。先发生的扣减事件可能晚于后发生的释放事件到达消费者。如果只执行“收到什么就写什么”，旧事件会覆盖新状态。消息中应携带业务版本或单调序列号，消费者只接受不小于当前状态版本的事件。

if (event.version // 已处理或过期事件，记录后忽略

return;

}

applyEvent(event);

updateCurrentVersion(event.version);

4. 订单取消后的库存释放

释放库存不能简单理解为执行一次加法。系统首先要确认订单是否确实占用过库存，并且释放动作是否已经执行。释放请求也必须幂等，否则订单取消重试可能把库存加回两次。

更稳妥的实现是为每次锁定建立库存占用流水，释放时通过唯一的 release_request_id 进行状态转换。库存数量由流水和状态共同解释，不能只根据订单状态推测。

5. 对账不是失败后的临时补丁

对账应当从系统设计之初就存在，而不是出现事故后临时写脚本。可以按 SKU、订单、库存流水三个维度进行核对：数据库当前库存是否等于总量减去各类占用；缓存版本是否低于数据库版本；订单状态与库存锁定状态是否匹配。

对账发现差异后，不应直接批量覆盖库存。先区分缓存偏差、流水缺失、订单状态错误和实际库存异常，再采用不同修复策略。缓存偏差可以删除重建，流水缺失需要补写审计记录，订单状态错误则要经过业务确认。

八、案例推演：中等并发与极高并发不应使用同一套方案

1. 案例一：普通电商订单库存

假设某商品日常订单流量平稳，单个 SKU 每秒扣减请求峰值约 300 次，数据库主库可以稳定承载条件更新，业务更在意订单与库存可追溯，而不是追求极限吞吐。

这类场景没有必要一开始就把 Redis 作为唯一扣减事实源。推荐使用数据库条件更新、幂等记录、库存流水和提交后删除缓存。缓存可以保存商品库存展示，但订单扣减结果以主库事务为准。

该方案的核心优点是故障面相对小。数据库事务成功但缓存删除失败，可以通过重试和对账恢复；客户端超时，可以通过 request_id 查询；副本延迟，可以让关键查询读主。系统的性能上限虽然不如纯内存扣减，但运维和审计成本低很多。

2. 案例二：秒杀热点 SKU

假设某个活动在 10 秒内涌入 50 万次请求，其中 99% 的请求最终都会因为库存不足而失败。如果所有请求都打到数据库，即使最终只有少量成功订单，数据库也要承担大量无效竞争。

这时可以使用缓存作为前置拦截层：先通过原子操作判断剩余预扣额度，明显超出库存的请求在缓存层快速失败，只有拿到预扣凭证的请求才进入订单和数据库落库流程。

但预扣凭证必须具备生命周期和状态管理。请求进入“已预扣”状态后，如果数据库落库失败，需要重试落库或释放预扣；如果订单支付超时，需要根据订单状态释放；如果缓存节点故障，需要依据预扣流水重建，而不是简单把数据库当前库存重新写回缓存。

3. 案例三：多仓、多区域库存

多仓库存不能把所有仓库简单相加后放入一个全局缓存。订单可能绑定配送区域、仓库优先级和运输时效，同一 SKU 在不同仓库的可售条件不同。

更合理的模型是按仓库或库存分片建立独立扣减单元，再由分配服务决定订单使用哪一个库存单元。跨区域扣减要明确是否允许异地抢占、是否允许最终调拨以及冲突发生时的补偿方式。

4. 案例数据应该怎样使用

上面的请求量和延迟是架构推演数据，不应被包装成某家企业的真实生产数据。正式容量评估时，应使用压测结果、历史流量峰值、数据库锁等待、复制延迟分位数和缓存命中率进行替换。

我建议至少做三组压测。第一组测试单 SKU 最后一件库存的并发扣减，观察成功数、失败数和负库存数；第二组测试数据库提交成功但缓存删除失败，确认重试和对账能否恢复；第三组测试客户端超时后重复提交，确认同一个 request_id 是否只产生一条有效扣减流水。

九、不同情况下的行动建议

1. 如果当前系统已经出现超卖

不要先加缓存，也不要先加分布式锁。先冻结问题范围，保留订单、库存流水、数据库 binlog 或审计日志，确认超卖是由重复扣减、库存释放重复、缓存误判还是人工修正造成。

• 立即将最终扣减切换为数据库条件更新。
• 为请求或订单增加唯一幂等约束。
• 关键库存查询暂时切换到主库。
• 停止使用副本旧值回填扣减缓存。
• 对异常 SKU 建立库存、订单和流水三方对账。
• 修复前保留原始数据，不要直接覆盖数据库库存。

如果已经出现真实超卖，应把“业务补救”与“技术修复”分开。业务需要确定补发、退款或改配方案；技术侧需要保证同类问题不会继续扩大。仅仅把库存数字改回去，往往会破坏后续订单和财务核对。

2. 如果数据库压力正在升高但还没有超卖

先确认压力来自成功扣减，还是来自大量库存不足的无效请求。如果大部分请求最终都会失败，缓存前置拦截、限流和请求合并可能比直接扩容数据库更有效。

• 为热点 SKU 设置短期库存状态缓存。
• 对已确认售罄的商品设置短 TTL 结果，减少无效访问。
• 将普通展示查询与扣减接口分离。
• 检查库存更新 SQL 是否命中正确索引。
• 监控锁等待、事务耗时和连接池饱和度。
• 不要因为数据库压力升高就直接让缓存承担最终扣减。

3. 如果采用 Redis 原子预扣

必须先设计预扣凭证，再写扣减脚本。脚本只负责同一库存单元的原子判断和减少，不负责跨系统订单事务。每次预扣都要有唯一流水号，预扣成功后进入待落库状态。

• 预扣成功后生成唯一 token 或业务流水号。
• 落库服务按流水号幂等写入数据库。
• 落库结果未知时先查询，不直接再次扣减。
• 订单取消或超时未支付时按状态释放。
• 缓存主节点切换后，以持久化流水和数据库事实重建。
• 定期对比预扣总量、数据库扣减总量和订单占用总量。

如果团队没有能力建设这套闭环，不建议仅因为“Redis 更快”就采用 Redis 作为唯一扣减源。高吞吐方案的主要成本不在脚本，而在异常恢复和数据重建。

4. 如果复制延迟经常超过业务容忍度

先把复制延迟作为业务信号，而不是单纯的基础设施指标。当延迟超过阈值时，系统可以临时关闭关键缓存回填、将写后读请求路由到主库，或者降低非关键报表查询优先级。

• 设置 P95、P99 和最大延迟告警。
• 关键读请求携带最近写入版本。
• 副本未追平时拒绝回填关键库存缓存。
• 评估副本磁盘、网络、批量任务和复制线程状态。
• 明确副本不可用时是降级读主还是暂停部分业务。
• 恢复后执行库存版本和缓存版本校验。

5. 如果业务只允许短暂最终一致

最终一致不是降低所有设计要求，而是把强一致边界缩小到真正重要的地方。例如，库存扣减和订单状态转换要求严格控制，商品页面的库存标签允许延迟 1 秒，运营报表允许延迟几分钟。

这种设计可以降低主库压力，但必须明确用户可见行为。页面显示有货而下单失败，可能是可接受的；扣减成功但订单页面长期显示失败，则不可接受。最终一致的边界要写进接口协议、产品提示和故障预案。

十、可验证的监控、测试和对账体系

1. 监控四类关键指标

第一类是业务结果指标，包括扣减成功率、库存不足率、订单创建成功率和库存释放成功率。第二类是数据一致性指标，包括数据库与缓存版本差异、订单与库存流水差异和对账异常 SKU 数量。

第三类是基础设施指标，包括主从复制延迟、数据库锁等待、事务提交耗时、缓存删除失败率和消息积压量。第四类是恢复指标，包括补偿成功率、死信数量、人工处理耗时和异常状态超过阈值的订单数量。

2. 故障注入必须覆盖“提交成功但响应失败”

很多测试只模拟数据库直接报错，却没有模拟最危险的半成功场景。库存系统至少要在数据库提交后、应用返回前主动中断进程，验证客户端重试是否会重复扣减。

还要模拟缓存删除超时、消息发送成功但响应丢失、消费者处理成功后确认消息失败、主库成功而副本延迟、缓存节点切换和订单创建失败。每种场景都要明确最终状态，而不是只观察接口是否返回 500。

1. 准备一个可追踪的 request_id 和 order_id。
2. 记录扣减前库存、扣减后库存和事务版本。
3. 在指定步骤注入网络断开或进程终止。
4. 重复发送相同 request_id，观察是否只产生一条有效流水。
5. 检查数据库、缓存、副本、订单和消息状态。
6. 等待重试与对账任务执行，确认系统最终收敛。

3. 以不变量验证，而不是只看最终数字

库存系统应建立不变量。例如，可售库存不能小于零；同一个 request_id 的成功扣减记录最多一条；释放数量不能超过对应锁定数量；数据库库存版本不能低于已提交流水版本；订单已支付后不能存在未解释的锁定库存。

这些不变量比“缓存最终是不是等于数据库”更有价值，因为它们直接描述业务不能被破坏的边界。即使允许页面短暂读旧值，也不能允许同一请求成功扣减两次。

4. 对账任务的执行顺序

对账不应该直接把缓存覆盖成数据库值。更安全的顺序是先读取数据库库存及版本，再检查库存流水和订单状态，最后判断缓存是否只是旧值。如果只是缓存版本落后，删除缓存即可；如果数据库与流水不符，需要锁定 SKU 并进入业务修复。

高风险库存修复应当保留原值、目标值、修复原因、操作人、审批信息和关联订单。自动化可以提高处理速度，但不能让系统在没有审计记录的情况下随意改动库存。

十一、不同方案的取舍：不要追求不存在的绝对一致

1. 数据库条件扣减加删除缓存

这是我对多数中等并发订单系统的默认建议。它把最终事实集中在数据库，通过条件更新保证扣减原子性，事务内写流水，提交后让缓存失效。

• 优点：逻辑清晰，数据可追溯，补偿边界明确。
• 缺点：热点 SKU 可能形成数据库行锁竞争，峰值吞吐有限。
• 适用：普通电商、仓储订单、库存变化需要审计的系统。
• 前提：数据库主库具备足够写入能力，SQL 和索引经过压测。

2. Redis 原子预扣加异步落库

这种方案适合大量请求集中争抢少量库存的场景。它可以在内存层快速淘汰无效流量，避免所有请求进入数据库，但代价是系统增加了一个需要被持久化和恢复的实时状态层。

• 优点：热点扣减吞吐高，能够削减数据库无效请求。
• 缺点：预扣、落库、释放、重建和对账复杂。
• 适用：短时秒杀、票务抢购、极热点资源分配。
• 前提：团队具备可靠消息、幂等消费和故障恢复能力。

3. 分布式锁包住全链路

分布式锁的优点是容易向业务方解释：同一资源同一时间只允许一个请求处理。但它会把数据库、订单、缓存和远程调用都放在锁的持有时间内，远程服务变慢时锁竞争会迅速扩大。

• 优点：对复杂业务流程有一定保护作用。
• 缺点：吞吐下降，锁续期、锁释放和节点故障需要额外治理。
• 适用：并发量有限、跨多个步骤且暂时无法重构的旧系统。
• 前提：必须有锁超时、业务幂等和异常解锁机制。

4. 消息驱动的最终一致方案

数据库事务完成后发送库存变更事件，由消费者刷新缓存或同步其他服务，适合需要解耦和削峰的架构。它的关键不是“使用消息”本身，而是消息是否可靠、消费者是否幂等、事件是否带版本、积压时业务是否能接受延迟。

• 优点：组件解耦，适合异步传播和多下游订阅。
• 缺点：消息延迟、重复、乱序和死信都会增加排障成本。
• 适用：库存变更需要同步搜索、营销、报表和风控等多个下游的场景。
• 前提：必须有本地事务与消息可靠投递的设计。

十二、架构师标准化落地清单

1. 数据模型检查

• 是否区分总库存、可售库存、锁定库存和已占用库存？
• 是否为库存变更建立独立流水？
• 是否有版本号或单调序列号？
• 是否能通过流水解释任意一次库存变化？
• 是否为释放、修正和人工调整建立不同操作类型？

2. 扣减接口检查

• 是否使用数据库条件更新防止库存变负？
• 是否检查数据库影响行数？
• 是否以 request_id 或 order_id 实现幂等？
• 超时后是否先查询原请求状态？
• 多 SKU 扣减是否采用固定顺序或统一事务策略？
• 订单失败后是否有明确的库存释放流程？

3. 缓存和复制检查

• 数据库提交前是否避免写入新缓存？
• 缓存删除失败是否进入可靠重试？
• 是否阻止副本旧值回填关键库存缓存？
• 是否监控复制延迟的 P95、P99 和最大值？
• 写后读请求是否能够绑定主库或等待版本追平？
• 缓存对象是否携带版本而不只是库存数字？

4. 故障恢复检查

• 是否模拟数据库提交成功但响应丢失？
• 是否模拟缓存删除失败？
• 是否模拟消息重复、乱序和积压？
• 是否模拟主库切换和副本延迟？
• 是否有库存、订单、流水三方对账？
• 自动修复是否保留审计信息？

5. 发布前的最小验收标准

在没有完成以下验证前，不建议把方案描述为“保证扣减一致性”。至少要证明并发争抢最后一件库存时不会产生两条成功扣减；相同 request_id 重试不会增加扣减次数；数据库提交成功后缓存删除失败能够自动恢复；订单取消不会重复释放；副本延迟时关键查询不会回填旧值。

如果暂时无法做到绝对强一致，应在接口和产品层明确可接受的延迟窗口，并记录超过窗口后的处理方式。架构方案最忌讳只写“最终一致”，却不说明多久最终、由谁校验、发现偏差后怎么修复。

十三、结语：一致性不是让所有组件同时变化

1. 最值得记住的判断

库存扣减一致性的核心，不是把缓存、数据库和副本里的数字尽快改成一样，而是让每一次业务动作都有唯一身份、原子结果、可追溯流水和可执行补偿。

缓存可以旧，但必须知道它可能旧多久；副本可以延迟，但关键请求不能盲目依赖它；消息可以重复，但消费者必须幂等；请求可以超时，但系统必须能查询原始处理结果；数据库可以故障，但恢复后必须能够重建和对账。

因此，“缓存同步复制保证扣减一致性”更准确的工程表达应该是：以数据库或专用库存服务作为明确事实源，用条件扣减保证原子性，用缓存和副本承载可控的读取压力，用幂等、版本、消息重试和对账把异常状态拉回闭环。

2. 下一步怎么做

1. 先画出一次扣减请求从入口到订单完成的完整时序图。
2. 标注每一步的数据源、事务边界、版本号和失败结果。
3. 明确哪些请求必须读主库，哪些请求允许读缓存或副本。
4. 为 request_id、库存流水和释放动作补上唯一约束。
5. 测量复制延迟长尾，而不是只查看平均值。
6. 实施数据库提交成功、响应失败、缓存删除失败和消息重复消费的故障注入。
7. 建立库存、订单、流水和缓存版本的定时对账。

如果系统属于普通订单业务，优先从“数据库条件扣减加提交后删除缓存”开始；如果系统属于极热点秒杀，再逐步引入原子预扣和异步落库。不要为了追求架构复杂度而提前承担恢复成本，也不要把一个性能组件误当成一致性方案。真正成熟的设计，不是正常情况下看起来顺滑，而是在超时、重试、延迟、宕机和部分成功之后，仍然能够给出确定答案。

UPDATE inventory SET available_stock = available_stock - :quantity version = version + 1 WHERE sku_id = :sku_id AND available_stock >= :quantity;

CREATE UNIQUE INDEX uk_inventory_request ON inventory_deduct_record(request_id);

免费注册

咨询方案

扫码咨询方案