noeviction是Redis默认策略，内存达maxmemory时硬性拒绝所有写命令并返回OOM错误，不淘汰数据，导致“能读不能写”，仅适用于纯只读配置中心等极少数场景。
Redis内存满了，不是立刻换机器或加内存就完事——关键看 maxmemory-policy 配置是否匹配你的数据特征和业务容忍度。选错策略，轻则缓存命中率暴跌，重则写入阻塞、数据库雪崩。
为什么noeviction是默认策略却最危险？
它不淘汰任何键，内存一满就返回 OOM command not allowed when used memory > maxmemory 错误。看似“安全”，实则把压力全甩给上游：写请求直接失败，订单创建、用户登录等链路瞬间中断。
- 只适合极少数场景：比如 Redis 用作纯只读配置中心，且所有 key 都带 TTL、过期后由外部兜底重建
- 监控时发现
evicted_keys:0但used_memory持续逼近maxmemory，基本就是它在默默报错 - 切勿在缓存场景下长期使用——它不是“保守”，是放弃治疗
volatile-lru和allkeys-lru到底该选谁？
区别不在“LRU”算法本身，而在淘汰范围是否包含永久键（没设 TTL 的 key）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 如果你的业务明确区分“临时缓存”和“持久状态”（比如 session 有 TTL，用户资料无 TTL），用
volatile-lru：只动带过期时间的键，避免误删核心数据 - 如果你所有数据都是缓存，且允许全部参与淘汰（例如 CDN 元数据、商品页 HTML 片段），用
allkeys-lru：更充分利用内存，热点数据留存率更高 - 注意：Redis 的 LRU 是近似实现，每次随机采样 N 个 key（默认 N=5），不是全量扫描，所以实际淘汰顺序和理论 LRU 有偏差
volatile-ttl适合什么真实场景？
它不看访问频次或时间，只看剩余生存时间——TTL 越短，越先被淘汰。这听起来反直觉，但对某些定时任务型缓存很有效。
- 典型用例：秒杀库存预热时生成的临时计数器，TTL 设为 10 分钟；同时存在一批 24 小时 TTL 的商品详情缓存。活动结束前，优先淘汰即将过期的计数器，保留长期缓存
- 风险点：如果大量 key 的 TTL 被设成相同值（比如统一设为 3600 秒），
volatile-ttl会退化成随机淘汰 - 不适用于通用缓存：它无法识别“冷热”，可能把刚写入但 TTL 短的热数据提前踢掉
为什么volatile-lfu在 Redis 4.0+ 值得重点关注？
LFU（Least Frequently Used）按访问频次淘汰，比 LRU 更适应“长尾流量”场景——有些数据访问间隔长但稳定，LRU 会误判为冷数据。
- 适用前提：必须所有待淘汰 key 都设置了 TTL，否则
volatile-lfu完全不生效 - 性能开销略高于 LRU：每个 key 需维护访问计数器，但 Redis 已做衰减优化（避免计数器溢出），实际影响可控
- 调试技巧：用
OBJECT FREQ keyname查看单个 key 当前 LFU 频次，验证是否符合预期分布
真正难的不是记住 8 种策略名字，而是确认你数据里有多少带 TTL、哪些绝对不能丢、业务能否接受写失败——这些信息藏在代码里的 SET 和 EXPIRE 调用中，不在配置文件里。
