仓储系统里最难排查的缓存问题，往往不是“Redis 删除失败”，而是库存表已经更新、缓存也删过一次，几百毫秒后缓存却又被旧数据重新写回。问题通常发生在数据库事务、主从复制、并发回填和异步消息的交界处。我的判断是：缓存同步不是 Redis 命令设计，而是表结构能否表达业务事实、数据版本和变更事件的问题。如果表里没有版本号、流水和可重试的事件记录，延时双删只能减少部分概率，无法让团队真正做到可追踪、可补偿、可验收。

数据库存：仓储系统团队操作手册：表结构设计中的缓存同步怎么落地

一、先讲核心结论：缓存同步要从库存表设计开始

1. 数据库保存事实，缓存保存读取效率

在仓储系统中，数据库应该保存“库存事实”，缓存只负责缩短查询路径。可用库存到底是多少，必须由库存主表、库存流水、扣减事务或库存服务来定义，而不能由某个缓存 Key 的当前值来定义。

这条边界看似基础，实际却是很多项目的分水岭。有些团队为了提高扣减性能，直接读取缓存中的库存数量，再把扣减后的结果写回缓存。只要发生缓存淘汰、服务重启、消息乱序或并发扣减，缓存就可能从“加速层”变成新的事实来源，最终出现超卖、少卖或库存回滚。

我通常要求团队先回答三个问题，再讨论缓存策略：

• 库存发生变化时，哪张表是最终事实来源？
• 缓存中的数据如何判断比数据库新还是旧？
• 删除缓存失败、消息重复或数据异常时，能否自动恢复并留下记录？

如果这三个问题没有明确答案，就不建议直接上线延时双删、异步刷新或缓存预热。技术方案可能暂时降低接口延迟，却会把不一致问题推迟到盘点、对账或订单履约环节。

2. 不同仓储数据不应该使用同一套一致性等级

商品名称、图片、包装规格和计量单位出现几秒钟旧值，通常不会导致履约错误；可用库存、预占库存和已分配库存则不同，它们直接影响订单能否继续、拣货任务是否创建以及是否发生超卖。

表格中的“旧值容忍度”不是数据库技术参数，而是业务规则。比如拣货员看到的库位可用量可以接受短暂延迟，但订单服务在确认扣减时不能把缓存里的旧库存当成授权依据。读请求可以追求最终一致，写请求必须先守住库存事实。

3. 表结构至少要表达四种信息

一张能支撑缓存同步的库存主表，不只是存数量。它至少要表达业务唯一性、当前状态、数据版本和最后变更时间。同步系统还需要知道这次变化由什么业务动作触发，以及变化是否已经成功传播到缓存。

因此，我会把字段分成四组：

• 定位字段：仓库编号、库区编号、库位编号、SKU 编号、批次编号。
• 事实字段：账面数量、可用数量、预占数量、锁定数量、在途数量。
• 排序字段：版本号、更新时间、数据库提交时间或业务序列号。
• 追踪字段：最后操作单号、变更来源、操作人、请求号和审计标识。

没有排序字段时，消费者无法判断旧消息是否晚到；没有追踪字段时，排查人员只能看到“现在是多少”，却不知道“为什么变成这样”；没有业务唯一键时，同一个 SKU 在同一个仓库里可能被不同代码路径写成两条库存记录。

二、真实场景：为什么删过缓存，系统仍然读到旧库存

1. 一个典型的并发回填时序

假设仓库 1 中 SKU-A 的可用库存原本是 100。缓存中也是 100。此时订单服务扣减 20，查询服务同时收到一个库存查询请求。看起来只是一次更新和一次查询，但实际可能形成以下时序：

1. 扣减请求开始更新主库，目标值变为 80。
2. 查询请求发现缓存被删除或刚好失效。
3. 查询请求从延迟中的只读副本读取到旧值 100。
4. 查询请求把 100 回填到缓存。
5. 扣减请求完成第一次删除缓存。
6. 旧值 100 再次进入缓存，后续请求继续读取错误结果。

这里真正的问题不是某一条 Redis 删除命令写错，而是读请求在缓存重建时没有确认数据来源和版本。即使再补一次删除，也只能覆盖部分时序。如果副本延迟超过延迟删除窗口，第二次删除完成后仍可能有旧值回填。

我在评审这类链路时，不会先问“延时多久合适”，而会先看四个时间：数据库事务提交时间、主从追平时间、缓存回填时间和消息消费时间。只有知道这四个时间的分布，才能决定延时双删是否有价值。

2. 库存主表、流水表和事件表要形成一条证据链

当出现缓存与数据库不一致时，团队需要按顺序还原：库存主表什么时候变更、哪一张流水记录触发变更、哪一条同步事件负责删除缓存、消费者是否成功处理、缓存最后一次写入来自哪个请求。

如果团队只有一张库存主表，就只能看到最终结果。即使发现缓存不对，也很难判断是数据库更新错误、异步事件丢失、消费者重复执行，还是某个查询接口用旧数据回填。

因此，建议把三张表视为一个最小闭环：

• 库存主表：保存当前业务事实。
• 库存流水表：保存每一次库存变更及业务原因。
• 同步事件表：保存应该传播到缓存或其他服务的变更事件。

这三张表不代表所有系统都必须完全照搬，但它们分别承担“现在是什么”“怎么变的”“还要传播什么”三个问题。只要缺少其中一环，排查和补偿成本就会明显增加。

3. 不要把查询日志当成同步审计

访问日志只能说明某个接口被调用过，不能证明缓存写入的是哪个版本。很多团队看到日志中有一次查询，就认为缓存应该已经更新，实际上查询可能读取了从库旧值，也可能在缓存写入前被连接中断。

更可靠的做法是在缓存值或缓存元数据中保存版本号、更新时间和数据来源。例如：

{
"warehouseId": 1,

"skuId": 1001,

"availableQty": 80,

"reservedQty": 12,

"version": 2058,

"source": "warehouse_stock",

"updatedAt": "2026-09-16T10:20:30Z"

}

当缓存出现异常时，运维人员可以直接比较主表版本、事件版本和缓存版本。如果缓存版本小于数据库版本，问题是同步滞后；如果缓存版本大于数据库版本，问题可能是错误写入、测试数据污染或事件模型设计不完整。

三、常见误区：很多“看起来可靠”的方案为什么不够

1. 误区一：先更新缓存，再更新数据库

先写缓存、后写数据库的方案响应速度快，但它把缓存暴露在数据库事务之外。只要数据库更新失败，缓存就可能提前展示一个不存在的库存状态；如果后续没有回滚缓存，脏数据会持续到 TTL 到期。

这种顺序尤其不适合库存扣减。库存更新失败可能是版本冲突、库存不足、数据库连接异常或事务回滚，缓存却没有能力判断这些业务结果。缓存应该接收数据库已经确认的变更，而不应该提前宣告变更成功。

2. 误区二：写库成功后只删除一次缓存

“更新数据库，然后删除缓存”是 Cache-Aside 中常见的基础路径，但它不能覆盖所有并发情况。删除动作可能失败，删除后可能有读请求从旧数据源回填，跨服务场景还可能因为消息投递失败而没有完成失效。

这并不意味着基础方案不能用，而是要明确它的适用边界。低并发、单库、主库读取、缓存只读且 TTL 较短的商品资料，可以采用这种简单方案。库存、价格、额度和订单状态则应增加版本校验、事件记录或同步巡检。

3. 误区三：延时双删可以保证强一致

延时双删通常是第一次删除缓存，等待一段时间后再次删除。它的价值是降低“旧值在删除后被并发读请求回填”的概率，但它不是事务协议，也没有办法天然感知数据库副本是否已经追平。

如果延迟时间设置为 500 毫秒，而实际副本延迟在高峰期达到 2 秒，第二次删除完成后仍然可能有旧数据回填。如果延迟任务执行失败，方案还会退化为一次删除。因此，延时双删应被视为补偿动作，而不是一致性的唯一保障。

4. 误区四：TTL 越短，数据越安全

TTL 只能限制脏数据最长存活时间，不能阻止错误数据在 TTL 期间被反复读取。对库存接口而言，哪怕脏数据只存活 10 秒，也可能在高并发下影响大量订单判断。

TTL 过短还会带来缓存命中率下降、数据库回源增多和热点 Key 击穿。真正合理的做法是根据业务容忍窗口设置 TTL，再用主动失效、版本校验和异常巡检缩短错误数据的发现与修复时间。

5. 误区五：消息队列天然保证同步可靠

消息队列能提升解耦、削峰和重试能力，但不会自动解决消息丢失、重复、乱序和积压。尤其是数据库事务提交成功后，如果消息发送发生在事务之外，服务进程可能在两者之间宕机，形成“库存已经扣减、同步事件没有产生”的空洞。

更稳妥的方式是采用 Outbox 思路：库存更新、流水写入和同步事件写入放在同一个数据库事务里，再由独立投递程序发送消息。这样即使消息队列短暂不可用，事件仍然留在数据库中，可以继续重试。

6. 误区六：所有缓存都应该刷新，而不是删除

刷新缓存看起来更快，但它要求消费者准确构造缓存值，还要处理事件乱序和局部字段更新。如果一个缓存对象由多个表聚合而成，事件消费者可能只拿到部分信息，直接刷新反而会写入不完整快照。

删除缓存通常更保守：数据库变更确认后删除，下一次读取再从可靠数据源重建。对高频更新的库存数据，我更倾向于“写库加事件、异步失效、读主库回填、缓存携带版本”的组合，而不是让多个服务直接写复杂缓存结构。

四、表结构落地：一套可追踪、可幂等、可补偿的设计

1. 库存主表：用业务唯一键锁住事实边界

库存主表最重要的不是字段数量，而是同一个业务对象能否被唯一定位。对于仓库级库存，常见唯一键是 warehouse_id 加 sku_id；如果库存按批次、货主或库位隔离，则必须把这些维度纳入唯一键，否则缓存 Key 和数据库记录会产生映射歧义。

CREATE TABLE warehouse_stock (
id BIGINT PRIMARY KEY,

owner_id BIGINT NOT NULL,

warehouse_id BIGINT NOT NULL,

location_id BIGINT NOT NULL,

sku_id BIGINT NOT NULL,

batch_no VARCHAR(64) NOT NULL DEFAULT '',

on_hand_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,

available_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,

reserved_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,

locked_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,

version BIGINT NOT NULL DEFAULT 0,

last_request_id VARCHAR(64) NOT NULL DEFAULT '',

last_biz_no VARCHAR(64) NOT NULL DEFAULT '',

updated_at TIMESTAMP NOT NULL,

created_at TIMESTAMP NOT NULL,

UNIQUE KEY uk_stock_scope (

owner_id,

warehouse_id,

location_id,

sku_id,

batch_no

),

KEY idx_stock_updated_at (updated_at),

KEY idx_stock_sku (sku_id, warehouse_id)

);

这里的 version 不是装饰字段。它可以通过乐观锁避免并发更新覆盖，也可以作为事件顺序和缓存版本判断依据。last_request_id 用于识别请求重试，last_biz_no 用于关联订单、入库单、出库单或盘点单。

库存数量建议拆成 on_hand_qty、available_qty、reserved_qty 和 locked_qty，而不是只保存一个 total_qty。因为不同业务动作对数量的影响不同：预占可能减少可用量但不减少账面量，出库确认才会减少账面量，盘点调整则可能同时改变多个字段。

2. 库存流水表：让每一次数量变化可复核

流水表的职责不是复制主表，而是记录变化过程。它应能回答“本次变化由什么单据触发、变化前是多少、变化后是多少、哪个请求提交、是否成功”。对于库存争议，流水往往比当前库存值更有解释力。

CREATE TABLE stock_change_log (
id BIGINT PRIMARY KEY,
request_id VARCHAR(64) NOT NULL,
biz_no VARCHAR(64) NOT NULL,
biz_type VARCHAR(32) NOT NULL,
owner_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
location_id BIGINT NOT NULL,
sku_id BIGINT NOT NULL,
batch_no VARCHAR(64) NOT NULL DEFAULT '',
before_available_qty DECIMAL(18, 4) NOT NULL,
change_available_qty DECIMAL(18, 4) NOT NULL,
after_available_qty DECIMAL(18, 4) NOT NULL,
before_version BIGINT NOT NULL,
after_version BIGINT NOT NULL,
operator_id BIGINT NULL,
created_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_request_biz (request_id, biz_no, biz_type),
KEY idx_stock_change (warehouse_id, sku_id, created_at)
);

request_id 和业务单号不应混为一谈。业务单号可能在多个接口重试，request_id 更适合识别一次调用。两者同时保留，可以区分“同一张出库单的重复请求”和“不同业务动作碰巧使用相似参数”。

唯一索引 uk_request_biz 是幂等保护的一部分，但不能替代业务层校验。对于一次重试请求，服务仍应返回第一次处理结果或当前状态，而不是因为唯一键冲突后简单返回失败。

3. 同步事件表：把消息从“瞬时动作”变成“可恢复记录”

直接在事务代码中调用消息队列，最容易出现数据库与消息不一致。库存事务提交后，服务可能在发送消息之前崩溃；如果事务回滚而消息已经发出，消费者又可能误删或刷新缓存。

同步事件表的目标是把“应该传播的变更”持久化。事件表和库存主表在同一个数据库事务中提交，随后由投递器负责发送。这样消息队列短暂不可用时，事件不会凭空消失。

CREATE TABLE cache_sync_event (
id BIGINT PRIMARY KEY,

aggregate_type VARCHAR(64) NOT NULL,

aggregate_id VARCHAR(160) NOT NULL,

event_type VARCHAR(64) NOT NULL,

event_version BIGINT NOT NULL,

payload JSON NOT NULL,

status VARCHAR(24) NOT NULL DEFAULT 'PENDING',

retry_count INT NOT NULL DEFAULT 0,

next_retry_at TIMESTAMP NULL,

locked_at TIMESTAMP NULL,

sent_at TIMESTAMP NULL,

last_error VARCHAR(512) NULL,

created_at TIMESTAMP NOT NULL,

updated_at TIMESTAMP NOT NULL,

UNIQUE KEY uk_aggregate_version (

aggregate_type,

aggregate_id,

event_version

),

KEY idx_pending_retry (status, next_retry_at),

KEY idx_event_created (created_at)

);

aggregate_id 要能稳定对应一个缓存聚合，例如“货主-仓库-SKU”，而不是使用容易变化的页面参数。event_version 必须来自库存主表的版本变化，不能在消息发送时临时生成，否则无法证明事件与数据库事实处于同一顺序。

4. 事务边界：主表、流水和事件必须一起提交

一次库存扣减的推荐事务边界如下：

1. 根据业务唯一键查询库存主表，并锁定目标记录或使用版本条件更新。
2. 检查可用数量是否足够。
3. 更新 available_qty、reserved_qty 或 on_hand_qty。
4. version 加一，并记录 request_id 与业务单号。
5. 写入库存流水表。
6. 写入 cache_sync_event。
7. 所有操作成功后提交事务。

示例 SQL 可以这样表达乐观锁约束：

UPDATE warehouse_stock
SET available_qty = available_qty - :deductQty,

reserved_qty = reserved_qty + :deductQty,

version = version + 1,

last_request_id = :requestId,

last_biz_no = :bizNo,

updated_at = CURRENT_TIMESTAMP

WHERE owner_id = :ownerId

AND warehouse_id = :warehouseId

AND location_id = :locationId

AND sku_id = :skuId

AND batch_no = :batchNo

AND version = :oldVersion

AND available_qty >= :deductQty;

如果影响行数为 0，不能直接认为数据库异常。它可能代表库存不足，也可能代表版本冲突。两种情况的处理方式不同：库存不足应返回业务失败，版本冲突则可以重新读取并有限重试。

5. 事件投递器：不要让同步表变成新的“无人值守垃圾场”

Outbox 设计只有在事件表被持续消费时才有价值。投递器应按状态、重试时间和创建时间扫描待发送事件，发送成功后更新状态；发送失败则记录错误、增加重试次数并计算下一次重试时间。

重试不建议无限快速循环。可以采用递增退避，例如 1 秒、5 秒、30 秒、2 分钟、10 分钟，并设置最大次数。超过上限后进入死信状态，由告警系统通知负责人。

事件投递器还要处理并发抢占。多个实例同时扫描同一事件时，应通过数据库行锁、租约字段或状态条件更新避免重复投递。即使投递仍可能重复，消费者也必须幂等，因为分布式系统中“恰好只投递一次”通常不是一个可以轻易依赖的前提。

五、读取与写入链路：把缓存放在正确的位置

1. 读取链路要先决定“从哪里回填”

Cache-Aside 的读取流程通常是先查缓存，未命中后查数据库，再把结果写入缓存。但对仓储库存而言，真正关键的问题是：未命中时查询主库、只读副本，还是专用库存服务。

如果缓存回填使用只读副本，需要把复制延迟纳入一致性设计。商品基础资料可以接受这种做法；库存查询则应结合业务容忍度。如果查询结果会直接参与订单确认，建议读取主库或调用已经具备原子扣减能力的库存服务。

我会把“展示库存”和“授权库存”分成两个接口。展示库存允许使用缓存并标注更新时间，授权库存必须由事实源重新确认。这样可以避免页面为了追求低延迟，把缓存查询结果直接当成扣减许可。

2. 防止多个请求同时回填旧数据

缓存失效后，大量请求同时回源，会出现缓存击穿；如果回源数据来自延迟副本，还可能把同一个旧值批量写入缓存。常用的处理方式包括互斥锁、请求合并、热点 Key 预热和短暂空值缓存。

互斥锁并不是越重越好。对于单个 SKU 的短时热点，可以让第一个请求负责回源，其余请求等待；对于库存列表或大范围查询，则更适合采用分片缓存、异步刷新或限制单次查询范围。

缓存回填代码至少应带上版本判断。伪代码如下：

cached = cache.get(key)
if cached exists:

return cached

lock(key)

try:

cached = cache.get(key)

if cached exists:

return cached

record = loadFromReliableSource()

value = buildCacheValue(record)

current = cache.get(key)

if current is empty or value.version >= current.version:

cache.set(key, value, ttl)

return value

finally:

unlock(key)

代码中的版本判断不能替代数据库事务，但可以阻止迟到的回源结果覆盖缓存中已经存在的新版本。对于复杂聚合缓存，还需要判断参与聚合的多张表是否来自同一个一致性快照。

3. 写入链路建议采用“先库后事件，异步失效”

推荐写入顺序是：数据库事务更新主表，写入流水，写入同步事件，事务提交，异步删除或刷新缓存。缓存操作不应阻塞库存主事务太久，否则 Redis 的短暂波动可能扩大数据库事务持锁时间。

但异步失效会带来一个可见窗口：数据库已经是新值，缓存暂时仍是旧值。这个窗口必须被业务接受或被读取策略补偿。对可用库存，可以在下单授权环节再次查事实源；对商品资料，则可以接受短暂延迟。

4. 删除缓存与刷新缓存的判断标准

删除是把错误状态清空，刷新是主动写入新状态。如果团队没有版本校验和完善重试，我通常优先选择删除；如果缓存重建很重、查询链路复杂，再考虑基于事件版本的刷新。

六、延时双删、消息队列与版本号，应该怎样组合

1. 延时双删适合覆盖哪一段风险

延时双删最适合处理的是一个窄场景：写请求删除缓存后，读请求在数据库或副本中读到旧值并回填，随后第二次删除把这个错误回填清掉。它对“删除命令失败”“事件没有产生”“消费者长期积压”并没有直接解决能力。

延迟时间不应照搬网上的固定数字。可以先观察数据库复制延迟的 P99、缓存回填耗时 P99 和业务读写并发窗口，再设置初始值。比如复制延迟 P99 为 180 毫秒、回填耗时 P99 为 60 毫秒，初始延迟可以覆盖这两个时间的组合，并通过压测验证，而不是简单写死为 1 秒。

需要注意，复制延迟是动态值。促销、批量入库、夜间盘点和数据库扩容都可能改变延迟分布。因此延时双删任务最好记录计划执行时间、实际执行时间和删除结果，以便判断它是否真的覆盖了风险窗口。

2. 消息队列更适合承担传播和补偿

消息队列的定位应该是“把数据库变更传播给缓存及其他下游”，而不是替代数据库事务。一个库存变更事件可以包含聚合主键、版本号、变更类型和必要的业务上下文，但不建议让消费者完全相信消息里的数量字段。

如果消费者的任务只是删除缓存，事件中带主键和版本即可；如果消费者要刷新缓存，则需要更多字段，并且必须确认这些字段来自同一事务快照。对于库存这种高风险数据，我更倾向于事件负责通知失效，缓存重建时再从可靠数据源读取。

3. 版本号是处理乱序的最后一道保险

假设版本 101 的事件先产生，版本 102 的事件后产生，但由于网络或队列调度，102 先消费、101 后消费。如果消费者没有版本判断，101 可能覆盖 102，系统就发生了“时间倒流”。

消费者的基本规则可以写成：

• 事件版本大于缓存版本：允许刷新或删除后重建。
• 事件版本等于缓存版本：视为重复消费，记录幂等成功。
• 事件版本小于缓存版本：拒绝覆盖，记录迟到事件。
• 事件版本无法解析：不要强行写缓存，进入异常队列。

删除动作本身没有“缓存版本”可比较，但可以把版本写入缓存元数据，或者在刷新前查询数据库当前版本。对于只做删除的消费者，版本主要用于监控和补偿判断；对于直接刷新缓存的消费者，版本是必须条件。

4. 三种策略的实际取舍

七、一个完整库存扣减案例：从请求幂等到缓存补偿

1. 业务背景与数据变化

下面用一个常见的仓储场景说明落地方式。某仓库中 SKU-A 的账面库存为 500，可用库存为 420，已预占库存为 80。订单确认需要预占 30 件，成功后可用库存应变成 390，预占库存变成 110，账面库存仍为 500。

这次操作不是简单地把一个 total_qty 减去 30。它包含库存状态迁移，也必须保留订单号、请求号、旧版本和新版本。缓存如果只存一个数量，后续很难判断它代表账面库存、可用库存还是订单可预占库存。

2. 请求进入数据库事务

服务收到 request_id 为 R-20260916-0001、业务单号为 O-10086 的预占请求。第一步不是写缓存，而是根据仓库、SKU、批次和库位定位库存记录，并获取当前版本 2057。

如果同一请求因为网络超时重试，服务应先根据 request_id 和业务单号查询流水表。如果第一次事务已经成功，就返回第一次处理结果；如果第一次事务处于处理中，则根据状态继续查询，而不是再次扣减。

随后执行带版本条件的更新。如果更新影响行数为 1，说明版本匹配且可用库存足够；如果影响行数为 0，则分别判断库存不足和版本冲突。这个判断要写进团队规范，不能统一返回“库存更新失败”，否则重试策略会变得不可控。

3. 同一事务写入流水与事件

库存主表更新成功后，服务在同一事务中写入库存流水，并生成版本为 2058 的同步事件。事件的 aggregate_id 可以是 owner_id、warehouse_id、location_id、sku_id 和 batch_no 的稳定组合。

事件 payload 不应只放一个“删除 Key”的字符串，还应包含事件类型、聚合主键、版本号和业务单号。这样出现异常时，运营人员可以根据事件记录定位具体库存，而不是依赖日志中一段难以检索的拼接文本。

{
"eventType": "STOCK_RESERVATION_CHANGED",

"aggregateId": "owner-7/warehouse-1/location-18/sku-1001/batch-B202609",

"eventVersion": 2058,

"bizNo": "O-10086",

"requestId": "R-20260916-0001",

"cacheKeys": [

"stock:warehouse:1:sku:1001",

"stock:location:18:sku:1001"

]

}

4. 事务提交后异步处理缓存

事务提交成功后，投递器发送事件。消费者收到事件后，可以删除仓库级库存缓存和库位级库存缓存。如果某个 Key 删除失败，不应影响其他 Key 的处理结果，也不应把整条事件直接标记为成功。

建议为每个缓存目标记录处理状态，或者把一个聚合事件拆成可独立重试的缓存任务。否则一个缓存 Key 持续失败会掩盖其他 Key 已经成功的事实，重试时也无法准确判断从哪里继续。

如果业务采用直接刷新缓存，消费者应先检查当前缓存版本。只有事件版本大于等于当前版本时才允许写入；如果当前缓存版本更高，则把本次事件记录为迟到事件，不要强制覆盖。

5. 用巡检发现消息链路没有发现的问题

即使消息系统有重试和死信，也建议对高价值库存做抽样巡检。巡检不需要每秒扫描全部库存，可以按仓库、SKU 热度、最近变更时间和异常订单进行采样。

巡检逻辑可以比较数据库主表的 version 与缓存中保存的 version。发现缓存版本低于数据库版本时，记录同步延迟；发现缓存数量与数据库数量不一致时，先判断缓存是否属于允许的延迟窗口，再决定自动删除还是人工介入。

八、数据观察：如何判断同步设计是否真的有效

1. 不要只看缓存命中率

缓存命中率高，只说明请求找到了缓存，并不说明缓存内容是最新的。一个被错误数据长期填充的缓存，命中率可能非常漂亮，但业务结果完全不可靠。

仓储系统至少要同时看四类指标：性能、时效、正确性和可恢复性。性能包括命中率、接口延迟和数据库回源量；时效包括事件消费延迟和副本追平延迟；正确性包括抽样比对差异和旧版本覆盖次数；可恢复性包括重试成功率、死信量和人工修复耗时。

2. 用 P99 而不是平均延迟确定补偿窗口

平均延迟适合观察整体性能，不能用来确定一致性补偿窗口。比如平均主从延迟只有 40 毫秒，但少量批量任务可能把 P99 推到 1.5 秒。如果延时双删只等待 100 毫秒，覆盖的只是大多数正常请求，最危险的高峰请求仍然暴露在窗口之外。

建议至少连续观察一周，分别记录主从复制、消息消费、缓存回填和删除任务的 P95、P99。然后在压测环境模拟批量入库、促销扣减、盘点调整和 Redis 重启，确认补偿策略不会因为单一延迟峰值失效。

3. 用故障注入验证，而不是只做正常链路测试

正常链路测试只能证明“服务都正常时能跑通”。缓存同步最容易出问题的时刻，恰恰是数据库提交成功后服务重启、消息重复、消费者暂停、只读副本延迟或缓存集群短暂不可用。

我建议上线前至少做以下故障注入：

• 数据库事务提交后立即终止应用进程，确认事件是否已经持久化。
• 让消息发送接口连续失败，确认事件是否进入重试并最终告警。
• 重复投递同一事件，确认库存不会重复扣减，缓存不会反复覆盖。
• 让旧版本事件晚于新版本事件到达，确认消费者拒绝旧版本覆盖。
• 让只读副本延迟超过正常窗口，确认敏感接口是否切换到可靠数据源。
• 删除缓存后并发回源，确认是否存在旧值回填和热点击穿。

测试结果不要只记录“通过”或“失败”。应记录触发条件、异常持续时间、自动修复时间、是否需要人工操作，以及数据库、缓存和事件表最终是否恢复一致。

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

1. 单体系统、单数据库、低并发商品资料

如果系统是单体应用，商品资料主要由一个服务维护，数据库没有明显主从延迟，缓存只用于商品名称、规格和图片，可以使用 Cache-Aside 加写库后删除缓存。

这类场景不必一开始就引入复杂消息队列。建议保留更新时间字段、删除失败日志和短周期巡检，先把缓存写入权限收敛到一个服务。TTL 可以作为兜底，但不要把 TTL 当成唯一同步方案。

• 优先保证实现简单和故障可见。
• 缓存失效失败时记录业务主键。
• 读请求回填使用主库或可接受的只读副本。
• 上线前测试数据库事务回滚和缓存删除失败。

2. WMS 与订单服务分离、库存变更频繁

当仓储服务、订单服务、采购服务和报表服务分别维护自己的读模型时，建议采用库存主表加流水表加 Outbox 事件表。数据库事务只负责确认库存事实，缓存和下游读模型通过事件异步更新。

此时应把库存聚合主键设计清楚，避免订单服务按 SKU 缓存、仓储服务按库位缓存、报表服务按仓库缓存，却没有统一的失效关系。一次库位库存变化，可能影响 SKU 总库存、仓库总库存和可用库存列表，事件应明确哪些读模型需要失效。

• 主表、流水和事件必须在同一事务提交。
• 消费者按聚合键实现幂等。
• 缓存值携带版本号或更新时间。
• 事件积压、死信和旧版本拒绝必须有监控。

3. 存在主从复制、读请求大量走副本

如果缓存未命中后的回源请求默认走只读副本，必须先确认业务是否允许读到旧值。商品资料和报表通常问题不大，库存可用量则要更谨慎。

可以采用分层策略：普通展示请求读缓存或副本；订单确认、库存扣减和拣货分配请求读取主库或调用专用库存接口；缓存重建敏感数据时优先使用主库。这样不必让所有查询都承担主库压力，也不会把高风险写操作交给旧缓存。

• 监控副本延迟的 P95 和 P99。
• 超过阈值时暂停敏感缓存回填。
• 在缓存中记录数据来源，便于故障定位。
• 不要用固定延时数字掩盖复制延迟波动。

4. 高峰期存在批量入库、盘点和促销扣减

这类业务的特点是短时间内大量更新同一批库存记录，消息积压、数据库锁等待和缓存热点会同时出现。此时应优先保证库存事务的正确性，再通过批量失效、事件合并和热点保护降低下游压力。

同一库存聚合在极短时间内连续产生多个版本时，可以在投递层做有限合并：只保留尚未投递的最新事件。但合并必须谨慎，不能跳过需要记录的业务流水，也不能让下游误以为中间的库存动作没有发生。

• 库存流水完整保留，事件传播可以按聚合做合并。
• 缓存刷新优先采用最新版本，避免重复回源。
• 热点 Key 设置互斥回填或请求合并。
• 对批量任务设置独立限流和消息优先级。

5. 团队规模小、暂时没有消息平台运维能力

如果团队没有可靠的消息队列、事件监控和死信处理能力，不建议为了“架构完整”强行引入异步链路。一个没有运维闭环的复杂方案，可能比简单但可观测的同步删除更危险。

可以先采用数据库事务加同步事件表，再由定时任务扫描失败和未处理事件，执行缓存删除。等事件量、跨服务需求和故障频率达到一定规模后，再替换为正式消息队列。关键不是一开始选最复杂的组件，而是先把事件记录和补偿思路建立起来。

十、不同方案的取舍：不要把“更复杂”误认为“更先进”

1. 低复杂度方案的优势与边界

写库后删除缓存的优势是代码少、链路短、故障面小。对于更新频率低、读请求不参与关键业务决策的数据，它往往足够可靠。

它的边界也很明显：删除失败需要额外记录，并发回填可能带来短暂旧值，跨服务同步需要新增通知机制。如果系统未来会拆分订单、仓储和库存服务，早期没有事件模型，后续补建会比一开始保留事件字段更困难。

2. 延时双删的优势与边界

延时双删不需要改变所有读取逻辑，适合在已有 Cache-Aside 体系上做增量加固。它能覆盖一部分旧值回填时序，部署成本相对较低。

但它依赖延时任务调度、数据库复制延迟和回填窗口判断。它不能证明数据库和缓存已经一致，也不能代替删除失败重试。对于库存核心链路，延时双删应该与事件表、版本号和巡检配合使用。

3. Outbox 加消息队列的优势与边界

Outbox 的最大价值是把“数据库已经发生的变更”持久化下来。消息队列不可用时，事件还可以在数据库中等待；消费者失败时，也能看到重试次数和错误原因。

代价是需要维护事件表、投递器、消息确认、幂等消费者、死信队列和监控告警。团队必须接受至少一次投递的现实，并在业务代码中处理重复和乱序，而不是把可靠性完全寄托给中间件。

4. 直接刷新缓存的优势与边界

直接刷新缓存可以减少缓存未命中和回源压力，适合读模型稳定、聚合计算昂贵、事件顺序可控的场景。比如库存列表经过多表聚合且计算成本高，异步刷新可能比每次删除后重建更省数据库资源。

但刷新要求消费者掌握完整的数据构造逻辑。如果事件只携带部分字段，消费者可能写入不完整对象；如果多个事件乱序到达，旧结果可能覆盖新结果。因此，刷新方案必须配合版本号、完整快照或可靠回源。

十一、团队上线操作手册：从建表到验收的执行顺序

1. 第一步：先画出业务对象和缓存 Key 的对应关系

不要直接从 Redis Key 开始设计。先列出库存的业务维度：货主、仓库、库区、库位、SKU、批次和库存状态，再确认每个查询接口使用哪些维度。

例如，warehouse:1:sku:1001 代表仓库级聚合，location:18:sku:1001 代表库位级明细，二者的数据来源不同、失效范围也不同。库位库存发生变化时，仓库级聚合缓存也可能需要失效。如果 Key 关系没有文档，新增接口很容易漏删某个聚合缓存。

• 为每种缓存对象定义唯一业务主键。
• 标明缓存内容对应的数据库表和字段。
• 标明哪些库存变化会影响该 Key。
• 标明缓存是删除、刷新还是只读。

2. 第二步：补齐版本、流水和请求幂等字段

表结构评审时，优先检查 version、updated_at、request_id、biz_no 和变更前后数量。如果这些字段缺失，先不要讨论消息顺序，因为系统根本没有足够信息判断顺序和重复。

版本号的生成方式要统一。可以采用数据库行版本递增，也可以使用业务序列，但必须保证同一库存聚合的版本单调递增。不同服务各自生成版本号，容易出现同一对象出现两个无法比较的版本。

3. 第三步：把事件写入放进同一事务

库存更新成功、流水写入成功、同步事件写入成功，三者必须作为一个事务结果对外可见。任何一个失败，都应该回滚整个库存变更，而不是让部分状态提交。

如果历史原因导致事件表无法与库存表放在同一个数据库中，应明确接受更高风险，并增加定时对账任务。不要把跨库写入包装成“已经具备事务一致性”，这会让团队在故障时产生错误判断。

4. 第四步：给消费者定义幂等和乱序规则

消费者文档中至少要写清楚四件事：如何识别重复事件、如何拒绝旧版本、删除失败如何重试、连续失败何时进入死信。只有写了这些规则，消息消费才算可运营。

删除缓存的消费者可以把“缓存不存在”视为成功，因为目标状态已经达到；刷新缓存的消费者则必须先比较版本。重复事件不应持续报高优先级错误，否则真正的删除失败会被大量幂等日志淹没。

5. 第五步：建立抽样巡检和人工修复入口

自动化系统也需要人工修复入口。修复命令至少要支持按照仓库、SKU、库位、批次和版本查询，并能执行定向删除或重新回填。修复操作必须记录操作者、原因、时间和修复前后版本。

不要允许运维人员直接在缓存服务器上手工删除一串 Key，却不在业务系统留下记录。直接删 Key 可能暂时解决展示问题，但无法说明为什么异常、影响了哪些订单、后续是否还会再次出现。

6. 第六步：设置上线验收指标

十二、故障排查：出现库存旧值时按证据链定位

1. 先确认数据库事实是否正确

收到“页面库存不对”的反馈后，第一步不是清空全部缓存，而是查询库存主表、库存流水和最近一次同步事件。先判断数据库事实是否正确，避免把业务扣减错误误判成缓存问题。

需要核对的字段包括仓库、SKU、库位、批次、available_qty、reserved_qty、version、updated_at 和 last_biz_no。随后查找最近一次库存流水的 before、change 和 after 数量，确认数量变化是否符合业务动作。

2. 再确认缓存版本和缓存来源

如果数据库版本是 2058，而缓存版本是 2057，说明缓存只是同步滞后；如果缓存版本是 2059，但数据库仍是 2058，就需要检查是否有绕过数据库的缓存写入、测试脚本或乱序事件。

如果缓存没有保存版本，至少要从缓存写入日志、事件消费日志和请求链路日志中还原。没有版本字段时，故障排查会明显依赖时间戳，而时间戳在多机房、时钟偏差和异步重试场景下并不总是可靠。

3. 判断是删除失败还是旧值回填

删除失败通常表现为缓存长期保留旧版本，且没有看到成功删除记录；旧值回填则常表现为缓存先被删除，随后又出现旧版本写入。两者的修复方向不同：前者要重试删除，后者要检查回源数据源、并发窗口和版本校验。

可以在缓存写入日志中记录 source、event_version、request_id 和 caller。这样可以知道究竟是事件消费者写入了缓存，还是某个查询接口直接回填了缓存。缓存写入来源不唯一，是很多系统难以治理的根因。

4. 最后决定自动修复还是人工修复

如果缓存版本低于数据库版本，且数据库事实已经确认无误，通常可以自动删除缓存并重新回填。如果缓存版本高于数据库版本，则不应盲目覆盖数据库或直接接受缓存，需要先检查非法写入和事件乱序。

如果库存已经影响订单履约，应把缓存修复和业务补偿分开处理。清理缓存只能修复读模型，不能自动修正已经错误确认的订单、拣货任务或出库单。涉及业务结果时，必须回到库存流水和业务单据进行核查。

十三、哪些数据不该放进缓存，哪些数据值得缓存

1. 不建议把库存扣减授权放在缓存中

缓存适合承载读取压力，不适合独立承担库存扣减授权，除非系统使用的是经过严格设计的原子库存组件，并且该组件本身就是库存事实服务的一部分。普通 Key-Value 缓存没有业务流水、订单幂等和事务回滚能力。

如果为了性能必须在缓存中执行预扣减，也要把它当成一个独立库存服务来设计：需要原子操作、预扣减流水、超时释放、数据库对账、失败补偿和订单状态关联。简单地对一个数字执行减法，不能称为可靠库存方案。

2. 值得缓存的是高频、可重建、读多写少的数据

商品基础资料、仓库配置、库位名称、库存展示摘要和权限范围等数据，通常具备高频读取、低频更新和容易重建的特点，更适合缓存。

对库存展示摘要，可以保存最近确认版本和更新时间，并在页面上区分“实时确认库存”和“展示库存”。这不仅有助于用户理解，也能减少业务方把缓存读数误认为扣减授权的风险。

3. 缓存对象的粒度不要过大

把整个仓库的库存列表放进一个大 Key，更新一个 SKU 就要删除或重建整份列表，会造成严重写放大和缓存抖动。把每个 SKU 的库存放成独立 Key，又可能增加批量查询的网络往返。

合理粒度需要结合访问模式：单 SKU 高频查询可以按 SKU 缓存；库位列表查询可以按仓库和分页维度缓存；报表则适合异步生成结果。表结构中的业务唯一键，应与缓存对象粒度保持可解释的对应关系。

十四、最终落地清单：团队可以直接拿去做评审

1. 表结构评审清单

• 库存记录是否有明确的业务唯一键？
• 是否区分账面、可用、预占和锁定库存？
• 是否有 version 或其他可比较的顺序字段？
• 是否记录更新时间、请求号和业务单号？
• 每次库存变化是否有独立流水？
• 流水是否记录变更前数量、变化量和变更后数量？
• 同步事件是否与库存主表在同一事务中提交？
• 事件是否具有唯一版本和可重试状态？

2. 缓存设计评审清单

• 缓存 Key 是否能反推出仓库、SKU、库位和批次范围？
• 缓存是只读、删除后重建，还是事件刷新？
• 缓存回填使用主库、只读副本还是专用库存服务？
• 缓存值是否保存版本和更新时间？
• 多个请求同时回填时是否有互斥或请求合并？
• TTL 是否基于业务容忍窗口和回源压力设置？
• 是否存在绕过数据库直接修改缓存的代码路径？

3. 消息与补偿评审清单

• 消息重复消费时是否不会重复扣减库存？
• 旧版本事件迟到时是否不会覆盖新缓存？
• 消息发送失败是否会重试？
• 超过重试上限后是否进入死信并触发告警？
• 删除多个缓存 Key 时是否支持单 Key 失败重试？
• 是否有按仓库、SKU、版本定向修复的工具？
• 是否有抽样巡检比较数据库与缓存版本？

4. 上线后的观察清单

• 关注缓存命中率之外的旧版本覆盖次数。
• 关注消息消费 P99，而不只是平均消费延迟。
• 关注主从复制长尾，而不只是平时复制状态。
• 关注死信数量和人工修复耗时。
• 关注缓存回填来源，识别是否有未授权写入路径。
• 关注库存异常是否已经影响订单、拣货和出库流程。

十五、结语：真正可靠的同步链路，应该允许失败但不能失去证据

仓储系统的缓存同步不可能因为增加一个 Redis 删除命令就变成绝对实时。数据库事务会失败，副本会延迟，消息会重复或乱序，缓存也会短暂不可用。工程设计的重点不是假设这些事情不会发生，而是让它们发生后仍然能够被发现、定位和修复。

我的建议是按风险分层建设：商品资料先采用简单的写库后失效；库存展示增加版本和回源策略；库存扣减以数据库事务或专用库存服务为事实边界；跨服务场景使用 Outbox 和幂等消费者；高并发回填再根据监控决定是否引入延时双删。

不要从“延迟双删还是消息队列”开始做方案，而要从“库存表能否表达版本、变化和待传播事件”开始做设计。当主表、流水表、事件表、缓存版本和补偿任务形成闭环时，缓存不一致就不再是无法解释的线上玄学，而会变成一个有状态、有指标、有处理入口的工程问题。

下一步可以从一个真实库存聚合开始：选定一个仓库和一个 SKU，画出数据库更新、缓存读取、事件投递和异常修复的完整时序；随后补齐 version、request_id、业务流水和同步事件表；最后用重复请求、消息乱序、主从延迟和缓存不可用四类故障注入验证。不要一次改造所有缓存，先把一个高价值库存链路做成可追踪、可补偿的样板，再复制到其他仓储数据对象。

UPDATE warehouse_stock SET available_qty = available_qty - :qty version = version + 1 updated_at = CURRENT_TIMESTAMP WHERE warehouse_id = :warehouse_id AND sku_id = :sku_id AND available_qty >= :qty;

免费注册

咨询方案

扫码咨询方案