<p>noeviction 是写入熔断机制而非安全默认：内存满时所有写命令报错，读操作正常；生效需满足 maxmemory 已设且合理、淘汰策略匹配数据特征（如 volatile-* 要求多数 key 有 TTL）、evicted_keys 持续增长验证真实生效。</p>
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-*类策略有误删风险，应单独建库隔离，而非靠策略妥协
线上改策略必须配合监控验证
CONFIG GET maxmemory-policy 返回 allkeys-lru 只代表配置值对了，不代表淘汰真在工作。真实生效要看：
- 5 分钟内
INFO stats中的evicted_keys是否稳定爬升（不是突增一次就完事） -
INFO memory中used_memory_human是否在maxmemory_human附近小幅震荡，而不是一路冲顶后卡死 - 避免只看日志有没有报错，要盯指标变化节奏——淘汰策略是否生效，本质上是个“动态平衡”问题，不是开关一拨就万事大吉
