内存满了会拒绝写入
maxmemory-policy 设为 noeviction 时，内存用满后 Redis 不淘汰任何键，而是直接让写命令失败，报 OOM command not allowed when used memory > maxmemory。读命令默认仍然可用，这个设计的取向是「宁可拒绝写入，也不悄悄丢数据」，所以看到这类报错要当成容量或策略问题处理。
基本信息
| 典型报错 | OOM command not allowed when used memory > maxmemory |
|---|---|
| 读命令 | 默认仍可执行 |
| 写命令 | 被拒绝，部分命令可按配置放行 |
| 相关配置 | maxmemory、maxmemory-policy |
典型使用场景
- 写接口突然大面积报错，确认是不是服务端内存打满
- 把 Redis 当存储而非纯缓存时，评估 noeviction 的风险
- 排查「同一份代码有的实例报错有的不报」
- 容量评审时确认每个实例当前的淘汰策略
- 上线前用压测验证内存打满时的行为是否可以接受
定位与确认
定位与确认
# 看当前用量与上限之间的差距
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'
# 确认淘汰策略：noeviction 表示不淘汰、写入直接失败
redis-cli CONFIG GET maxmemory-policy
# 是否已经出现淘汰与拒连
redis-cli INFO stats | grep -E 'evicted_keys|rejected_connections'
# 应急前先看有哪些大键可以评估清理
redis-cli --bigkeys现象与含义对照
| 现象 | 含义 | 应对方向 |
|---|---|---|
| OOM command not allowed | 达到上限且不允许淘汰 | 扩容、改策略或清理数据 |
| evicted_keys 持续增长 | 已经在按策略淘汰键 | 说明当前是可淘汰策略 |
| used_memory 长期贴近上限 | 容量已到边界 | 提前规划扩容 |
| mem_fragmentation_ratio 偏高 | 碎片挤占可用额度 | 碎片治理或安排重启 |
| maxmemory 偏小 | 上限设置低于业务增长 | 复核实例规格与配置 |
noeviction 适合不允许丢数据的场景；纯缓存场景通常用 allkeys-lru 之类的策略，让新数据能写得进来，代价是旧键会被淘汰，业务要能接受这一点。
应急时把策略临时改成可淘汰策略，会立刻开始淘汰键；如果这个实例承载的是不能丢的数据，这个操作的破坏力等同于删数据，动手前必须先确认数据属性。