Cache Aside策略写入后：删除还是更新缓存？

在Cache Aside的写入流程中，写完数据库后选择删除缓存（方案A）还是更新缓存（方案B），核心差异聚焦在一致性风险、资源开销、读取性能这几个维度，具体优缺点如下：

方案A：删除对应缓存条目 #

优点 #

• 规避数据不一致风险：如果DB写入成功但缓存更新失败（比如Redis网络超时），直接删除缓存的话，后续读取会自动从DB拉取最新数据重建缓存；而更新缓存的话，就会留下旧数据直到TTL到期。这是删除缓存最核心的优势。
• 减少无效资源消耗：如果某条数据写入后长期无人读取，更新缓存就是做无用功——既占Redis内存，又浪费计算资源。删除缓存只有在数据被实际读取时才会触发缓存重建，更高效。
• 适配复杂缓存场景：如果缓存存储的不是单条DB记录，而是多表聚合、统计计算后的结果（比如用户的订单总金额），每次写入都重新计算并更新缓存成本极高；删除缓存后，下次读取再按需计算，逻辑更简单。

缺点 #

• 可能触发缓存击穿：热点数据被删除后，瞬间大量请求会直接打到DB，导致DB压力骤增。虽然可以通过加互斥锁、异步预热等方式缓解，但会增加系统复杂度。
• 首次读取延迟升高：删除缓存后的第一次读取，需要先从DB加载数据再写入缓存，相比直接读缓存会有明显的延迟，尤其是数据量大或需要复杂计算的场景。

方案B：更新对应缓存条目 #

优点 #

• 读取性能稳定可控：只要缓存更新成功，在TTL到期前所有读取都能直接命中缓存，不会出现加载DB的额外延迟，适合对读取响应速度要求极高的场景。
• 无缓存击穿风险：热点数据始终驻留在缓存中，不会出现大量请求同时打DB的情况，DB负载更平稳。

缺点 #

• 数据不一致隐患：DB写入成功但缓存更新失败时，缓存会保留旧数据，直到TTL到期（如果没设置TTL，旧数据会一直存在）。虽然可以通过重试机制缓解，但会增加写入流程的复杂度。
• 无效更新浪费资源：对于写入频繁但读取极少的冷数据，每次写入都更新缓存纯粹是浪费Redis的内存和CPU，完全没必要。
• 复杂缓存场景成本高：如果缓存内容需要多表关联、复杂运算生成，每次写入都重新计算并更新缓存，会大幅增加写入操作的耗时，拖慢整个写入链路的性能。

选型建议 #

• 大多数通用场景优先选方案A（删除缓存）：能平衡一致性、资源开销和实现复杂度，是行业内的主流选择。
• 仅在写入频率低、读取量极大的热点简单数据场景下考虑方案B：比如首页的热门商品信息，此时读取延迟要求高，且缓存内容直接对应DB单条记录，能接受极小概率的不一致风险（配合TTL兜底即可）。

内容的提问来源于stack exchange，提问作者Maxx