仅靠maxclients无法防OOM，因其只限连接数而非内存；需协同配置client-output-buffer-limit和maxmemory-clients，管控各客户端缓冲区及总客户端内存。
直接结论：仅靠 maxclients 无法解决客户端连接导致的内存溢出，必须配合 maxmemory-clients 和缓冲区控制。
为什么 maxclients 本身不防 OOM
设置 maxclients 10000 只是限制连接数上限，但每个连接背后有输入/输出缓冲区（client output buffer），尤其在慢客户端、订阅模式或大响应场景下，单个连接可能占用几 MB 甚至几十 MB 内存。Redis 不会因为连接数未超限就拒绝写入响应——它会继续堆积，直到 used_memory 触发全局淘汰或 OOM。
-
maxclients控制的是 socket 连接数量，不是内存用量 - 一个空闲但未关闭的 PUB/SUB 连接，
output_buffer可能持续增长至几百 MB -
client-output-buffer-limit才真正约束每个客户端的缓冲区内存，但它默认只对 pubsub 和 slave 生效，普通 client 是无限制的（0）
必须配齐的三项配置：client 缓冲区 + 客户端内存总量 + 连接数
三个参数协同生效，缺一不可：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
maxclients 10000：按服务器资源设合理上限，避免 fd 耗尽；需确认系统ulimit -n≥ 此值 + 预留（如 10240） -
client-output-buffer-limit normal 0 0 0：显式禁用普通 client 的 output buffer 限制（即不限制），但这恰恰是危险默认值；应改为类似client-output-buffer-limit normal 2mb 4mb 60（2MB 软限、4MB 硬限、60 秒内超限则断连） -
maxmemory-clients -50：让客户端相关内存（含所有 input/output buffer）总和不超过maxmemory的 50%，这是 Redis 7.0+ 才有的硬性兜底机制；若设为正数如1gb，则按绝对值限制
如何验证客户端内存是否真被控住
光改配置不生效，得看指标：
- 执行
info clients，重点关注client_longest_output_list和client_biggest_input_buf；值持续 > 1MB 就说明有客户端在积压响应 - 执行
info memory，检查used_memory和used_memory_rss差距是否异常扩大；若mem_fragmentation_ratio > 1.5且used_memory_peak持续上涨，大概率是 client buffer 没控住 - 用
client list抓出 top 5 大 buffer 客户端：client list | grep "omem=" | sort -k5 -nr | head -5（omem字段即 output buffer 字节数）
容易被忽略的坑：slowlog 和 monitor 也会吃内存
这两个调试功能开启后，会为每个连接额外分配 buffer，且不受 client-output-buffer-limit 约束：
-
slowlog-log-slower-than 10000（默认 10ms）本身不占内存，但 slowlog list 存在时，每条记录都占内存；slowlog-max-len 128应设为合理值，避免日志堆满 -
monitor命令一旦启用，会为每个 monitor client 开辟独立 output buffer，并实时复制所有命令——一个 monitor 连接就可能吃掉上百 MB，且无法通过常规 buffer limit 控制 - 生产环境务必确保
monitor关闭，或严格限制其生命周期（如只开 30 秒用于临时排查）
真正卡住 Redis 内存的，往往不是 key 数据本身，而是那些“看不见”的连接缓冲区。配置再全，不盯 client list 和 info memory 的实时输出，等于没设。
