何时执行Cache invalidation？其是否仅用于修复缓存数据不一致？

嘿，这个问题问得特别到位——不少刚接触缓存的同学都会误以为失效只是用来“擦屁股”的补救操作，但实际上它是缓存策略里的核心环节，用途远不止你想的那样！

一、什么时候需要执行缓存失效？ #

我把常见场景分成主动设计和被动/补救两类，你一看就明白：

• 数据源主动更新时（最核心的主动场景）
  比如你修改了数据库里的用户头像、商品库存，这时候如果缓存还存着旧数据，用户拿到的就是过时内容。这时候必须主动触发失效——比如在更新数据库的代码逻辑里，同步调用DEL user:123:avatar这类删除缓存键的操作，或者标记缓存为过期。这完全是正常业务流程的一部分，不是补救。
  举个实际例子：用户提交了昵称修改请求，后端写完数据库后，立刻删掉对应的缓存条目，下次用户请求昵称时，就会从数据库拉取新数据再重新缓存，这是主动保证数据一致性的标准操作。

• 缓存数据自然过期（被动但常规的场景）
  有些场景下你没法精准捕获数据源的更新（比如数据源是第三方天气API，或者数据更新频率低但不确定），这时候会给缓存设置TTL（生存时间），到时间自动失效。比如把天气数据缓存1小时，到点自动失效，重新拉取最新数据——这也是一种失效策略，是提前设计好的，和补救完全不沾边。

• 发现缓存与数据源不一致时（真正的补救场景）
  就像你提到的，比如因为网络故障、代码bug，导致数据库更新了但缓存没同步，这时候发现后需要手动或自动触发失效来修复不一致。这属于补救，但只是其中一种小众场景。

• 缓存空间不足时（资源管理场景）
  当缓存服务器内存不够用了，会按照预设的淘汰策略（比如LRU最近最少使用）自动失效部分缓存条目，释放空间。这时候的失效是为了保证缓存系统的可用性，和数据一致性无关，纯粹是资源管理的需求。

二、为什么需要缓存失效？ #

核心原因其实就两个：

1. 保证数据一致性：缓存的价值是加速读取，但如果返回的是过时数据，反而会伤害业务（比如用户看到错误的商品价格、账户余额），失效是让缓存和数据源对齐的关键手段。
2. 优化缓存资源利用率：缓存空间是有限的，把没用的、过时的数据清掉，才能给更常用的新数据腾位置，避免缓存命中率下降——命中率一旦低了，缓存就失去了加速的意义。

三、它是不是仅作为补救措施？ #

当然不是！绝大多数情况下，缓存失效是主动设计的缓存策略核心：

• 写操作后主动失效缓存，是“写失效+读回源”模式的标准流程；
• 设置TTL自动失效，是应对不确定更新场景的常规方案；
• 基于LRU的自动淘汰，是缓存系统自带的资源管理机制。

补救场景只是极端情况（比如出现bug、异常）下的补充，完全不是它的主要用途。

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