sql缓存一致性需应用层主动设计，推荐写后失效策略（先更新 DB 再删缓存），避免先删缓存后更新 DB；读多写少场景宜用 懒加载 ，高一致性需求可预热缓存； 并发 下可用 分布式 锁、版本号或 MQ 保障顺序；需建立比对、告警、手动刷新等兜底机制。
SQL 缓存一致性不是靠 数据库 自动解决的，而是由应用层结合缓存策略主动设计和控制的。核心矛盾在于：数据库改了，缓存没同步，用户就可能读到旧数据；而盲目删缓存或强刷缓存，又可能引发性能抖动或并发问题。关键是要在「及时性」和「可用性」之间找平衡。
缓存失效策略：什么时候删缓存？
最常用、也最稳妥的做法是「写后失效（Cache-Aside + delete on Write）」：先更新数据库，再删除对应缓存 key，下次读请求自然触发回源加载新数据。
- ✅ 推荐用于大多数业务场景（如商品信息、用户资料）
- ⚠️ 注意：删除失败需有补偿机制（如 异步 重试、日志告警），否则缓存永久脏化
- ❌ 避免「先删缓存再更新 DB」——中间若 DB 更新失败，缓存空了，后续读会误加载旧值（因为旧数据还在 DB 里）
缓存更新策略：什么时候写缓存？
不建议直接「写缓存 + 写 DB」双写，极易因网络、顺序、异常导致不一致。更可控的方式是「只删不写」，让读请求按需重建缓存（Lazy Load）。
- ✅ 读多写少场景下，延迟加载 天然降低写压力，且避免无效缓存 堆积
- ⚠️ 若对首次读延迟敏感（如首页强一致性），可搭配「更新 DB 后主动预热缓存」（但要确保预热逻辑幂等）
- ❌ 不要依赖定时任务批量刷缓存——无法感知实时变更，滞后高，还可能刷错版本
应对并发写：防止缓存与 DB 错乱
当多个 线程/ 服务同时修改同一条记录时，删缓存和更新 DB 的顺序可能被交叉执行，导致脏数据残留。常见防御手段：
- 加分布式锁（如redis SETNX）控制同一 key 的写操作串行化，适合变更频次不高、key 粒度适中的场景
- 引入版本号或时间戳字段，在更新 DB 和删缓存时一并校验，丢弃过期写请求
- 使用「更新 DB + 发送 MQ 消息」解耦，由消费者统一处理缓存删除，天然具备重试和顺序保障能力
兜底方案：如何发现并修复不一致？
再严谨的设计也无法 100% 杜绝异常。需要建立可观测性和自愈能力：
- 对核心缓存 key 做定期比对（如抽样查 DB 和 redis 的值是否一致），发现问题自动告警
- 提供运营后台的「强制刷新缓存」按钮，支持人工干预
- 在关键读 接口 增加「一致性校验开关」，开启时主动比对缓存与 DB，不一致则自动更新缓存并上报
不复杂但容易忽略。真正决定一致性的，从来不是缓存 工具 本身，而是你对数据流的理解和对异常路径的敬畏。
