直接回答：Cache Aside（旁路缓存，最常用）：读——先查缓存 miss 回源 DB 再回填；写——先更新 DB 再删除缓存。Read/Write Through 把缓存层做成数据访问代理：应用只面对缓存，缓存组件负责回源与写穿透（DB 仍是主，适合读多写多且能接受缓存层复杂度）。Write Behind（回写）：写只落缓存即返回，异步批量刷 DB——吞吐最高但宕机丢数据窗口，用于计数、排行榜这类可重建数据。

展开解析：Cache Aside 的经典一致性问题：更新 DB 与删除缓存之间，并发读可能把旧值回填——“先更库后删缓存”把不一致窗口压到一次读回源的耗时，配合“延迟双删”（更新 DB 后先删一次，隔几百毫秒再删一次，兜住窗口内并发读回填的旧值）或“binlog 订阅异步删”（Canal 类，可靠性更高，工程界大流量场景的主流）。反过来“先删缓存再更库”的窗口大得多（整个写事务期间），不推荐。还要明确这些模式的边界：它们保证的是最终一致不是强一致，强一致诉求要么不走缓存、要么接受分布式锁的吞吐代价。细节加分项：删除而非更新缓存（更新缓存在并发写下顺序难保证，且复杂对象算一遍浪费）；回填加较短的随机 TTL 防缓存雪崩与热点常驻；穿透用空值缓存/布隆过滤器，击穿用互斥回源（singleflight），三者别混。

追问方向：为什么用删除缓存而不是更新缓存？binlog 方案与延迟双删如何取舍？

（约 480 字）