Redis淘汰策略配置为noeviction会发生什么？如何优化？-Redis-PHP中文网

noeviction 是写入熔断机制而非安全默认：内存满时所有写命令报错，读操作正常；生效需满足 maxmemory 已设且合理、淘汰策略匹配数据特征（如 volatile-* 要求多数 key 有 ttl）、evicted_keys 持续增长验证真实生效。

redis淘汰策略配置为noeviction会发生什么？如何优化？

Redis 配置为 noeviction 时，内存一满，所有写命令（SET、HSET、LPUSH、INCR 等）立刻报错，读操作不受影响。这不是性能下降，是硬性拒绝——业务侧看到的是大量 (error) OOM command not allowed when used memory > 'maxmemory'。

为什么 noeviction 不是“安全默认”，而是熔断开关

noeviction 是 Redis 4.0+ 的默认策略，但它不意味着“稳妥”或“兜底”。它本质是写入熔断机制：

没设 maxmemory？那淘汰逻辑根本不会触发，noeviction 形同虚设
设了 maxmemory 但没配淘汰策略？Redis 就按 noeviction 执行，写操作直接失败
线上流量高峰时，缓存写不进、计数器更新失败、消息入队报错，根源常不在代码，而在 Redis 拒绝写入

改策略前必须验证的三件事

只执行 CONFIG SET maxmemory-policy allkeys-lru 很快，但大概率无效。真正起效需同时满足：

Redis Skill - 高性能缓存管理

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

下载

maxmemory 已设置且值合理（比如 2gb），否则 Redis 根本不启动淘汰流程
若选 volatile-lru 或 volatile-ttl，必须确认 ≥70% 的 key 真设置了 EXPIRE 或用 SETEX 写入；否则“可淘汰池”为空，实际等效于 noeviction
改完后查 INFO memory 中的 evicted_keys：持续增长才说明淘汰在真实工作；若长期为 0，说明策略未生效或数据特征不匹配（例如全是长 TTL 键 + volatile-* 策略）

allkeys-lru 是最省心的生产兜底策略，但有陷阱

相比 volatile-* 类策略，allkeys-lru 不挑 key，所有键都参与排序，适合缓存写入不可控、部分 key 无 TTL 的场景：

它不是万能解药：allkeys-lfu 看似更智能，但默认 lfu-log-factor 10 在低频访问下会导致冷 key 被误判为热 key，该淘汰的没淘汰
allkeys-random 和 volatile-random 淘汰完全随机，可能刚写入的热点数据被干掉，生产环境基本不用
如果业务强依赖某些 key 长期存在（如全局配置、权限白名单），allkeys-* 类策略有误删风险，应单独建库隔离，而非靠策略妥协