立刻停写、查策略、换策略、压内存四步可救活90%线上告警：先用info memory和config get maxmemory-policy确认是否真超限及当前策略（如noeviction必致写入失败），再运行时切为allkeys-lru等合适策略，配合memory purge（7.0+）或scan+del批量清理，避免重启与误删。

立刻停写、查策略、换策略、压内存，四步能救活90%的线上告警。别等OOM报错才动手。

查当前策略和内存使用是否真超限

先确认是不是误报或临时抖动，而不是直接改配置。很多告警是瞬时 spike，没到真正危险程度。

• INFO memory 看 used_memory_human 和 maxmemory_human 是否真的接近或超过 —— 注意：mem_fragmentation_ratio > 1.5 可能只是内存碎片高，不是真满
• CONFIG GET maxmemory-policy 查当前策略，如果是 noeviction，写入失败就是必然结果，必须改
• MEMORY STATS 看 peak_allocated 和 total_allocated，判断是否刚经历大写入峰值

运行时快速切换淘汰策略（不重启）

生产环境不能重启 Redis，CONFIG SET 是唯一安全路径。但要注意：策略切换不会立即释放内存，只影响后续写入行为。

Redis Skill - 高性能缓存管理

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

下载

• 紧急切到 allkeys-lru：适合通用缓存场景，命令是 CONFIG SET maxmemory-policy allkeys-lru
• 如果已有大量带 TTL 的 key（比如 session、token），优先用 volatile-lru 或 volatile-ttl，避免误删持久数据
• 切完立刻执行 MEMORY PURGE（Redis 7.0+）可主动回收内存碎片；老版本只能靠后续写入触发渐进式清理
• 不要切到 allkeys-random 或 volatile-random —— 随机淘汰在高负载下容易踢掉热点 key，引发雪崩

配合 immediate 内存释放操作

光换策略不够，得让 Redis 立刻“吐出”一部分内存。这些操作要谨慎，但比等自动淘汰快得多：

• 批量删冷 key：SCAN + DEL 组合，避免阻塞。例如删前缀为 tmp: 的 key：SCAN 0 MATCH tmp:* COUNT 1000，拿到游标后分批 DEL
• 对大 value 做降级：GETRANGE 截取部分值，或用 SETRANGE 覆盖为更小内容，比全删更温和
• 禁用 appendonly（仅限 AOF 关闭且无主从同步风险的场景）：临时减少 write-ahead log 开销，缓解内存压力
• 注意：FLUSHDB / FLUSHALL 是最后手段，会清空全部数据，务必确认业务可接受

为什么 volatile-lfu 比 volatile-lru 更难生效？

LFU 不是开箱即用的“智能策略”，它依赖访问频次统计，而这个统计有冷启动和衰减机制 —— 新 key 写入后不会立刻被识别为“低频”，旧 key 的计数也会随时间衰减。

• lfu-log-factor 和 lfu-decay-time 影响 LFU 敏感度：默认 lfu-log-factor 10 会让低频 key 很难被选中；调小（如 1）可加快淘汰，但可能误伤中频 key
• LFU 计数只在 key 被访问时更新，如果某 key 近期没被读过，它的计数不会自动下降，直到下次访问或后台衰减任务触发
• 真正想用 LFU，得先跑几天观察 OBJECT FREQ 输出，再决定是否调整参数，不能拿来就当“急救药”

策略切完不代表万事大吉——接下来 5 分钟内必须盯住 evicted_keys 和 rejected_commands 指标，看是否真在淘汰、有没有新写入被拒。很多故障是策略改了但 maxmemory 设得太死，或者 key 大小远超预期，导致淘汰速度跟不上写入速度。