Redis 设了上限还是 OOM：碎片与缓冲不归它管

直接答案：maxmemory 只统计键数据那一部分，进程实际内存还包括内存碎片、主从复制缓冲、客户端缓冲与 Lua 等开销——键没到上限而进程先被系统判死，就是这些"编外支出"顶的。想根治要先看对账单，再动淘汰策略。

对账三处

info memory 里三行是关键：used_memory（maxmemory 管的账）、mem_fragmentation_ratio（碎片率，高于 1.5 说明碎片侵占明显）、used_memory_overhead（复制与客户端缓冲等开销）。主从同步刚建立或断线重连时，复制缓冲会猛涨；有客户端用大命令拉全量数据，输出缓冲同样膨胀。

策略里藏的坑

淘汰策略默认 noeviction——写满直接报错，这不是"自动清理"，很多故障源于默认值没改过；按业务选 allkeys-lru（缓存型）或 volatile-lru（只动设过期的键）。但淘汰策略再对，也兜不住碎片与缓冲：碎片靠日常重启窗口或开启主动碎片整理缓解，缓冲靠限制 client-output-buffer-limit 与避免大 key、大范围扫描命令。

版本与迁移各一句

版本升级能吃到碎片整理与内存统计的改进，升级前在测试环境压一轮真实键分布，别拿空库测——碎片率与键大小强相关。实例迁移或扩容时按持久化双份落盘再搬，迁移窗口里缓冲开销的峰值容易顶爆目标机，容量按源机的峰值占用而不是平均值来留。

版本与迁移各一句

版本升级能吃到碎片整理与内存统计的改进，升级前在测试环境压一轮真实键分布，别拿空库测——碎片率与键大小强相关。实例迁移或扩容时按持久化双份落盘再搬，迁移窗口里缓冲开销的峰值容易顶爆目标机，容量按源机的峰值占用而不是平均值来留。

防复发三条

上限留余量：maxmemory 设到机器内存的六到七成，给编外支出留位；监控给碎片率与连接数设阈值；开发侧立规矩——禁 keys 全量扫描、大 value 拆分、读全量走从库游标化。贵州诚鑫致达科技处理过的缓存故障里，“设了上限还 OOM"的根因排名靠前的就是默认淘汰策略加碎片侵占——上限是给数据划的线，不是给进程划的线，这两条线的差距要看清楚。

企业存储选型参考｜贵州诚鑫致达

做机房存储、虚拟化或监控归档，群晖机型参考：FS6400（全闪存阵列） · SA3610 · SA3410。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。