Redis内存告警后如何快速清理无效数据？-Redis-PHP中文网

redis无冷数据识别能力，需人工定义冷标准（如idletime≥86400）、定位冷键（scan+业务前缀，禁用keys）、安全删除（unlink分批，禁用flush）；maxmemory-policy仅兜底，删后须查mem_fragmentation_ratio。

redis内存告警后如何快速清理无效数据？

内存告警后，别急着 FLUSHALL —— 那会直接清空所有数据，业务大概率中断。真正有效的清理，得靠“精准识别 + 分层清理 + 策略兜底”三步走。

无效数据 ≠ 过期但未删除的 key，还包括：长期未访问的冷 key、业务已下线但残留的缓存、重复写入的临时 token。关键不是看 TTL，而是看实际访问热度和生命周期。

TTL 或 PTTL 只能告诉你“理论上该过期”，但无法反映是否真被业务弃用（比如一个设置 7 天过期的配置项，实际 2 小时后就不再使用）
用 redis-cli --scan --pattern "user:*" 配合 OBJECT FREQ（Redis 4.0+）查访问频次，OBJECT IDLETIME 查空闲秒数，比单纯扫 EXPIRE 更准
对高频 key 做采样检查：DEBUG OBJECT keyname 能看到 lru 字段值，结合当前 server 时间戳可估算最后访问时间（注意：该命令仅用于调试，生产慎用）
优先排查 SCAN 出的、TTL 返回 -1（永不过期）但 IDLETIME > 86400 的 key —— 这类最可能是历史遗留垃圾

因为它们都“不主动、不彻底”：定期删除默认每秒最多执行 10 轮（hz 10），每次只随机抽 20 个带过期时间的 key；惰性删除则完全依赖请求触发 —— 如果某个 key 过期后永远没人 GET，它就一直占着内存。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

当内存使用率已达 95%+，靠默认的 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 和 maxmemory_samples 5，清理速度远跟不上内存增长
从库不会主动删过期 key，主库若延迟高或同步卡住，从库上大量过期 key 会持续存在，INFO keyspace 看不到，但 MEMORY USAGE 仍计入
CONFIG SET hz 100 可临时提升扫描频率，但 CPU 使用率会明显上升，需监控 used_cpu_sys 和 used_cpu_user

避免用 KEYS *（阻塞主线程），也别在高峰时段跑全量 SCAN —— 推荐分批 + Lua 原子执行，控制节奏。

用 Lua 脚本封装判断逻辑（例如：TTL 3600 才删），避免多次往返网络开销：

eval "for i, k in ipairs(KEYS) do if redis.call('ttl', k)  3600 then redis.call('del', k) end end" 1 temp:key1 temp:key2

别直接切到 allkeys-random —— 随机删可能把热 key 干掉。优先选有业务语义的策略，并配合 maxmemory-samples 提升精度。

如果大部分 key 都设了过期时间（如 session、验证码），用 volatile-lru 或 volatile-ttl，前者保活跃，后者清“马上到期”的
如果 key 没设过期时间但有明确冷热区分（如商品详情缓存），改用 allkeys-lfu，并把 maxmemory-samples 从默认 5 提到 10～15，让抽样更准
切策略后立刻验证：CONFIG GET maxmemory-policy，再发几条写命令观察 evicted_keys 是否开始增长
注意：noeviction 下写操作会直接报错 (error) OOM command not allowed when used memory > 'maxmemory'.，此时必须先清理或扩容，不能只调策略