Redis里那些旧键清理了，系统才会活过来，别让缓存拖后腿

（根据“阿里技术”公众号一篇关于Redis内存优化的文章，以及多位一线运维工程师的经验分享整理）

你有没有遇到过这种情况？服务器监控大半夜突然报警，CPU使用率飙升，网站打开慢得像蜗牛，甚至直接报错“服务不可用”，一群人火急火燎地查了半天，最后发现根源既不是代码bug，也不是流量暴增，而是那个平时默默无闻的Redis——它的内存，不知道在什么时候，已经被塞得满满当当了。

这时候,Redis就不再是那个提升性能的“加速器”了，它瞬间变成了整个系统的“拖油瓶”，它会开始疯狂地折腾自己，试图腾出一点空间来，这个过程，我们俗称为“旧键清理”，如果清理不及时或者清理不掉，系统可就真的“活”不过来了。

为什么缓存满了会这么要命？

你可以把Redis的内存想象成一个超级市场货架,刚开始的时候，货架空荡荡的，新来的商品（数据）可以整整齐齐地摆上去，顾客（应用程序）来取货（读取数据）也特别快，但随着时间推移，货架越来越满，新商品来了没地方放，超市管理员（Redis）就得干两件事：

1. 淘汰旧货（键淘汰）：根据一定的规则（比如扔掉卖得最少的，或者摆放时间最长的），把一些商品清下架，腾出位置，这个“找旧货、扔旧货”的过程是需要花时间和力气的，当内存压力巨大时，Redis可能要把大部分精力都用来做这件事，自然就没空好好处理正常的“顾客请求”了，导致响应变慢。
2. 拒绝新货（写入失败）：如果管理员忙不过来，或者规定了“货架满了就不能再上新”，那么新的商品就会被拒之门外，对应到系统里，就是用户下单、发表评论等需要写入缓存的操作全部失败，直接影响核心业务。

更糟糕的一种情况是,货架上堆满了再也无人问津的“僵尸商品”（比如一场促销活动结束后，相关的缓存数据已经完全没用了），这些僵尸商品占着宝贵的货架，让管理员在清理时非常头疼，效率极低。

哪些“旧键”是我们要优先清理的目标？

想让系统“活过来”，关键在于精准地清理掉那些该清理的键，而不是盲目地删数据，以下几类键是典型的“拖后腿”大户：

1. “僵尸键”或“幽灵键”：这是最大的元凶，指的是那些曾经有用（比如为某个临时活动服务）、但活动结束后就再也不会被访问的键，它们占据了大量内存，却毫无价值，这种键只能通过业务逻辑来分析发现，比如定期扫描那些长时间没有访问记录、但体积巨大的键。（来源：某电商平台运维团队的事后总结报告）
2. “巨无霸”键：有些键本身存储了过大的数据，比如一个List里塞了几十万条记录，或者一个String键存储了几兆的JSON字符串，当Redis需要淘汰数据时，操作一个大键的代价远高于操作一堆小键，一旦需要清理这种“巨无霸”，可能会引起短暂的性能抖动，让已经不堪重负的系统雪上加霜，最佳实践是将大键拆分成多个小键。
3. TTL设置不合理的键：有些键虽然设置了过期时间（TTL），但可能设置得过长，比如一些用户会话信息，可能设置了7天过期，但实际上用户活跃周期只有一天，这些键在过期前会一直占着内存，需要根据业务实际情况，合理缩短TTL。

如何避免下次再被“拖后腿”？

临时救火之后,更重要的是建立长效机制。

• 设定合适的内存淘汰策略：这是Redis提供的自救机制，不要使用默认的 noeviction（不淘汰，只报错），而应根据业务特点选择，如果都是缓存数据，丢了可以重新从数据库加载，allkeys-lru（淘汰最近最少使用的键）是个好选择，如果想保住一部分重要数据，可以选择 volatile-lru（只淘汰设置了过期时间的键中最近最少使用的）。
• 监控与预警：给Redis的内存使用率设置明确的警戒线（比如80%），一旦触发预警，就立刻着手分析，而不是等到100%了才手忙脚乱，监控关键指标，比如键的个数、内存碎片率、淘汰键的数量等。
• 定期“大扫除”：像前面提到的，定期通过脚本扫描并清理那些“僵尸键”，这应该成为一个固定的运维流程。
• 代码层面优化：开发人员要养成良好的缓存使用习惯，避免存储过大的数据，给缓存数据设置合理的过期时间，并及时清理无效缓存。

Redis是个宝贝,用好了能让系统飞起来；但要是疏于管理，让它被陈年老键“堵”住，它立马就能让系统瘫痪，定期给Redis“减负”，清理掉那些不再需要的缓存，绝不是可有可无的优化，而是保证系统稳定性的生命线，别等到报警响了才想起来，平时就该多关心一下这个默默奉献的伙伴。