缓存要怎么安全销毁啊，Redis缓存到底咋个销毁才靠谱呢？

说到缓存怎么安全销毁,尤其是Redis，这确实是个挺要紧的事儿，为啥呢？因为缓存这东西，它不是数据库，它是个临时工，干的就是快进快出的活儿，但很多时候，这个“临时工”手里攥着关键数据，你要是随随便便让它“消失”，比如直接断电或者执行一个FLUSHALL，那可能就跟在高速公路上突然给车熄火一样，后果很严重，轻则网站卡顿一下，重则可能引发连锁反应，导致服务雪崩，整个系统都瘫了。

咱们得聊聊怎么让这个“临时工”安全下岗，再换上新来的，这不叫销毁，更专业的说法叫缓存失效与缓存更新的策略，目标就一个：在不让用户感觉到卡顿、出错的前提下，把旧数据清理掉，让新数据能顶上去。

最忌讳的就是“一刀切”

你可能会想,这多简单啊，Redis不是有FLUSHDB（清空当前数据库）和FLUSHALL（清空所有数据库）命令吗？直接来一下，干干净净。（来源：Redis官方命令文档） 这绝对是下下策，除非是你个人在测试环境玩，或者公司服务器准备永久关机了，否则在生产环境千万别这么干，你想啊，一瞬间所有缓存都没了，这时候成千上万的用户请求涌进来，发现缓存全空了，只能全都绕到后面那慢吞吞的数据库里去查，数据库平时被缓存保护得好好的，哪见过这阵仗，CPU立马飙升，连接数爆满，响应速度慢如蜗牛，前端页面要么白屏，要么一直转圈圈，这就是典型的缓存穿透引发的雪崩效应。

那靠谱的办法有哪些呢？咱们一个一个说。

给缓存上个“闹钟”：设置过期时间（TTL）

这是最基本也是最有效的一招,在把数据写入缓存的时候，就直接给它设定一个存活时间，比如5分钟、1小时。（来源：常见的缓存设计模式） 时间一到，Redis会自动删除这个键值对，这样做的最大好处是“平滑”，每个key的过期时间是分散开的，不会在同一时刻全部失效，对数据库的压力是均匀的，避免了雪崩。

但这里也有个坑要注意,如果你一大批key是在同一时刻被创建的，又设置了相同的TTL，那它们就会在同一时刻集体失效，设置TTL时最好加个随机数，比如基础过期时间是1小时，然后加上一个几分钟的随机值，让失效时间点稍微错开一些。

“延时下班”策略：惰性删除配合定期清理

其实Redis本身就很聪明,它用了两种方式来管理过期key，一种是惰性删除，就是当某个key被访问时，Redis才会检查它是否过期，如果过期就当场删除。（来源：Redis内存优化官方文档） 另一种是定期删除，Redis会每隔一段时间随机抽查一些key，清理掉已经过期的，这两种方式结合，既保证了效率，又能及时回收内存，但这主要针对的是设定了TTL的key。

有新来的，就让旧的走人：主动更新策略

很多时候,缓存失效是因为后台数据变了，比如管理员在后台修改了商品价格，你肯定希望前台页面立刻显示新价格，而不是等缓存自然过期，这时候就需要主动出击。

• 先更新数据库，再删除缓存（Cache-Aside Pattern）：这是最常用、最被推荐的做法。（来源：分布式系统缓存经典模式） 流程是：当数据发生变更时，首先去把数据库更新成功，然后立刻把Redis里对应的缓存键删掉，这样，下一个来读数据的请求，发现缓存里没有（这叫缓存未命中），就会自己去数据库查出新数据，然后顺手再塞回Redis里，这个模式简单有效，能很好地保证数据一致性，虽然在一个极短的时间窗口内（删除缓存后、新数据被读回前），可能存在数据不一致，但概率很低，对业务影响通常很小。

• 消息队列通知：在复杂的系统里，数据变更可能来自不同的服务，为了解耦，可以采用消息队列，比如一个服务更新了数据库后，就往消息队列里发个消息：“某个商品ID的数据变了”，然后有一个专门负责缓存的服务监听这个消息，一收到就去删除对应的缓存，这样各司其职，更稳妥。

• 先更新缓存还是先更新数据库”的争论：除了上面说的“先更数据库再删缓存”，也有人讨论“先更新缓存再更新数据库”，或者“先删除缓存再更新数据库”，但这些方式问题更多，先删缓存再更数据库”，在高并发下很容易导致脏数据被读回到缓存里。“先更新缓存再更新数据库”则可能因为数据库更新失败导致缓存是脏数据，综合来看，“先更新数据库，再删除缓存”是毛病最少的方案。

处理“刁钻”的删除情况

你想删除的不是某一个具体的key,而是某一类有共同前缀的key，比如所有product:1001:开头的key，Redis本身不支持按前缀模糊删除，但你可以用SCAN命令先扫描出所有匹配的key，然后再逐个删除。（来源：Redis键空间遍历官方文档） 但要注意，这个操作如果key很多会比较耗时，最好在业务低峰期用脚本执行，别在线上高峰期搞。

总结一下到底咋个才靠谱：

• 核心原则：避免一次性、大规模的无差别删除，保护数据库，保证服务平稳。
• 日常用法：给绝大多数缓存数据设置一个合理的、带有随机波动的TTL，让Redis自己去管理失效。
• 应对数据变更：采用“先更新数据库，再删除缓存”的策略，简单直接，复杂系统可以用消息队列来解耦。
• 批量清理：使用SCAN命令结合删除操作，并在低峰期执行。

缓存销毁（失效）不是目的，目的是为了让系统能无缝衔接地使用上新数据，一切操作都要围绕着“用户体验无感知，系统运行无压力”这个中心思想来转，千万别图省事，那一下FLUSHDB按下去，可能就得准备熬夜处理故障了。