Redis缓存清理那些事儿，怎么操作才算靠谱又有效呢？

Redis缓存清理那些事儿,怎么操作才算靠谱又有效呢？

说到用Redis，大家图的就是个快，但内存空间是有限的，不可能无限制地往里塞数据，所以缓存清理就成了一个绕不开的话题，这事儿听起来简单，不就是删数据嘛，但要是操作不好，轻则影响系统性能，重则可能导致服务雪崩，直接挂掉，咱们今天就来聊聊,怎么清理Redis缓存才算靠谱又有效。

咱得明白Redis自己是怎么管理内存的，Redis内置了几种主要的清理策略，也就是所谓的“淘汰策略”，你可以把它想象成仓库的管理员，当仓库快满的时候，他得决定把哪些货物先清出去，根据Redis官方文档（来源：Redis官方文档关于maxmemory-policy的说明）,常见的策略有这么几种：

1. noeviction：这是默认策略，当内存不够时，新写入的数据会报错，原有的数据一概不动，这听起来很“霸道”，适合你非常确定某些核心数据绝对不能丢的场景,但风险就是写操作可能会失败。
2. allkeys-lru：这是最常用、也往往是最推荐的策略，LRU是“最近最少使用”的意思，这个策略会尝试淘汰掉所有键中，最近一段时间被使用得最少的那些，这很符合缓存的直觉：把长时间没人用的“冷数据”清掉，给“热数据”腾地方。
3. volatile-lru：这个策略只针对那些设置了过期时间（TTL）的键，从中淘汰最近最少使用的，如果你把Redis同时用作缓存和持久存储（一部分数据永不过期）,这个策略就比较合适。
4. allkeys-random：简单粗暴，从所有键里随机挑一些淘汰，这听起来不靠谱，但在某些访问模式非常均匀的场景下,也可能有奇效。
5. volatile-random：同理,只在设了过期时间的键里随机淘汰。
6. volatile-ttl：这个策略优先淘汰那些过期时间最短的键，这有点反直觉，但想想看，快过期的数据反正也要没了,不如提前清掉腾空间。

怎么选才算靠谱呢？对于绝大多数纯缓存场景，allkeys-lru 通常是安全且有效的选择，它能自动帮你维护一个相对“热”的数据集，如果你混合使用了缓存和持久化数据，volatile-lru 可以保护你的持久化数据不被误删。

光选好策略还不够，有时候我们还需要主动出击，进行手动清理，比如产品下线了，某个功能模块需要重构，对应的缓存数据就得批量清理，这时候,手动操作就得讲究方法了。

*最不靠谱的操作就是直接在线上环境执行 `keys ` 命令！** 这个命令会一次性列出所有的键，如果你的Redis里存了几千万甚至上亿个键，这个操作会长时间阻塞Redis的单线程，导致所有其他请求全部卡住，服务瞬间不可用,这简直就是一场灾难。

那应该怎么做呢？正确的手动清理姿势是使用 SCAN 命令配合 DEL 命令，根据Redis最佳实践（来源：Redis官方文档关于SCAN命令的说明），SCAN 命令是一个增量式的迭代命令，它不会一次性锁住整个数据库，而是分多次遍历，每次只返回一小部分键，这样即使是在处理海量数据,对服务器的影响也是微乎其微的。

具体的操作流程大概是这样的：

1. 先使用 SCAN 命令，根据匹配模式（user_cache:*）分批扫描出需要删除的键。
2. 对于每一批扫描到的键，再使用 DEL 命令逐个删除，如果一批键很多，也可以考虑使用 UNLINK 命令代替 DEL。UNLINK 是Redis 4.0之后提供的异步删除命令，它会把删除任务丢到后台线程去执行，能更快地释放主线程,对性能的影响更小。
3. 循环执行步骤1和2，直到 SCAN 命令返回的游标为0,表示遍历完成。

除了这种按模式匹配的清理，还有一种情况是缓存预热出了问题，或者遇到了缓存污染（比如突然有大量非热点数据涌入），导致缓存命中率急剧下降，这时候，一个更“狠”的操作是执行 FLUSHDB（清空当前数据库）或 FLUSHALL（清空所有数据库），但这绝对是一个高危操作，必须极其谨慎！除非是在业务低峰期，并且你有完善的预案（比如立刻可以从数据库或其他地方快速重建缓存），否则不要轻易使用，即使要用，也优先考虑使用 FLUSHDB ASYNC 这种异步方式,以减少对服务的冲击。

Redis缓存清理要想靠谱又有效，核心在于“自动化”和“精细化”。

• 自动化：依靠配置合理的自动淘汰策略（如allkeys-lru）,让Redis自己能从容应对常规的内存压力。
• 精细化：在需要手动干预时，摒弃粗暴的 keys *，采用 SCAN + DEL/UNLINK 这种对服务影响最小的方式,像外科手术一样精准地清除目标数据。

记住一个原则：任何清理操作，尤其是手动操作，最好在测试环境充分验证，并在生产环境的业务低峰期进行，同时做好监控和回滚预案，这样才能在享受Redis高速缓存带来的便利的同时，避免清理缓存这件“小事”变成压垮系统的“大事”。