volatile-lru和volatile-lfu等以volatile-开头的策略只淘汰设置了过期时间的key，即仅从expires字典中选取，未设过期时间的key完全不受影响；而allkeys-类策略会无差别淘汰所有key，包括持久化数据。
volatile-lru / volatile-lfu 等策略只删带过期时间的 key
这类以 volatile- 开头的淘汰策略（如 volatile-lru、volatile-lfu、volatile-ttl）在触发时，**只会从 Redis 的 expires 字典中选 key 删除**，而这个字典只存设置了 EXPIRE 或 SETEX 等命令的键。没设过期时间的 key 根本不会被扫描到，更不会被删。
所以如果你的配置数据、用户白名单、基础字典等 key 都没加 EXPIRE，哪怕内存打满，它们也完全安全。
- 判断一个 key 是否会被
volatile-策略淘汰，只看它是否在redis-cli --scan --pattern "*" | xargs -n 1 redis-cli ttl中返回非负整数（即设置了过期时间） -
TTL返回-1表示没设过期；返回-2表示 key 本身不存在或已过期但未被惰性/定期删除 - 即使你用
SET写入后立刻EXPIRE，只要成功执行过，它就进了expires字典，就可能被选中淘汰
allkeys-lfu 会删掉没设过期的持久化数据
allkeys-lfu、allkeys-lru 这类策略不区分是否过期，直接在整个 dict（主键空间）里找候选 key。如果你把 Redis 当作混合存储——既存缓存又存用户 session、配置项、甚至轻量级业务状态——那这些没设 EXPIRE 的 key 就有真实被踢出的风险。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 一旦
maxmemory触发，且当前内存紧张，allkeys-lfu可能淘汰掉你刚写入的、访问频次低的配置 key - 这种行为不可逆：淘汰后数据从内存消失，如果没开 AOF/RDB，这部分数据就永久丢失
- 即使开了 RDB/AOF，恢复时也只能回滚到上次持久化时刻的状态，中间写入的“持久化数据”若未落盘，一样丢
noeviction 不删数据但会直接拒绝写入
noeviction 是唯一“不删任何 key”的策略，但它不是兜底保护，而是熔断机制：内存满后，所有写命令（SET、HSET、LPUSH 等）立即返回 (error) OOM command not allowed when used memory > 'maxmemory'.，读操作照常。
- 适合纯只读场景，比如加载完配置后不再写入的 Redis 实例
- 缓存服务绝对不能用——流量高峰时大量
SET报错，上游业务会感知为缓存不可用 - 它不会删数据，但也不帮你腾地方，问题只是被掩盖了而已
真正决定“删不删持久化数据”的是你的 key 设计习惯
Redis 本身没有“持久化数据”和“临时缓存”的语义区分，只有“有没有过期时间”。所谓“持久化数据”，是你自己决定不加 EXPIRE 的那些 key；所谓“缓存”，是你主动加了过期时间的那些 key。淘汰策略只是按这个标记来执行。
- 如果你混用：一部分配置 key 加了
EXPIRE 86400（误以为“长期有效=一天”），另一部分用户 token 没加过期——那volatile-策略反而可能误删配置，allkeys-又可能误删 token - 最稳的做法是严格分层：缓存统一用
SETEX或SET ... EX；配置/状态类 key 绝对不用EXPIRE，并配volatile-lfu淘汰策略 - 别依赖“我没设过期就不会被删”——万一哪天运维脚本批量加了
EXPIRE，整个配置体系就可能被悄悄清掉
