直接回答

严格强一致性在缓存+DB 双写场景下成本极高，工程上追求最终一致性。主流方案是 Cache Aside（旁路缓存）：读时先查缓存、未命中查 DB 并回写；写时先更新数据库，再删除缓存（是删除不是更新，避免并发下写入旧值且懒加载更省）。

展开解析

为什么是"先更新 DB，再删缓存"而不是反过来：先删缓存再写 DB 时，若在 DB 写完前有并发读进来，会把旧值重新回填缓存造成长期不一致；而先写 DB 再删缓存，不一致窗口只有"删缓存前的读"这一段，概率小得多。但删缓存失败仍会不一致，需兜底：

  • 重试机制：删除失败进消息队列/本地表异步重试。
  • 订阅 binlog：通过 Canal 等监听 MySQL binlog，异步删缓存，把缓存失效和业务代码解耦，天然带重试。
  • 延迟双删：先删缓存 → 更新 DB → 延迟一段时间再删一次缓存，清理窗口期内被回填的旧值（延迟时长依赖经验，不够严谨）。

其他补充：给缓存设较短 TTL 作为最终兜底；强一致场景可用分布式锁把读写串行化，或干脆只读 DB。

追问方向：为什么不用"更新缓存"代替"删除"（并发写覆盖、冷数据白算）、读写串行化方案的吞吐代价。