Redis内存满了，警告来了，赶紧清理别让服务崩了

Redis内存快撑爆了,警告短信叮叮响，这可不是小事，弄不好服务就得瘫痪，数据都可能丢，别慌，咱们一步步来，就像收拾一个快塞爆的仓库，目的明确，手脚麻利。

赶紧看看“仓库”到底啥情况。 打开命令行，连上你的Redis，输入 INFO memory 这个命令，重点瞅瞅 used_memory 和 used_memory_peak，这俩数告诉你现在用了多少，历史最高用了多少，再看 maxmemory，这是你给Redis设的“仓库”最大容量，对比一下，是不是快顶到天花板了。used_memory 已经非常接近 maxmemory，警报就是它拉响的。（来源：Redis官方文档INFO命令说明）

知道满了，接下来得看看里面都堆了啥“货”。 用 redis-cli --bigkeys 这个命令（跑的时候注意别在流量高峰时搞，可能有点卡），它能帮你扫描一遍，找出哪种类型的Key最大、最多，可能发现一堆以“cache:user:session:”开头的哈希表占了大头，或者某个巨大的列表键塞了几十万个元素，找到这些“大块头”，你就有了清理的目标。

动手清理，讲究个先后顺序。 别一上来就乱删。

1. 先清“临时货架”——设置过期时间的Key。 Redis有个好机制，给Key设个过期时间（TTL），时间一到自动清理，但如果内存太满，它可能来不及清理，你可以用命令 redis-cli --scan --pattern “*” | while read key; do ttl=$(redis-cli ttl “$key”); if [ $ttl -eq -1 ]; then echo “$key”; fi; done 这个法子（或者用更高效的脚本）找出所有没设过期时间的“钉子户”Key，这些Key很可能是内存泄漏的元凶，重点检查它们是不是还有用，没用就果断删。
2. 对付“大块头”，分情况处理。 如果是缓存数据，比如上面找到的用户会话，评估一下能不能直接全清掉，让用户重新登录，这是最快的减压办法，如果是业务数据，比如那个巨大的列表，看看能不能按时间或规则拆分，删掉老旧的，删除单个大Key要用 UNLINK 命令，它比 DEL 更友好，会在后台慢慢删，不会卡住整个服务。（来源：Redis官方关于UNLINK命令的说明）
3. 检查“淘汰策略”这个仓库管理员。 输入 CONFIG GET maxmemory-policy，这个策略决定了内存满时，Redis怎么自动淘汰数据，默认可能是 noeviction（不淘汰，只报错），这最危险，会导致写不进去，赶紧把它改成 allkeys-lru 或 volatile-lru。allkeys-lru 会尝试淘汰最近最少用的任何Key；volatile-lru 只淘汰设了过期时间的Key里最少用的，改成这个，至少能先扛住，让服务能继续写入，给人工清理争取时间。（来源：Redis配置文件中关于maxmemory-policy的注释）

边清理边观察。 清理不是一锤子买卖，删一批Key，就回头看看 INFO memory 里的 used_memory 降下来没有，同时盯着服务的监控，看响应速度是不是恢复了，错误有没有减少。

治标还得治本。 这次压住了，得想想为啥会满：

• 是不是缓存数据只存不删？ 检查代码，确保缓存都有合理的过期时间。
• 是不是把Redis当数据库用了？ 超大对象、持续增长的全量数据，不该往Redis里硬塞。
• maxmemory 设得太小？ 根据机器内存和业务增长，适当调大点，但别超过物理内存，留点给系统。
• 没设监控告警？ 赶紧补上，别等满了才反应，监控 used_memory 的使用率，到80%就该提前告警了。

Redis内存告急是最高级别的运维警报之一,核心思路就是：快速诊断目标 -> 优先清理无过期时间Key和大Key -> 立即修改淘汰策略保服务 -> 事后复盘根因防再犯，手快有，手慢无，动作麻利点，服务就保住了。