缓存延迟双删的两种策略

策略A先删 → 更新 DB → 延迟再删经典版t1: 请求A 删除缓存 t2: 请求B 查缓存 miss读到旧值 t3: 请求A 更新 DB 完成 t4: 请求B 把旧值回填缓存 ← 脏数据 t5: 延迟 500ms 后再删缓存 ← 清理 t4 的脏数据解决的问题并发读在删和更新 DB之间发生把旧值写回缓存。策略B先更新 DB → 删缓存 → 延迟再删t1: 请求A 更新 DB新值 t2: 请求B 查缓存 miss读到新值 ← DB 已经是最新的直接命中新值 t3: 请求A 删缓存 t4: 延迟 500ms 再删缓存 ← 兜底防止 t5 回填解决的问题并发读在更新 DB之后发生如果缓存里还有旧值被命中回填时用新值覆盖即可。但实际上策略 B 里请求 B 读到的就是新值所以这个策略的价值主要体现在t1-t3 之间如果请求 B 读到了旧缓存值并回填t5 的第二次删除兜住某种程度上是冗余的因为策略 A 里的第一次删才是关键哪个更好策略 A删 → 更新 DB → 延迟删策略 B更新 DB → 删 → 延迟删第一次删/写的时机先删缓存先更新 DB并发读期间读到旧值但会被延迟删清掉新值因为 DB 已更新复杂性多一次远程 DB 读更简单DB 最新就行实用性经典方案解决明确简化版依赖更新 DB 后读到的就是新值策略 A 的问题是并发读在删缓存和更新 DB之间发生时读到旧值并回填需要延迟删来兜底。策略 B 实际上更简单——只要 DB 更新了后续的 Cache Aside 读本身就是新值。延迟双删的核心价值在于先删缓存这个动作阻断了并发读把旧值写回缓存的路径。结论策略 B 在某些场景下是有效的但策略A 才是延迟双删的标准写法因为它真正解决了删和更新之间的窗口问题。你在看的资料如果是策略 B可能是在简化实现——但要理解清楚它的前提假设DB 已更新后续读自然拿到新值。