Redis 内存突然增长可能来自数据量增加、BigKey、过期失效、客户端缓冲区、复制积压或内存碎片。贸然执行全量扫描或大 Key 删除，可能阻塞单线程并扩大故障。
一、确认内存构成
redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO clients关注 used_memory、used_memory_rss、mem_fragmentation_ratio、maxmemory、淘汰次数和客户端缓冲区。RSS 明显高于 used_memory 时需要检查碎片、jemalloc 和后台 fork。
二、安全定位 Key
redis-cli --bigkeys
redis-cli --memkeys
redis-cli MEMORY USAGE <KEY>生产环境避免 KEYS *。大规模实例应使用低峰采样、SCAN 和离线分析。BigKey 不只占内存，还会导致网络拥塞、删除阻塞和主从复制延迟。
三、检查过期与淘汰策略
redis-cli INFO keyspace
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy检查业务是否遗漏 TTL、同一时间大量 Key 过期、淘汰策略是否符合缓存或持久数据用途。缓存系统通常需要合理的 maxmemory 与淘汰策略，不能依赖宿主机 OOM 兜底。
四、检查客户端与复制
redis-cli CLIENT LIST
redis-cli INFO replication慢客户端、Pub/Sub、输出缓冲区、复制积压和网络中断都可能推高内存。还要关注 RDB/AOF rewrite 期间 fork 的写时复制额外内存。
五、紧急止血
限制异常写入并定位来源；
对 BigKey 使用
UNLINK异步删除；临时扩容前确认持久化、复制和故障转移策略；
不要在未知用途的实例直接切换淘汰策略；
保留 INFO、慢日志和 Key 分布证据。
六、长期治理
为数据统一设置 TTL；限制单 Key 大小和集合成员数；监控 used_memory、RSS、碎片率、淘汰、过期、客户端缓冲区和复制延迟；把 Key 命名规范与容量预算纳入上线评审。
总结
Redis 内存治理不能只看总量，要分清数据、客户端、复制、fork 和碎片。用采样定位来源，安全处理 BigKey，再从 TTL、淘汰策略和数据模型上防止复发。