误配allkeys-lru或allkeys-random会导致核心key被无差别淘汰，表现为缓存命中率秒级归零、DB QPS突增、响应飙升至800ms+，需严格按“停写→切策略→恢复数据”三步闭环处理。
误配 allkeys-lru 或 allkeys-random 会导致核心业务 key（如登录态、库存锁、幂等 token）被无差别淘汰，现象是缓存命中率秒级归零、DB QPS 突增、接口响应从 20ms 拉到 800ms+。这不是渐进式恶化，而是立即失控——必须按“停写 → 切策略 → 恢复数据”三步闭环操作，跳过任一环都可能让残留的无 TTL key 继续被扫荡。
确认当前策略是否已陷入 allkeys 风险状态
先验证问题是否存在，而不是凭经验猜测：
- 执行
redis-cli CONFIG GET maxmemory-policy，返回值为allkeys-lru或allkeys-random即为高危状态 - 同时运行
redis-cli INFO memory | grep -E "used_memory_human|maxmemory"，确认used_memory_human已接近或超过maxmemory—— 若已满，CONFIG SET可能延迟生效甚至失败 - 观察
evicted_keys是否持续增长（redis-cli INFO stats | grep evicted_keys），这是淘汰正在发生的直接证据
切回 volatile-lru 前必须停写
直接 CONFIG SET maxmemory-policy volatile-lru 是无效动作：策略只约束“有 TTL 的 key 是否参与淘汰”，不保证“没 TTL 的 key 就安全”。若已有大量无 TTL key 存在，切回去后它们仍会被淘汰（因为 volatile-lru 不管它们，但内存压力仍在，Redis 会 fallback 到拒绝写入或触发其他机制）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 停写 ≠ 关 Redis，而是让上游流量绕过它（如 Nginx 降级到直连 DB）、或在应用层强制走本地缓存 + DB 查询路径
- 必须在停写后、切策略前，确认
evicted_keys增速归零 —— 否则说明仍有写入在制造新无 TTL key - 切完立即执行
CONFIG REWRITE，否则重启后策略丢失，灾难重现
从 RDB 恢复关键数据的关键限制
RDB 不是全量备份，它只是某一时刻的内存快照。恢复前必须核对两个事实：
- 你要恢复的 key，在最近一次 RDB 生成时是否还存活？查
INFO persistence中的rdb_last_save_time，结合业务日志判断该时间点 key 是否已被淘汰或未写入 - RDB 文件本身是否完整？用
redis-check-rdb /var/lib/redis/dump.rdb校验，损坏的 RDB 无法加载 - 恢复不是“覆盖式还原”：停写后，先
FLUSHDB清空当前残缺状态，再用redis-cli --rdb /var/lib/redis/dump.rdb加载 —— 注意这会丢弃所有后续写入，包括你刚手动补的临时 key
真正容易被忽略的是：volatile-* 类策略依赖 TTL 存在。如果业务 key 本就不设过期时间（比如某些长期有效的配置或白名单），哪怕切回 volatile-lru，它们依然不受保护——这种设计缺陷必须从应用层补 TTL，而不是指望配置修复。
