OOM command not allowed when used memory > 'maxmemory' 表明 Redis 实例当前的内存使用量已经达

错误：RedisException vendor/laravel/framework/src/Illuminate/Redis/Connections/Connection.php:122 OOM command not allowed when used memory > 'maxmemory'.

这个错误 OOM command not allowed when used memory > 'maxmemory' 表明 Redis 实例当前的内存使用量已经达到了配置的 maxmemory 上限，并且由于当前的‌内存淘汰策略（maxmemory-policy）‌配置为 noeviction（默认值）或无法有效淘汰数据，导致 Redis 拒绝了新的写入命令以保护自身不崩溃。

这‌并不一定‌意味着服务器物理内存耗尽，而是 Redis 内部逻辑触发了写保护。以下是针对该问题的详细排查步骤和解决方案：

1. 核心原因分析
   内存已达上限‌：Redis 内部统计的已用内存 (used_memory) 大于等于配置的最大内存 (maxmemory)。
   淘汰策略无效‌：
   如果 maxmemory-policy 设置为 noeviction（默认），Redis 不会删除任何旧 key，直接拒绝写入。
   如果设置为 volatile-* 策略（如 volatile-lru），但当前数据库中‌没有设置过期时间（TTL）‌的 key，Redis 也无法淘汰数据，同样会报错。
   内存碎片或隐性占用‌：虽然 used_memory 可能未完全填满，但内存碎片率过高或缓冲区占用过大，导致实际可用内存不足。

2. 紧急恢复方案（先让业务恢复正常）

如果线上业务正在报错，请优先执行以下操作释放内存：

方案 A：动态调整最大内存（临时扩容）

如果服务器物理内存还有剩余，可以临时调大 Redis 的内存上限。

bash

连接 Redis CLI

redis-cli

查看当前限制

CONFIG GET maxmemory

临时调整为更大值（例如从 2gb 调整为 4gb，根据服务器实际空闲内存决定）

CONFIG SET maxmemory 4gb

务必将配置写入配置文件，防止重启失效

CONFIG REWRITE

方案 B：手动清理大 Key 或无用数据

如果无法扩容，需手动删除部分数据以腾出空间。

bash

1. 查找占用内存最大的 Key（谨慎使用，生产环境建议在低峰期执行）

redis-cli --bigkeys

2. 删除指定的大 Key 或过期数据

推荐使用 UNLINK 异步删除，避免阻塞主线程

UNLINK key_name

3. 如果确定某些前缀的缓存可以清空

注意：FLUSHDB 会清空当前数据库所有数据，请慎用！

FLUSHDB

方案 C：修改淘汰策略（长期建议）

将淘汰策略从 noeviction 改为自动淘汰策略，让 Redis 在内存满时自动删除旧数据。

bash

设置为所有键中最近最少使用的被淘汰（适合纯缓存场景）

CONFIG SET maxmemory-policy allkeys-lru

或者设置为设置了过期时间的键中最近最少使用的被淘汰

CONFIG SET maxmemory-policy volatile-lru

持久化配置

CONFIG REWRITE

3. 深度排查与根本解决

为了防止问题再次发生，需要分析内存被谁占用了。

第一步：检查内存使用情况

执行 INFO memory 命令，关注以下指标：

bash
redis-cli INFO memory

used_memory_human‌: Redis 实际分配的数据内存。
maxmemory_human‌: 配置的最大内存限制。
mem_fragmentation_ratio‌: 内存碎片率。
如果 used_memory < maxmemory 但报错，且 mem_fragmentation_ratio > 1.5，说明是‌内存碎片‌导致的问题。
解决碎片‌：执行 MEMORY PURGE（Redis 4.0+）或重启 Redis 实例。
第二步：检查淘汰策略
bash
redis-cli CONFIG GET maxmemory-policy

如果返回 noeviction，这是导致报错的直接原因。生产环境作为缓存使用时，‌强烈建议‌不要使用默认值，应设置为 allkeys-lru、allkeys-random 或 volatile-lru 等。
第三步：排查“隐形”内存占用

maxmemory 仅限制数据存储内存，以下部分‌不计入‌ maxmemory 限制，但会消耗物理内存，可能导致系统级 OOM 或间接影响 Redis 性能：

客户端输出缓冲区‌：如果有客户端读取数据慢，缓冲区会积压。
检查：CLIENT LIST 查看 omem 字段。
主从复制积压缓冲区‌：主从同步延迟时，backlog 会增大。
检查：INFO replication 中的 repl_backlog_size。
AOF/RDB 持久化开销‌：在进行 AOF 重写或 RDB 保存时，Linux 的 Copy-On-Write (COW) 机制会导致内存瞬时翻倍。
建议‌：maxmemory 建议设置为物理内存的 ‌60%-70%‌，为操作系统和持久化过程预留足够空间。
第四步：分析大 Key (Big Keys)

单个巨大的 Key（如包含百万成员的 Hash 或 Set）会导致内存瞬间飙升且难以淘汰。

bash

扫描大 Key

redis-cli --bigkeys

如果发现异常大的 Key，评估是否可以拆分或删除

4. 最佳实践建议
   显式设置 maxmemory‌：永远不要依赖默认值（0 表示无限制，直到撑爆物理内存被系统 Kill）。
   合理设置淘汰策略‌：
   纯缓存场景：使用 allkeys-lru 或 allkeys-random。
   混合场景（部分数据永不过期）：使用 volatile-lru 并确保热点数据有 TTL。
   预留内存余量‌：
   maxmemory 不应超过物理内存的 70%-80%。
   例如：16GB 内存的服务器，建议设置 maxmemory 10gb 或 12gb，留出空间给操作系统、日志进程以及 Redis 自身的 fork 操作。
   监控告警‌：
   监控 used_memory / maxmemory 比率，当超过 80% 时发出警告。
   监控 mem_fragmentation_ratio，当超过 1.5 时关注碎片情况。
   总结

你遇到的错误是因为 ‌Redis 内存满了且不允许自动删除数据‌。

最快解决‌：CONFIG SET maxmemory <更大值> 或 CONFIG SET maxmemory-policy allkeys-lru。
根本解决‌：优化代码中的 Key 过期策略，清理大 Key，并合理规划 maxmemory 大小。