Redis被动淘汰了，接下来到底该怎么应对和调整才好呢？

Redis的被动淘汰机制突然生效，这绝对是一个需要立刻重视的信号，它就像你家里的储物间，本来东西随便放，但突然有一天你发现，新买的东西放不进去了，因为空间满了，于是你不得不把一些旧东西扔掉才能塞进新的，Redis的被动淘汰就是这种情况：当内存用满时，新的写入请求会触发Redis强制删除一些已有的数据,以便腾出空间。

这听起来好像是Redis在“自动”帮你解决问题，但实际上，这是一个非常被动且后置的补救措施，往往会带来意想不到的麻烦，你可能发现一些重要的、本应常驻内存的热点数据被意外删除了，导致数据库压力瞬间增大，应用程序响应变慢甚至报错，我们的目标不是依赖这种被动的淘汰，而是要主动管理内存，让一切尽在掌握,我们就从几个切实可行的步骤来应对和调整。

第一步：立刻检查，搞清楚现状

当发现被动淘汰被触发时，先别慌，也不要急着去调参数，首先要像医生看病一样，先做“体检”。

1. 查看淘汰策略：通过Redis命令 CONFIG GET maxmemory-policy 看看当前设置的是什么策略，常见的策略有noeviction（不淘汰，直接报错）、allkeys-lru（从所有key中淘汰最近最少使用的）、volatile-lru（只从设置了过期时间的key中淘汰最近最少使用的）等,了解当前策略是分析问题的起点。
2. 分析内存使用：使用 INFO memory 命令，重点关注used_memory（当前内存使用量）和maxmemory（设置的内存上限）,看看内存是否真的已经用满或接近饱和。
3. 识别大Key和热点Key：内存过快耗尽，很可能是由少数几个“大Key”（比如一个List里存了几十万条数据）或者大量没有设置过期时间的“僵尸Key”导致的，可以使用redis-cli --bigkeys命令（生产环境慎用，可能阻塞）或者通过内存分析工具来找出这些“罪魁祸首”。

第二步：对症下药，采取核心调整措施

搞清楚状况后,就可以根据具体情况采取行动了。

1. 首要任务：设置一个合适的淘汰策略

   • 如果你的数据重要程度不一，有些可以丢，有些绝对不能丢：建议使用 volatile-lru 或 volatile-ttl 策略，前提是，你必须给那些可以丢弃的数据设置上过期时间（TTL），这样Redis只会在有TTL的Key里进行淘汰,保证了核心数据的安全。
   • 如果所有数据都可以根据使用频率来淘汰：可以使用 allkeys-lru，这是最常用的一种策略，它认为最近不被访问的数据就是“冷数据”,可以优先被清理掉。
   • 如果你的数据访问模式是周期性的，或者希望尽可能保留使用频率高的数据：可以考虑 allkeys-lfu（最不经常使用）,它会优先淘汰访问次数最少的数据。
   • 绝对不要轻易使用 noeviction：除非你非常确定当内存满时，宁愿让写请求失败也不能丢失任何数据（比如Redis纯粹用作只读缓存的情况很少见）,否则这会导致业务写入异常。

2. 根本大计：优化内存使用

   • 给Key设置过期时间：这是最重要的好习惯，就像给食物贴上保质期一样，对于缓存类数据，一定要预估其有效时间并设置TTL,让Redis可以自动清理。
   • 清理“僵尸Key”：检查那些没有TTL、但又长期不被访问的Key，通过扫描（可以使用SCAN命令非阻塞地进行）识别并清理它们。
   • 拆分大Key：如果发现了大Key，比如一个巨大的Hash或List，想办法把它拆分成多个小Key，比如一个用户的消息列表，可以按时间拆分成user:msg:2024-03，user:msg:2024-04等。
   • 考虑使用更节省内存的数据结构：比如用Hash代替多个独立的String Key；如果数据是数值型的，可以考虑使用Redis Module提供的Bloom Filter、Time Series等特定数据结构，或者使用ziplist、intset等内部编码优化（这部分涉及稍多细节，但值得研究）。

第三步：长远规划，建立预防机制

解决了眼前的危机,还要想着如何避免下次再发生。

1. 监控告警：这是最关键的一环，必须建立一个监控系统，持续监控Redis的内存使用率，设定一个阈值，比如当内存使用率达到80%或85%时，就发送告警（短信、邮件、钉钉等）,让你在内存被撑爆之前就有足够的时间介入处理。
2. 容量规划：根据业务增长趋势，定期评估Redis的内存需求，如果数据量持续增长，就要提前规划扩容，比如升级到更大内存的机器,或者采用Redis集群方案将数据分片到多个实例上。
3. 应用程序层面优化：检查代码，避免不必要的缓存写入，防止缓存“滥用”，确保写入Redis的数据都是必要的,并且大小是合理的。

总结一下

Redis被动淘汰是一个警告，而不是一个功能，我们的应对思路应该是：从被动响应转变为主动管理，具体行动路线是：立即检查（策略和内存诊断） -> 核心调整（设置合理策略、优化Key和TTL） -> 长期预防（建立监控告警和容量规划），通过这一套组合拳，你就能把Redis的内存管理权牢牢抓在自己手里,确保服务的稳定和高效。

（参考思路来源于常见的Redis运维最佳实践和官方文档中关于内存优化的建议）