缓存一致性：从更新兜底到多级防线的工程实践

缓存是性能的银弹，一致性是缓存的宿命。但凡用过缓存的系统，都被「数据库改了、缓存还是旧值」支配过。这篇把缓存一致性的方案按演进顺序排开——从非常朴素的用到今天的多级防线，重点讲每层方案防什么、防不住什么。

阶段一：先说非常常用的两个姿势的对与错

先更新数据库再删缓存（Cache-Aside）：主流默认方案。优点是简单、多数场景够用；漏洞是「删了缓存之后、下一次加载之前」的窗口期读旧值，以及删除失败时的永久不一致（解法：删除重试队列）。

先删缓存再更新数据库：看似对称，实则有并发陷阱——删除后、数据库更新前，另一个请求把旧值又加载进缓存，之后数据库更新完成，缓存里那份旧值成了孤儿。这个方案只适合写多读少且能容忍分钟级不一致的场景。

结论：没有一劳永逸的方案，只有明确的不一致窗口 + 补偿机制。

阶段二：缩短窗口的三个手段

1. 延迟双删：更新数据库后，延迟几百毫秒再删一次缓存（清掉并发窗口期进来的旧值）。延迟取「一次读请求的典型耗时」，不精确但有效。
2. 删除重试：缓存删除失败进消息队列异步重试，兜住「永久不一致」的下限。
3. 短 TTL 兜底：缓存设置较短的过期时间（分钟级），把非常坏情况的不一致时长封顶。这是所有方案的「保险丝」——前面全失效，TTL 保证错误有涯。

阶段三：强一致需求的另起炉灶

以上都是「非常终一致」。业务真的要求强一致（库存扣减、余额）时，正确答案不是把缓存修到强一致（等于放弃缓存的性能意义），而是架构分流：

• 强一致路径：绕过缓存直读数据库（或用分布式锁串行化关键读写）
• 高性能路径：走缓存，接受短暂不一致

把「哪些数据必须强一致」圈出来（通常不到 5%），剩下 95% 用非常终一致——这个分类决策比任何缓存技巧都重要。

阶段四：多级缓存的防线叠加

现代系统的缓存通常不止一层（本地缓存 → 分布式缓存 → 数据库），一致性要每层都设防：

• 本地缓存：非常短 TTL（秒级）+ 变更广播失效（多实例间的本地缓存靠消息通知互相失效）
• 分布式缓存：阶段二的完整方案
• 预防层：缓存击穿保护（热点 key 过期瞬间的并发回源，用互斥重建或逻辑过期）

观测：不一致是会被度量的

埋一个「数据版本比对」探针：抽样比对缓存值和数据库值的时间戳，不一致率做成分位数指标。没有这个指标，缓存健康度全靠用户投诉反馈；有了它，方案演进的效果可量化。

总结成一张决策表

• 能容忍秒级不一致：Cache-Aside + TTL 兜底，收工
• 分钟级不能容忍：+延迟双删 + 删除重试
• 强一致：分流架构，关键数据不走缓存
• 多级缓存：每层独立设防 + 广播失效

缓存一致性这个话题的尽头不是「消灭不一致」，是「把不一致管理在业务无感的范围内」——工程的美感从来在于恰好够用。

（服务端工程系列：网关限流 → 熔断降级 → 配置治理 → 灰度闭环 → 本文：缓存一致性）

发布记录

• 10-17 发布操作后 3 天（10-17/18/19）creator 列表与搜索均无此文 → 判定未发布成功（write 页无跳转的假成功）；明日（10-20）班重灌此稿让用户补点（腾讯云今日已发版本治理，不冲突）
• A 级，服务端工程系列