Redis等缓存采用TTL失效与主动删除key的方案各有什么优劣？

两种缓存失效方式的优缺点对比 #

TTL自动失效 #

优点：

• 实现成本极低：只需要在写入缓存时设置过期时间，后续无需额外业务逻辑介入，适合无强一致性要求的场景
• 天然避免缓存永久残留：即使业务逻辑出现疏漏，未主动处理脏缓存，到期后也会自动清理，不会长期占用内存
• 缓存集群负载稳定：过期清理逻辑由缓存服务端内部调度，不会产生额外的业务侧删除请求峰值
  缺点：
• 缓存一致性差：数据更新后，旧缓存会一直保留到TTL到期，期间会返回脏数据，不适合对数据一致性要求高的业务
• 内存利用率低：大量已经无效的key在到期前会持续占用缓存内存，缓存容量紧张时会挤占有效数据的存储空间
• 可能出现缓存雪崩：如果大量key的TTL设置接近，到期时会同时失效，导致请求集中打到底层数据库，引发服务雪崩

主动删除key #

优点：

• 缓存一致性高：数据更新后立刻删除对应旧缓存，后续请求就能拿到最新数据，能满足绝大多数一致性要求的场景
• 内存利用率高：无效数据会被立刻清理，不会长期占用缓存内存，缓存空间可以被有效利用
• 灵活性强：可以根据业务场景灵活决定删除时机，不需要被固定的TTL限制
  缺点：
• 实现成本高：需要在所有涉及数据更新的业务逻辑中嵌入缓存删除逻辑，一旦有遗漏就会出现脏缓存长期存在的问题
• 可能出现误删风险：业务逻辑异常或者并发场景处理不当，可能会误删有效缓存，甚至出现缓存和数据库永久不一致的问题
• 会产生额外的请求开销：每次数据更新都要额外发送删除请求到缓存服务，高并发更新场景下会增加缓存服务的请求量

Redis缓存key失效的常见最佳实践 #

绝大多数业务场景优先采用「主动删除+兜底TTL」的组合策略，既能保证数据更新后的一致性，又能避免业务逻辑遗漏删除导致的脏缓存永久残留，除此之外还有以下可落地的实践规则：

• TTL设置要合理：避免所有key使用相同的TTL，可以在基础过期时间上增加随机偏移量，防止大量key同时过期引发缓存雪崩；同时TTL不能设置过长或过短，过长会导致脏数据存留时间久、内存浪费，过短会导致缓存命中率太低
• 高并发场景下的主动删除要做优化：如果同一时间有大量相同key的删除请求，可以做请求合并，减少重复请求发送到Redis；对于非核心业务的删除操作，可以采用异步删除的方式降低业务链路的耗时
• 大key删除用异步释放：Redis 4.0+版本支持UNLINK命令替代DEL命令删除大key，不会阻塞主线程，对缓存性能影响极小
• 避免短时间内大量删除key：如果需要批量清理过期key，可以分批次慢量删除，避免一次性请求过多导致Redis阻塞

主动删除对缓存负载的影响说明 #

正常场景下的主动删除操作不会对缓存吞吐量造成明显影响，原因如下：

Redis的删除请求本身是O(1)操作，处理耗时极短，常规业务场景下的删除请求量远低于缓存读取请求量，占整体请求的比例极低，不会成为性能瓶颈
只有当出现以下极端场景时才可能影响吞吐量：

• 短时间内发起十万级以上的批量删除请求，占整体缓存请求的比例超过30%
• 使用DEL命令删除体积超过100MB的大key，导致Redis主线程阻塞
  这种情况下只要优化删除逻辑，采用异步删除、分批次删除、请求合并的方式，就能完全规避性能影响。

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