noeviction触发后所有写命令（set、hset等）直接返回oom错误，读操作正常，导致“能读不能写”；根源是内存达限后硬性熔断，而非延迟或数据淘汰，需监控mem_fragmentation_ratio、client-output-buffer等隐性内存消耗。

noeviction 触发后写命令直接返回 OOM 错误

当 used_memory 超过 maxmemory，所有写命令（SET、HSET、LPUSH、INCR、XADD）会立刻失败，返回固定错误：(error) OOM command not allowed when used memory > 'maxmemory'。这不是延迟升高或后台抖动，是硬性熔断——业务代码若没捕获该错误，HTTP 接口就直接 500，前端重试雪崩，日志里全是 OOM。

能读不能写是典型表象，但根源常被误判

你可能看到 GET、HGETALL 正常，SET 却全挂，于是怀疑网络或客户端。其实这是 noeviction 的设计行为：它只拒绝写，不干扰读。排查时容易踩的坑包括：

• 只看 used_memory_human 和 maxmemory_human，忽略 mem_fragmentation_ratio > 1.5 导致 RSS 内存早已耗尽
• 监控 evicted_keys 为 0 就认为“没压力”，但 noeviction 下这个值永远是 0
• 以为 client-output-buffer 或 slave_buf 占用不计入 used_memory，就不管它们——而它们真能悄悄吃掉几百 MB 可用内存

订单、登录、计数器等关键路径最易连锁崩塌

这些操作通常无幂等保护、无重试兜底、不校验 Redis 返回值，错误直接透出：

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

• SET session:xxx ... EX 1800 失败 → 登录态无法写入，用户反复点击登录，请求堆积
• HSET order:20260905001 status "paid" 拒绝 → 支付成功但状态未更新，财务对账差一笔，人工介入成本高
• INCR user:123:login_count 失败 → 行为漏统计，风控规则阈值失效，异常登录逃逸检测
• XADD stream:events * event "timeout" 拒绝 → 事件丢失，下游补偿逻辑无从触发

改策略前不验证淘汰是否真生效，等于白改

执行 CONFIG SET maxmemory-policy allkeys-lru 后，别只信 CONFIG GET 返回值。必须盯住两个指标：

• INFO stats 中的 evicted_keys 是否在 5 分钟内稳定增长（不是单次跳变）
• INFO memory 中 used_memory_human 是否开始回落并维持在 maxmemory_human 以下

如果 evicted_keys 仍为 0，大概率是 maxmemory 没设、或选了 volatile-lru 但大部分 key 根本没 TTL——策略配了，但没数据可淘汰。