数据库存：技术负责人效率攻略：用缓存同步加快保证扣减一致性

库存系统最容易被误判的地方，是把“读取库存很快”当成“扣减库存很安全”。我见过不少架构评审，一开始的目标是把库存查询从数据库迁移到缓存，后来却发现真正难处理的不是查询延迟，而是缓存预扣成功、数据库落库失败、订单重复提交、支付超时释放等一连串状态问题。缓存解决的是并发访问效率，扣减一致性解决的是业务事实是否成立；两者必须拆开设计，再通过幂等、消息、补偿和对账闭环。

本文讨论的“数据库存”，统一按“数据库库存”理解，重点不是教你简单地把库存字段放进缓存，而是从技术负责人的决策视角，说明什么时候应该让数据库承担最终扣减，什么时候可以让缓存承担高并发预扣，以及两种方案各自需要付出什么代价。

一、先讲核心结论：缓存提速，数据库定责，补偿兜底

1. 不要先问“用什么缓存”，先问“谁是库存事实来源”

库存架构的第一个问题，不是 Redis、数据库还是消息队列，而是：当缓存、订单和数据库的数字不一致时，系统最终相信谁。

如果一个商品在数据库中显示可售库存为 0，但缓存中还显示 1，客服、财务和库存盘点最终应该依据哪一个数字处理？如果订单已经创建，缓存却因为服务重启丢失了预扣记录，系统又应该如何恢复？这些问题都指向同一个结论：库存必须有明确且唯一的权威数据源，其他副本只能承担加速、预占或传递职责。

在大多数需要审计、结算和售后追责的业务中，我建议把数据库中的库存流水或库存状态作为最终事实来源。缓存可以承担库存预扣，也可以承担高频查询，但不应让一个无法被完整追溯的缓存数值成为唯一账本。

2. 查询链路与扣减链路必须分开

查询库存通常是读多写少的场景。用户打开商品详情页、活动页或购物车时，系统希望快速回答“现在大概还有多少”。这一类请求可以优先命中缓存，允许极短时间内存在展示延迟。

扣减库存则是写操作。它要回答的是“这一次请求是否真正占用了库存”。这个结果往往会影响订单、支付、发货和财务核算，因此不能仅凭一次缓存读取决定。

这张表背后的判断很重要：同一个“库存数字”，在不同阶段承担的职责并不相同。如果团队把展示库存、预占库存和已确认库存都压缩成一个字段，后续必然会在取消、支付失败和缓存恢复时遇到解释不清的问题。

3. 一致性不是一个开关，而是一条可恢复的链路

很多方案文档会写“通过缓存同步保证一致性”，但“同步”这个词很容易掩盖失败窗口。数据库提交成功后，缓存删除可能失败；缓存预扣成功后，消息可能没有送达；消息消费成功后，服务响应可能超时，客户端又会重试。

因此，我更愿意把一致性拆成四个可检查的问题：

• 正确写入：一次合法请求只能扣减一次。
• 可靠传递：库存变更事件不能因为单次网络故障永久丢失。
• 异常收敛：失败请求要能重试、回补或进入人工处理。
• 最终可证：系统要能够通过流水和对账证明库存状态。

只做到第一步，系统可能短期看起来没有超卖；只做到第二步，系统可能消息很多但状态混乱；只做到第三步，系统能够修错但无法知道错了多少。真正可运营的库存系统，四步缺一不可。

二、真实场景：为什么库存扣减问题总在峰值时暴露

1. “只剩一件”的并发场景，比普通商品更能暴露设计缺陷

假设某个限量商品的数据库库存为 1，缓存也为 1。两个请求几乎同时到达。

1. 请求 A 从缓存读取到库存为 1。
2. 请求 B 也从缓存读取到库存为 1。
3. A 创建订单并准备扣减数据库。
4. B 因为没有重新校验，继续创建订单。
5. 两个订单都认为自己拿到了最后一件商品。

如果数据库更新语句没有带上“库存大于等于购买数量”的条件，就可能发生超卖。如果数据库带了条件，通常只有一个请求能成功，但另一个请求可能已经产生了订单记录，系统就会出现“订单存在、库存未扣减”的悬挂状态。

这说明“先查库存，再扣库存”不是一个原子动作。查询只是在某个时间点观察状态，不能为后续写入提供永久承诺。

2. 订单、库存和支付本来就不是同一个事务

库存扣减还经常被错误地绑定到支付结果。用户下单时需要锁定库存，但支付可能在几分钟后完成；如果支付失败，库存要释放；如果用户重复支付或订单回调重复到达，库存又不能被二次确认。

在我参与过的库存方案评审中，最常见的状态混乱不是单纯超卖，而是“库存冻结”长期没有释放。系统为了避免超卖，采用了预占机制，却没有建立超时释放任务。最终可售库存越来越少，数据库显示还有货，用户却无法继续购买。

这类问题的根源不是缓存命中率，而是库存状态没有被建模。至少应区分：

• 可售库存：可以被新的请求预占。
• 预占库存：已经分配给某个业务请求，但订单尚未最终确认。
• 已确认库存：订单完成关键确认后正式消耗。
• 已释放库存：预占失败、订单取消或支付超时后重新回到可售池。

3. 高并发不只意味着请求多，还意味着重试多

很多团队压测时只模拟一次请求，却没有模拟真实网络环境中的超时和重试。实际流量里，网关、客户端、服务间调用和消息消费者都可能重试。

例如，服务已经完成缓存扣减和数据库提交，但响应在返回途中超时。客户端无法判断业务是否成功，于是再次提交。若系统没有幂等键，第二次请求就可能再次扣减库存。

所以库存系统的并发模型至少要包含三类重复：

4. 峰值流量会放大数据库热点，而不是平均流量

一条库存记录被大量请求同时更新时，数据库面对的不是普通写入，而是热点行竞争。即使单条 SQL 很快，多个事务排队后，锁等待时间也会逐渐增加，连接池开始堆积，最终表现为接口超时。

这里有一个容易忽略的事实：缓存能够减少读取压力，却不会自动消除数据库写热点。如果所有扣减最终仍然集中更新同一条库存记录，缓存只是把请求更快地送到了数据库门口。

因此，评估缓存方案时不能只看缓存 QPS，还要看数据库实际承受的写入次数、热点行锁等待、事务提交延迟、消息堆积时间和失败重试量。

三、先拆常见误区：很多“看起来合理”的方案为什么会失效

1. 误区一：缓存里有库存，就可以直接创建订单

缓存中有库存，只能说明某一次缓存操作认为库存尚未耗尽。它不代表请求一定拥有库存，更不代表数据库已经完成确认。

如果直接根据缓存读取结果创建订单，至少有三个风险：

• 多个请求同时读取到相同库存。
• 缓存与数据库在同步窗口内存在旧值。
• 缓存服务重启或故障后，库存状态无法完整恢复。

更稳妥的做法是把缓存判断设计成“快速拦截器”或“预占器”，并给每次扣减写入可追踪的业务流水。缓存返回成功后，后续仍然要有数据库确认或可靠的异步落库。

2. 误区二：先更新数据库，再更新缓存，就一定一致

数据库提交和缓存更新是两个独立操作。即使顺序设计为“先数据库、后缓存”，第二步仍可能因网络中断、缓存不可用或服务进程退出而失败。

更麻烦的是，并发读请求可能在两个操作之间读取旧缓存。如果此时又有一个请求根据旧值作出业务判断，就会扩大不一致影响。

“先数据库后删缓存”通常比“先更新缓存后更新数据库”更容易维护，因为数据库先形成事实，缓存失效后可以回源重建。但它只是降低风险，并没有消除风险。

3. 误区三：延迟双删可以解决所有缓存一致性问题

延迟双删的基本思路是先删除缓存，更新数据库，再延迟删除一次缓存，以降低并发读写导致的旧值回填概率。它对某些读多写少的数据确实有帮助，但库存扣减属于高并发写场景，不能把它当成完整方案。

延迟双删无法解决以下问题：

• 数据库事务回滚后缓存已经发生变化。
• 第二次删除本身失败。
• 多个更新请求乱序到达缓存。
• 业务请求重复提交导致多次扣减。
• 缓存预扣成功后数据库完全没有对应流水。

我的判断是：延迟双删是一种缓存失效策略，不是库存一致性协议。它可以作为局部优化，但不能代替幂等、消息和对账。

4. 误区四：加一把分布式锁，问题就解决了

分布式锁能让多个请求在某段时间内串行执行，但它本身并不记录业务结果，也不负责消息投递和库存回补。

锁还会带来新的工程问题：锁过期时间如何设定，持锁服务宕机后如何释放，业务执行时间超过租约后是否会出现并发执行，锁粒度是否导致所有商品互相阻塞。

对于库存扣减，我通常把分布式锁放在最后考虑，而不是第一选择。优先级应当是：

1. 数据库条件更新或缓存脚本的原子性。
2. 业务请求幂等。
3. 库存状态机和唯一约束。
4. 可靠消息、重试和补偿。
5. 只有在确实存在跨步骤临界区时，才评估分布式锁。

5. 误区五：用一个 stock 字段覆盖所有业务状态

如果库存表只有一个可加可减的数字，订单取消、支付超时和人工补偿都只能直接修改这个数字。过一段时间后，团队很难回答“这次库存为什么变成了 37”。

库存不只是一个结果值，还是一组业务事件的累计结果。建议至少保留库存变更流水，记录商品、数量、变更类型、业务单号、操作时间、操作来源和前后余额。

四、专业判断逻辑：先按业务约束选择架构，再谈性能优化

1. 第一步：计算超卖成本和少卖成本

不同业务对库存错误的容忍度完全不同。普通促销赠品出现少量差异，可能只需要客服补发；高价值商品发生超卖，可能带来退款、赔付和信誉成本；医疗、票务或配额类场景则可能要求严格禁止超额分配。

因此，不能只问“系统能承受多少 QPS”，还要问“每一次错误的业务代价是多少”。我通常会让团队先写出三种成本：

• 超卖成本：赔付、退款、履约失败、客诉和品牌损失。
• 少卖成本：库存闲置、机会损失和转化下降。
• 冻结成本：订单取消后库存迟迟不能回收造成的资金或商品占用。

如果超卖成本远高于少卖成本，应该优先选择数据库权威校验和严格幂等；如果峰值极高且业务允许极短暂延迟，可以考虑缓存预扣，但必须把回补和对账作为上线条件，而不是后续优化。

2. 第二步：区分强约束和软约束

库存系统里有些约束不能被牺牲，例如“同一个订单不能扣两次”“库存不能低于零”“已经确认的订单不能被重复释放”。另一些约束可以接受短暂延迟，例如商品页面显示的剩余库存不是实时精确值。

3. 第三步：确定一致性窗口，而不是承诺“绝对一致”

缓存、数据库和消息系统之间通常存在网络延迟、事务提交延迟和消费延迟。与其在方案中写“保证强一致”，不如明确几个可测量的指标：

• 缓存与数据库的最大允许差异时间。
• 预占成功到数据库确认的目标时延。
• 异常库存进入补偿队列后的最大等待时间。
• 对账任务的执行周期和差异修复时限。

例如，一个活动系统可以定义：预占结果在 1 秒内进入确认队列，99%的正常事件在 10 秒内完成落库，异常预占在 5 分钟内释放或进入人工处理。这样的目标比一句“最终一致”更容易监控和验收。

4. 第四步：检查故障时的可逆性

我在评审库存方案时，会特别关注一个问题：每一步写入是否可逆。数据库扣减失败时能否回补缓存？消息重复时能否识别？订单取消时能否只释放原先预占的数量？如果无法回答，说明系统依赖“正常流程”，而不是具备完整的异常设计。

可逆性不等于任何操作都可以无条件加回库存。回补必须关联原业务流水，并检查当前状态。例如，已经确认消耗的库存不能因为一条迟到的“预占失败”消息再次加回，否则会形成隐性增量。

5. 第五步：用压测验证写入瓶颈，而不是凭经验堆组件

缓存是否有价值，取决于实际瓶颈。如果数据库瓶颈在库存热点更新，单纯把查询放进缓存可能几乎没有帮助；如果瓶颈在商品详情页的库存展示查询，缓存命中率提升则可能明显降低数据库读取量。

一次有价值的压测至少应记录：

• 缓存命中率和缓存操作延迟。
• 数据库库存更新 QPS。
• 数据库锁等待时间和事务提交耗时。
• 消息发送成功率、消费延迟和重试次数。
• 重复请求比例和幂等拦截数量。
• 库存差异数量、异常预占数量和回补耗时。

如果只记录接口平均响应时间，往往会掩盖 P99 延迟、长尾超时和补偿队列堆积。技术负责人真正需要的是一张从请求入口到库存最终确认的全链路指标表。

五、具体方案一：数据库原子扣减加缓存失效

1. 适合大多数普通库存业务的最小闭环

对于并发量中等、库存价值较高、团队希望降低系统复杂度的业务，我通常优先建议数据库原子扣减。缓存只负责库存展示和降低读压力，真正的扣减由数据库通过条件更新完成。

最小闭环可以是：

1. 请求携带唯一业务请求号。
2. 服务校验请求参数、限购规则和订单状态。
3. 在数据库事务中执行幂等检查。
4. 通过带库存条件的 SQL 原子扣减。
5. 写入库存变更流水和订单预占状态。
6. 事务提交成功后删除库存缓存。
7. 缓存删除失败则记录事件并重试。

2. 原子扣减 SQL 应该怎样写

库存扣减必须把“库存足够”作为更新条件，而不是先查询后在应用层判断。以单件扣减为例：

UPDATE inventory
SET available_stock = available_stock - :quantity,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND available_stock >= :quantity

AND status = 'ON_SALE';

执行后通过影响行数判断结果：

• 影响行数为 1：本次扣减成功。
• 影响行数为 0：库存不足、商品不可售或条件已经发生变化。
• 执行异常：事务失败，不能直接返回“库存不足”，应区分系统错误和业务拒绝。

这里有三个细节经常被忽略。第一，条件字段需要结合实际执行计划建立索引；第二，库存数量必须使用足够的数值范围，避免边界溢出；第三，扣减成功后要写入业务流水，否则后续无法区分正常扣减和补偿扣减。

3. 事务边界不能无限扩大

库存扣减事务中，应尽量只放入必须与库存事实同时成立的操作，例如库存状态更新、库存流水和预占记录。调用外部订单服务、支付服务或通知服务，不应长时间占用数据库事务。

一个常见的错误是：开启数据库事务后，调用远程订单接口，等待几百毫秒甚至几秒，再回头提交库存事务。峰值期间，这会显著增加锁持有时间，让本来可以快速完成的库存更新变成排队热点。

更合理的方式是：本地事务完成“预占事实和业务事件”的落库，外部流程通过消息异步推进。这样做并不意味着降低可靠性，前提是本地事件具备可靠投递和幂等消费机制。

4. 缓存应该删除还是更新

在库存扣减成功后，我更倾向于删除缓存，而不是直接在应用层计算后更新缓存。原因是更新缓存需要保证计算所依据的库存版本没有过期，多个并发写入可能导致旧值覆盖新值。

删除缓存的逻辑更简单：下一次查询发现缓存不存在，再从数据库加载当前值。为了避免删除失败，可以配合变更事件、重试队列和定期重建。

如果业务对缓存回源压力非常敏感，也可以采用带版本号的缓存更新。每次数据库变更都携带递增版本，只有更高版本的数据允许覆盖缓存，避免乱序事件把新库存改回旧库存。

5. 这套方案的边界

数据库原子扣减并不是低级方案。它最大的优势是事实集中、调试路径短、审计容易、故障恢复相对直接。很多普通电商商品、内部配额和库存价值较高的业务，先把这套方案做扎实，比直接引入多套中间件更稳妥。

它的主要限制是热点商品的写入竞争。当同一 SKU 在极短时间内承受大量扣减时，数据库行锁、连接池和事务日志都会成为瓶颈。此时再增加缓存展示层，收益有限，需要转向预扣、分片库存或活动流量隔离。

六、具体方案二：缓存原子预扣加异步落库

1. 什么时候值得承担复杂度

缓存预扣适合峰值非常集中、库存读取和扣减请求量远高于数据库同步写入能力、且业务可以接受异步确认的场景，例如限时活动、抢购、短时配额发放等。

它的核心价值不是“缓存比数据库快”这么简单，而是把大量失败请求尽早拦截在数据库之前，把真正可能成功的少量请求送入后续确认链路。

但这套方案会把一致性责任从数据库同步事务转移到缓存、消息、补偿和对账系统。技术负责人必须先确认团队是否有能力长期维护这条链路。

2. 一条可执行的预扣流程

1. 客户端生成业务请求号，服务端校验用户、商品、活动和限购规则。
2. 缓存脚本同时完成幂等判断和库存预扣，避免先判断后扣减。
3. 预扣成功后写入预占记录，记录请求号、商品、数量、时间和过期时间。
4. 通过可靠事件机制发送库存确认消息。
5. 消费者执行数据库库存流水和订单状态更新。
6. 数据库确认成功后，将预占状态改为已确认。
7. 数据库失败则根据错误类型重试、回补或进入死信队列。
8. 超过预占时限仍未确认的记录，由释放任务回补库存。

3. 缓存脚本不能只做一个 DECR

直接执行一次自减命令，只能解决“数字减一”的原子性，解决不了业务幂等。如果同一个请求重复到达，第二次仍可能继续减少库存。

更完整的脚本逻辑应当同时检查请求号和库存：

-- 伪代码：缓存原子预扣逻辑
if exists("reserve:" .. request_id) then

return "DUPLICATE"

end

local stock = get("stock:" .. sku_id)

if stock == nil or tonumber(stock) < quantity then

return "NO_STOCK"

end

decrby("stock:" .. sku_id, quantity)

set("reserve:" .. request_id, quantity, "EX", reserve_ttl)

return "RESERVED"

生产实现还需要考虑脚本执行超时、缓存集群分片、预占记录持久化、故障切换和回补幂等。这里的伪代码只能说明业务顺序，不能直接当作完整生产脚本。

4. 预扣成功后，订单服务不应只依赖同步返回

缓存预扣成功后，如果系统只返回一个“成功”，但没有可靠地记录后续确认任务，那么服务进程一旦退出，就可能留下没有订单、没有数据库流水、也没有释放动作的孤儿预占。

因此，预扣成功后至少要有一种可恢复记录：

• 数据库预占表。
• 可靠消息中的库存事件。
• 本地消息表或 Outbox 记录。
• 可扫描的预占键及其过期时间。

在高可靠场景中，我不建议只把预占信息留在缓存里。缓存适合快速执行，但不适合承载全部异常审计信息。

5. 回补库存必须有状态条件

回补操作不能简单地执行“库存加一”。它必须先判断这笔预占是否仍处于“已预占”状态。

UPDATE inventory_reservation
SET status = 'RELEASED',

released_at = CURRENT_TIMESTAMP

WHERE reservation_id = :reservation_id

AND status = 'RESERVED';

只有影响行数为 1 时，才允许执行对应的库存回补。影响行数为 0，说明这笔预占已经确认、释放或被其他补偿任务处理，不能再次加库存。

这条规则看似简单，却是防止“重复释放导致库存凭空增加”的关键。所有补偿动作都必须先改变业务状态，再根据状态变更结果决定是否调整库存。

七、同步、消息与补偿：把失败路径写进主流程

1. 数据库成功，缓存删除失败

这是数据库权威模式中最常见的异常之一。数据库已经扣减成功，但缓存仍保留旧值，后续读请求可能短时间看到较大的库存。

处理方式可以按复杂度递进：

• 直接删除缓存，失败后记录重试任务。
• 通过库存变更事件异步删除或刷新缓存。
• 为缓存值增加版本号，拒绝旧版本覆盖新版本。
• 通过定时对账发现长期未失效的缓存并主动修复。

不要在缓存删除失败时直接把已经成功的数据库扣减判定为失败，否则客户端重试可能造成重复扣减。数据库事务结果和缓存同步结果应当分别记录、分别监控。

2. 缓存成功，数据库确认失败

这是缓存预扣模式中风险更高的异常。缓存已经减少库存，但数据库没有形成对应事实。此时有三种可能：暂时性失败、业务性失败和永久性失败。

3. 消息可靠性不等于消息一定只消费一次

很多消息系统强调至少一次投递，这意味着消费者必须接受重复消息。真正需要做到的不是“消息绝不重复”，而是“重复消息不会重复改变业务结果”。

库存消费者可以采用以下任一组合：

• 消费记录表加唯一业务事件号。
• 库存流水表加事件唯一索引。
• 状态机条件更新，例如只有“已预占”才能转为“已确认”。
• 版本号校验，拒绝旧事件覆盖新状态。
• 业务结果查询加幂等返回，让重复消费获得同一结果。

我不建议把幂等完全交给消息中间件。消息层只能帮助投递和消费管理，真正的业务幂等必须落在数据库约束或状态机上。

4. 重试必须区分次数、间隔和错误类型

无条件快速重试会把数据库故障放大成雪崩。无条件长时间重试又会让库存迟迟无法释放。一个可执行的重试策略应当包含错误分类、退避间隔、最大次数和死信转移。

例如，可以采用 1 秒、5 秒、30 秒、2 分钟的递增间隔。达到最大次数后，不再继续占用主消费线程，而是进入死信队列。对预占库存而言，还要结合预占有效期：如果订单已经超过可支付时限，继续等待数据库确认可能不如直接进入释放流程。

5. 对账不是“出了问题再查”，而是库存系统的持续验证

对账任务应当定期比较至少三类数据：数据库库存流水汇总、订单与预占状态、缓存中的可售库存。三者不一定在同一时刻完全相等，但差异必须有解释。

一套可执行的对账逻辑可以是：

1. 按 SKU 汇总数据库库存初始值、增加、确认消耗和释放数量。
2. 查询仍处于预占状态的订单及其过期时间。
3. 读取缓存库存并记录采样时间和版本号。
4. 对比可解释差异与不可解释差异。
5. 对不可解释差异创建补偿单，禁止直接覆盖原始流水。
6. 补偿完成后再次对账，直到差异收敛或转人工处理。

对账程序本身也要幂等，并保留每次对账的结果。否则系统虽然能修复库存，却无法回答“差异何时产生、由什么事件导致、如何修复”。

八、幂等、状态机与库存流水：比加锁更值得优先投入

1. 幂等键应该从业务入口一路传递

幂等键不能只在接口层生成后就丢失。它应该贯穿请求日志、库存预占记录、订单记录、消息事件和库存流水。

常见的幂等键组合包括：

• 客户端请求号：适合识别同一次提交的重复请求。
• 订单号加商品编号：适合订单维度的库存扣减。
• 用户编号加活动编号加商品编号：适合限购场景。
• 事件编号：适合消息消费和补偿重放。

不要只使用用户编号作为全局幂等键。一个用户可能在不同订单、不同商品或不同活动中合法购买多次，幂等粒度必须与业务规则一致。

2. 状态机让迟到消息有地方可去

没有状态机时，消费者往往只根据消息内容执行加减操作。消息一旦乱序或迟到，就可能把已经确认的记录再次释放。

建议为预占记录设计明确状态：

RESERVED –确认成功–> CONFIRMED
RESERVED –超时释放–> RELEASED

RESERVED –业务失败–> RELEASED

CONFIRMED –重复确认–> CONFIRMED

RELEASED –迟到确认–> 拒绝或进入人工处理

其中最重要的是最后一行：已经释放的记录收到迟到确认消息时，不能简单地再次确认。系统需要根据订单状态和库存流水判断是否需要人工介入。

3. 库存流水要支持追责，而不仅是统计

库存流水字段至少应包括：流水号、商品编号、变更数量、变更前余额、变更后余额、变更类型、业务单号、请求号、事件号、操作来源、创建时间和处理节点。

变更前后余额尤其有价值。它能够帮助排查“数量算对了，但顺序不对”的问题，也能识别重复回补和并发覆盖。

如果流水量很大，可以进行分区、归档和汇总，但不建议在主业务表中直接删除历史记录。库存异常往往不是在发生当天发现，而是在盘点、退款或售后阶段暴露。

4. 分布式锁什么时候才有价值

如果数据库条件更新已经能保证库存不低于零，缓存脚本已经能保证预扣原子性，那么再加锁未必会带来额外收益，反而可能增加等待和故障处理复杂度。

锁更适合保护以下场景：

• 同一商品的复杂库存拆分和合并操作。
• 库存配置变更与活动切换的临界过程。
• 对账修复时需要避免同一 SKU 被多个修复任务同时处理。
• 无法通过数据库条件更新表达的多步骤业务规则。

锁的设计仍然要配合超时、续租、持锁者标识和幂等校验。锁是并发控制工具，不是完整的一致性方案。

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

1. 普通商品、并发量中等

如果商品日常访问量较稳定，没有极端抢购峰值，优先采用数据库原子扣减。缓存只做商品详情和库存展示，扣减结果由数据库影响行数决定。

行动重点是：

• 补齐库存条件更新。
• 增加请求号和订单号唯一约束。
• 事务中写库存流水。
• 提交后删除缓存。
• 每天执行库存与订单对账。

这类业务不需要一开始就引入复杂的缓存预扣和多级消息链路。先把数据模型、事务边界和异常日志做好，通常比追求极限吞吐更有价值。

2. 高读低写、库存展示请求很多

如果主要问题是详情页查询压垮数据库，而实际扣减量并不高，可以采用缓存预热、缓存读取和数据库原子扣减组合。

需要注意，库存展示可以做近似值。例如页面显示“库存紧张”而不是精确显示 3 件，能够减少用户对瞬时数字的依赖。真正下单时仍然走原子扣减，不要把展示缓存当作最终判断。

3. 秒杀或短时活动、峰值高度集中

此时可以考虑缓存原子预扣和异步落库，但上线前必须完成故障演练。至少要模拟缓存操作成功后服务进程退出、消息重复消费、数据库持续不可用、订单超时释放和缓存主从切换。

行动重点是：

• 缓存脚本同时完成幂等和库存判断。
• 预扣记录必须可扫描、可过期、可回补。
• 消息事件必须具备唯一事件号。
• 数据库消费必须使用状态条件更新。
• 对账和死信处理必须在活动前上线。
• 活动结束后要执行全量盘点，而不是只看接口成功率。

4. 高价值商品或严格禁止超卖

如果每一次超卖都可能带来较高赔付或履约风险，不建议仅凭缓存预扣结果直接确认订单。可以让缓存负责流量拦截，但最终扣减必须通过数据库权威校验和可审计流水。

在这类场景中，少卖或短暂返回“库存不足”的成本，可能低于超卖成本。技术负责人要明确告诉业务方：追求绝对峰值吞吐，可能意味着更长的异常恢复链路；如果业务不能接受这个风险，就应优先选择更强的事实约束。

5. 复杂库存，包括仓库、批次和区域维度

当库存同时受到仓库、批次、地区、渠道和保质期影响时，不能只维护一个商品总库存。预扣时需要确定具体库存来源，释放时也必须回到原先的库存池。

建议建立库存分配记录，保存“从哪个仓、哪个批次、哪个库存池扣减了多少”。如果先扣总库存、后异步分配具体仓库，必须处理分配失败和重新分配，否则总量看似正确，实际履约仍可能失败。

6. 团队缺乏中间件运维能力

如果团队没有成熟的消息监控、缓存集群运维、死信处理和对账经验，不建议为了追求理论吞吐直接采用复杂的缓存预扣架构。

可以先采用数据库原子扣减，配合读缓存、限流、队列削峰和数据库热点优化。架构的可维护性本身就是效率，尤其是库存系统一旦出现问题，排查成本往往高于一次性能不足。

十、数据观察与压测设计：不要用平均值掩盖库存风险

1. 一次合格的库存压测应模拟什么

库存压测不应只有“并发用户持续扣减”这一条曲线。真实系统更接近混合流量：部分用户查看库存，部分用户重复提交，部分请求因库存不足被拦截，部分消息被重复消费，还有一部分订单在超时后需要释放。

建议至少设计以下测试组：

• 库存充足时的高并发扣减。
• 库存只剩少量时的竞争扣减。
• 同一请求号重复提交。
• 不同请求号同时竞争最后一件库存。
• 数据库扣减成功但缓存删除失败。
• 缓存预扣成功但消息发送失败。
• 消息重复消费和乱序消费。
• 订单取消、支付超时和库存回补。
• 服务重启、缓存切换和数据库短暂不可用。

2. 重点观察 P99，而不是只看平均响应时间

平均响应时间可能是 20 毫秒，但 1%的请求已经等待 2 秒。对于秒杀和限时活动，长尾请求会触发客户端重试，进而增加重复请求和消息量。

我建议把以下指标放在同一张监控看板中：

3. 用一组示意数据看出瓶颈位置

下面是一组用于方案评审的情景模拟数据。它不是某个企业的生产结果，但可以说明为什么“接口更快”不等于“库存更安全”。

假设缓存展示上线后，库存查询 P99 从 180 毫秒下降到 35 毫秒，数据库读取量下降 80%；但数据库热点更新锁等待只从 420 毫秒下降到 390 毫秒，库存确认延迟几乎没有变化。这说明系统的主要瓶颈不在读取，而在同一库存行的并发写入。

此时继续提高缓存命中率，收益会越来越有限。更有效的方向可能是活动库存分桶、异步预扣、限流排队或按库存池拆分热点。

4. 数据来源要和数据性质一起写清楚

生产数据应注明采集时间、接口范围、机器配置、数据库版本、缓存持久化设置、并发模型和统计分位数。压测数据应明确是单机、集群还是跨机房环境。

如果没有真实生产数据，可以使用“情景模拟”“样本推演”或“建议基准”，但不能把模拟数字包装成行业平均值。技术文章最容易失去可信度的地方，就是给出一个看似精确的性能提升比例，却不交代测试条件。

十一、上线前的工程清单：技术负责人应逐项验收

1. 数据模型验收

• 是否明确可售、预占、确认和释放库存的定义。
• 是否存在库存变更流水，而不是只保存最终余额。
• 库存流水是否关联订单号、请求号和事件号。
• 是否有防止库存低于零的数据库约束或原子条件。
• 库存数量、版本号和时间字段是否具备足够精度和范围。

2. 并发与幂等验收

• 同一个请求重复提交是否返回同一个业务结果。
• 多个请求竞争最后一件商品时，是否最多确认一个有效扣减。
• 消息重复消费是否不会重复减少或增加库存。
• 补偿任务重复执行是否不会重复回补。
• 数据库更新是否使用了正确的条件和索引。

3. 缓存验收

• 缓存的职责是展示、预扣还是临时限流，是否写入方案文档。
• 数据库成功而缓存失效失败时，是否有重试和重建机制。
• 缓存重启、切换和数据丢失后，是否能够从数据库恢复。
• 缓存值是否带有版本或时间信息。
• 缓存回源时是否有击穿保护和流量限制。

4. 消息与补偿验收

• 库存事件是否有唯一事件号。
• 消息发送失败是否能够发现。
• 消费者失败是否支持退避重试。
• 是否设置死信队列和人工处理入口。
• 预占超过有效期后是否能够自动释放。
• 回补前是否检查预占状态，避免重复释放。

5. 监控与演练验收

• 是否监控接口 P95、P99 延迟和超时率。
• 是否监控缓存命中率、数据库锁等待和连接池使用率。
• 是否监控预占到确认的延迟分布。
• 是否监控异常预占、消息重试、死信和人工补偿量。
• 是否有按 SKU 的库存差异对账报告。
• 是否完成缓存故障、数据库故障、消息重复和服务重启演练。

十二、方案取舍：效率不是组件数量，而是故障后的可恢复能力

1. 数据库权威模式的收益与代价

数据库原子扣减的收益是边界清晰、审计方便、状态容易查询。它适合作为大多数业务的起点，尤其适合库存价值高、并发量可预测、业务方更关注不超卖而不是极限吞吐的场景。

它的代价是数据库写热点明显，峰值流量下可能出现锁等待和长尾延迟。要解决这个问题，不能只靠增加缓存，还要考虑请求限流、队列削峰、库存分片和商品维度拆分。

2. 缓存预扣模式的收益与代价

缓存预扣能够快速处理大量并发请求，减少无效请求进入数据库同步链路。它适合峰值强、失败请求比例高、业务可以接受异步确认的场景。

它的代价是系统复杂度显著上升。你需要长期维护预占记录、可靠事件、重试、死信、回补、超时释放、缓存恢复和对账。若团队没有对应的监控和演练能力，理论上的吞吐提升可能会被实际故障成本抵消。

3. 分段库存的收益与代价

对于单个商品写热点非常严重的活动，可以把库存拆成多个库存桶，让请求分散更新不同记录，再通过逻辑汇总得到剩余库存。这能够降低单行锁竞争。

但分段库存会增加库存分配、桶耗尽、补偿和盘点难度。尤其是库存回补时，必须明确回到哪个库存桶，不能随意加到一个总库存字段上。它更适合技术团队成熟、流量峰值明确且有完整监控的业务。

4. 强一致和最终一致的取舍

强一致并不是所有环节都必须同步完成，而是关键业务事实不能被错误确认。最终一致也不是“先做了再说”，而是允许一定时间差，但必须有确定的收敛机制。

十三、技术负责人下一步怎么做

1. 先画出一张库存状态图

不要先写缓存代码。先把“可售、预占、确认、释放、异常、人工处理”画出来，明确每个状态能由谁触发、能转向哪里、重复事件如何处理。

如果状态图画不清楚，说明业务边界还没有被定义。此时引入更多中间件，只会把模糊的流程包装得更复杂。

2. 再做一次带故障注入的压测

除了正常并发，还要主动让缓存删除失败、消息重复、数据库超时和服务进程退出。记录每一个请求号最终去了哪里：成功确认、正确释放、重试中、死信还是人工处理。

压测结束后，不要只问“最高 QPS 是多少”，还要问：

• 库存是否出现负数。
• 是否有重复扣减。
• 是否有长期悬挂预占。
• 异常是否在承诺时限内收敛。
• 对账能否解释每一件库存的变更来源。

3. 最后按业务成本确定方案

如果当前问题只是库存查询慢，先做读缓存和缓存失效；如果问题是数据库热点写入，评估限流、削峰、预扣和库存分片；如果问题是库存差异无法解释，优先补库存流水、状态机和对账，而不是继续调高缓存容量。

我的建议是：先选择最简单、能够证明正确的方案，再根据压测中已经确认的瓶颈增加复杂度。不要为了一个尚未测量的峰值问题，提前引入一整套难以恢复的异步链路。

十四、结语：真正高效的库存架构，是让错误有记录、让失败能回去

缓存同步的价值，从来不只是把一次读取从 100 毫秒变成 20 毫秒。它真正改变的是系统处理流量的方式：缓存可以在入口快速拦截、预扣和削峰，但数据库仍需要承担事实确认，消息系统需要承担可靠传递，状态机需要限制非法迁移，对账和补偿需要让异常最终收敛。

库存系统最危险的方案，往往不是明显错误的方案，而是“正常流程很顺、异常流程没人负责”的方案。它们在开发环境里表现良好，在峰值、超时、重试和服务重启之后才暴露问题。

如果你正在改造库存系统，下一步可以按以下顺序执行：

1. 确定库存权威来源和业务状态模型。
2. 为扣减、确认和释放补齐幂等键。
3. 用数据库条件更新或缓存原子脚本保证单次操作原子性。
4. 建立库存流水、消息事件和状态条件更新。
5. 补齐重试、死信、超时释放和定期对账。
6. 通过混合流量和故障注入压测验证真实瓶颈。

缓存负责快，数据库负责真，消息负责传，补偿负责收敛，对账负责证明。技术负责人真正要优化的，不是某一个组件的速度，而是整条库存链路在高峰和故障之后仍然能够给出确定、可解释、可恢复的结果。

UPDATE inventory SET available_stock = available_stock - 1, updated_at = NOW() WHERE sku_id = ?AND available_stock > 0;

免费注册

咨询方案

扫码咨询方案