redis内存达maxmemory后写入失败，根本原因是noeviction策略或淘汰未触发：需检查mem_fragmentation_ratio>1.5、evicted_keys是否为0、key是否缺失ttl导致volatile策略失效。
内存打满后写入直接失败？先确认淘汰策略是否生效
Redis 内存达到 maxmemory 时，如果写入被拒绝并返回 OOM command not allowed when used memory > 'maxmemory'，说明当前策略是 noeviction（默认值），或者虽配置了其他策略但根本没触发淘汰——常见原因是过期键堆积未清理、内存碎片率高（mem_fragmentation_ratio > 1.5）、或 evicted_keys 持续为 0。
立刻检查：
-
redis-cli INFO memory中的used_memory、maxmemory、mem_fragmentation_ratio和evicted_keys -
redis-cli CONFIG GET maxmemory-policy确认实际生效策略 -
redis-cli INFO stats查看expired_keys是否远大于evicted_keys，若成立，说明过期键没被及时回收，惰性删除 + 定期删除机制已滞后
volatile-lru 和 allkeys-lfu 怎么选？看数据有没有统一过期逻辑
如果业务中大部分 key 都设置了 TTL（比如 session、token、验证码），且你希望保留“最近还用过”的热数据，volatile-lru 是安全起点：它只动带过期时间的 key，不影响长期存储的配置类数据。
但如果 key 混合了永久数据（如白名单、系统参数）和临时缓存，又想按访问频次淘汰（比如推荐商品缓存里少数爆款反复被查），就得用 allkeys-lfu ——它对所有 key 统计访问频次，但要求 Redis ≥ 4.0，且需注意 maxmemory-samples 默认为 5，采样太小会导致 LFU 误判，建议调到 10～15。
容易踩的坑：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 误用
volatile-lfu却给大量 key 忘设 TTL → 实际等效于noeviction，因为没 key 符合淘汰条件 - 用
allkeys-lru处理带长 TTL 的配置项 → 可能刚写入的配置因“未访问”被误删 -
volatile-ttl在批量刷新缓存时反而加剧雪崩：所有新 key TTL 相近，会集中被淘汰
为什么设置了策略却几乎不淘汰？关注三个隐藏开关
淘汰不是“开个策略就自动跑”，它依赖三个隐性条件同时满足：
-
maxmemory必须显式设置（单位可以是2gb、100mb），仅靠物理内存剩余量不管用 - 淘汰发生在「命令执行前申请内存」阶段，不是后台定时扫描；也就是说，没有写入压力，就不会触发淘汰
-
maxmemory-samples决定每次随机采样多少 key 来评估（LRU/LFU/TTL），默认 5 个。值太小（如 1）会让淘汰变成近乎随机；太大（如 100）增加 CPU 开销，尤其在大实例上
实操建议：
- 生产环境首次启用淘汰策略前，先用
CONFIG SET maxmemory 1gb+CONFIG SET maxmemory-policy allkeys-lru做小流量验证 - 观察
INFO stats中evicted_keys是否随写入增长，而不是只看内存曲线 - 避免在
redis.conf里写maxmemory 0或注释掉该行 —— 这等于没设上限，淘汰策略永远不会激活
淘汰不是万能解药：碎片、过期延迟、冷热混杂才是真瓶颈
即使淘汰策略跑得飞快，mem_fragmentation_ratio 超过 1.7 仍可能让 Redis 报 OOM；这是因为 jemalloc 分配器无法合并碎片，物理内存明明够，却申请不到连续页。
过期键清理滞后比淘汰更致命：一批 TTL=86400 的 key 在同一秒过期，Redis 的定期删除任务（默认每秒 10 次，每次最多 25 个）根本处理不完，它们继续占内存，直到下次访问才惰性删除 —— 这就是 evicted_keys 为 0 但 used_memory 居高不下的真相。
最常被忽略的一点：淘汰策略只解决“腾空间”，不解决“谁该留”。如果你的缓存里既有用户画像（高频读）、又有日志流水（低频但需保留 7 天），硬套一个全局 LRU 就等于拿锤子砸电路板——动作很大，效果很糟。
