redis内存超限写入失败的根本原因是maxmemory-policy默认为noeviction，内存达maxmemory时所有写命令直接报oom错误；allkeys-lru比volatile-lru更适合作兜底策略，因其可淘汰所有键而非仅带ttl的键，确保内存可回收。

Redis内存超限写入失败的根本原因

Redis默认的maxmemory-policy是noeviction，意思是“不驱逐”，一旦内存达到maxmemory配置值，所有写命令（如SET、LPUSH、HSET）都会直接返回错误：(error) OOM command not allowed when used memory > 'maxmemory'.
这不是网络或权限问题，而是策略层面的硬限制。只要没改策略，哪怕只超1字节，写操作就失败。

为什么allkeys-lru比volatile-lru更适合作为兜底策略

allkeys-lru会从整个键空间中淘汰最近最少使用的键，而volatile-lru只淘汰设置了过期时间的键。实际生产中常见两类情况：

• 缓存键没设TTL（比如用SET cache:user:123 "data"直写，无EX参数）
• 部分业务键本就不该有过期逻辑（如全局配置、热点白名单）

这时volatile-lru可能完全无法释放内存，最终仍卡在noeviction状态。而allkeys-lru能真正覆盖所有键，确保内存可回收。

调整策略前必须确认的三件事

• maxmemory已明确配置（单位字节），且不是0（表示不限制，此时策略不生效）
• Redis版本 ≥ 4.0（allkeys-lru在2.8+就支持，但低版本对LRU精度和内存统计有偏差）
• 没有依赖“写入必成功”的强一致性逻辑——因为淘汰是异步触发的，SET可能成功，也可能因淘汰延迟导致下一次GET不到刚写的值

修改方式有两种：

• 运行时动态改：CONFIG SET maxmemory-policy allkeys-lru
• 永久生效：在redis.conf中写入maxmemory-policy allkeys-lru并重启

注意：CONFIG SET不会持久化到配置文件，仅本次运行有效。

Redis Skill - 高性能缓存管理

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

下载

allkeys-lru的实际行为与潜在风险

Redis不是每次写都立刻淘汰，而是在以下任一条件满足时触发：

• 执行写命令前检查内存超限
• 后台周期性执行activeExpireCycle时顺带做LRU淘汰

这意味着：

• 内存可能短暂超过maxmemory（通常不超过5%）
• 淘汰的键是近似LRU，非严格LRU（出于性能考虑，Redis采样5个key做比较，而非全量扫描）
• 如果大量键访问模式高度集中（比如90%请求只打10个key），其余key可能长期不被访问，从而被误淘汰

所以，它适合缓存场景，但不适合用作唯一数据源——别把重要状态全塞Redis还指望它永不丢。

Redis的淘汰逻辑藏在内存分配路径里，不是独立线程轮询。调得再急，也绕不开这个设计前提。