摘要：明明删了200万个Key，内存却纹丝不动？明明还有几百M空闲，却报OOM内存溢出？如果你正在被Redis内存碎片困扰，这篇文章就是为你准备的。本文不仅深度剖析碎片成因，更结合真实生产事故，手把手教你利用Redis 4.0+的自动清理机制，实现在线“无感”治理。
📋 目录
- 引言：那个被内存碎片“坑”惨的深夜
- 一、内存碎片是什么？一个租房的比喻
- 二、三个“元凶”导致了内存浪费
- 三、真实生产事故：那些年我们踩过的坑 🚨
- 四、如何诊断？一个命令秒查
- 五、核心机制：深入jemalloc的“智慧”
- 六、实战治理：三种方案全解析
- 七、最佳实践：从源头避免“发福”
- 八、写在最后
引言：那个被内存碎片“坑”惨的深夜
你是否经历过这样的绝望时刻：
- “假删除”：你小心翼翼地删除了Redis里几百MB的大Key，满怀期待地看监控，结果内存占用率纹丝不动。
- “伪OOM”：Redis显示还有几百MB内存可用，但写入新数据时却直接报错
OOM command not allowed when used memory。
如果你遇到过，或者正在经历，那么恭喜你（虽然有点幸灾乐祸），你遇到了Redis最隐蔽的“隐形杀手”——内存碎片（Memory Fragmentation）。
别担心，作为“卷毛的技术笔记”的老粉，你今天就能彻底搞懂它，并学会如何在不重启服务的情况下，把它清理干净。
一、内存碎片是什么？一个租房的比喻
为了让你秒懂，我们打个比方：
used_memory(Redis视角)：你家里实际家具的占地面积（比如80平米）。used_memory_rss(操作系统视角)：你租的整套房子的建筑面积（比如100平米）。
内存碎片率就是 RSS / used_memory。
- 内部碎片：你想租10平米的房间，但房东（内存分配器）最小只给16平米，剩下的6平米就是“内部碎片”。
- 外部碎片：你家里有很多小空隙（比如沙发缝、冰箱后），单个都很小，虽然总面积很大，但放不下一张新桌子。
二、内存碎片是怎么来的？
Redis默认使用 jemalloc 作为内存分配器。它为了性能，采用了固定大小分配的策略。
- 分配器的策略：程序申请20字节，jemalloc可能直接分配32字节。这多出来的12字节就是内部碎片。
- 频繁的删改：Redis是内存数据库，数据频繁过期、删除、修改大小。删除后留下的空洞，往往因为大小不匹配，无法被后续的新数据利用，变成了外部碎片。
- 数据结构设计：存储了大量大小差异巨大的Key（比如既有几KB的Token，又有几MB的JSON大对象），加剧了空洞的产生。
三、真实生产事故：那些年我们踩过的坑 🚨
为了让你更有代入感，我整理了三个基于真实场景的案例，看看你中了几个。
1. 事故现场：删了200万Key，内存却“诈尸”不降
- 场景描述：某业务在做数据迁移前，清理了Redis中约200万个无效Key（总量350万）。按理说内存应该释放几GB，但监控显示内存占用几乎没变。
- 排查心路：运维小哥当时满头大汗，以为是Redis内存泄漏了，甚至准备重启大法。
- 根本原因：外部碎片。删除Key只是将内存标记为“空闲”，并没有归还给操作系统。这些空闲内存被切成了无数细小的碎片，无法被复用，也无法被释放。
- 解决方案：开启Redis 4.0+的自动碎片清理（Active Defrag），内存逐步回落。
2. 事故现场：明明有内存，却报“内存不足”
- 场景描述：Redis配置的
maxmemory是4GB，监控显示used_memory只有3.5GB，还有500MB空间。但此时写入新数据直接报错OOM。 - 排查心路：这是最让人抓狂的“薛定谔的猫”。明明看着有内存，为什么不让写？
- 根本原因：伪OOM（假满）。此时
used_memory_rss（物理内存）可能已经膨胀到了4.5GB甚至更高。虽然逻辑上还有空间，但物理内存已经满了，且碎片化严重，jemalloc找不到一块连续的内存块来存放这个新Key。 - 解决方案：检查碎片率，如果大于1.5，立刻开启碎片整理。
3. 事故现场：大促期间，P99延迟突然飙升
- 场景描述：电商大促期间，购物车业务频繁修改（删旧加新），Redis内存碎片率从1.2飙升至2.0，接口响应变慢，P99延迟翻倍。
- 排查心路：业务方疯狂甩锅，以为是网络或代码逻辑问题。
- 根本原因：CPU消耗在找内存。碎片率过高导致Redis在分配内存时需要花费更多时间去查找合适的内存块，直接拖慢了请求处理速度。
- 解决方案：开启自动清理，并优化购物车数据结构（如设置过期时间、拆分大Key）。
四、如何诊断？一个命令秒查
别听那些复杂的理论，想知道有没有问题，一条命令就够了：
redis-cli info memory | grep -E "used_memory|mem_fragmentation_ratio"
重点关注指标：
| 指标 | 含义 | 你的关注点 |
|---|---|---|
used_memory | Redis数据实际占用 | 你的数据有多大 |
used_memory_rss | 操作系统给Redis的物理内存 | 你的服务器花了多少内存 |
mem_fragmentation_ratio | 内存碎片率 | 核心指标 |
碎片率解读表：
| 碎片率范围 | 状态 | 建议操作 |
|---|---|---|
| < 1.0 | ⚠️ 危险 | 内存不足，可能使用了Swap，需立即扩容或清理 |
| 1.0 ~ 1.2 | ✅ 健康 | 几乎无碎片，保持现状 |
| 1.2 ~ 1.5 | 🟡 预警 | 碎片开始产生，建议关注趋势 |
| > 1.5 | 🔴 严重 | 必须处理，存在OOM风险或性能下降 |
💡 提示：如果碎片率大于1.5，且
used_memory_rss远大于used_memory，说明你的Redis“虚胖”了。
五、核心机制：深入jemalloc的“智慧”
Redis为什么会有碎片？因为它用的“管家”叫 jemalloc。
- 预分配机制：jemalloc为了防止频繁向操作系统申请内存（太慢），会预先切好很多固定大小的“箱子”（如8B, 16B, 32B...）。
- 有舍有得：这种机制极大地提升了分配速度（性能高），但代价就是空间利用率。如果你的数据大小刚好卡在两个箱子中间，就会产生内部碎片。
虽然它是“罪魁祸首”，但它也是Redis高性能的基石。我们不能换掉它（除非你用tcmalloc），只能学会和它“共存”。
六、实战治理：三种方案全解析
遇到碎片率过高怎么办？这里有三个级别的解决方案。
方案一：重启大法（最简单粗暴）
- 原理：重启后Redis重新加载数据，内存重新紧凑排列。
- 缺点：服务中断，RDB/AOF加载慢，可能导致雪崩。
- 适用：低版本Redis（<4.0）或维护窗口期。
方案二：手动命令（辅助诊断）
- 命令：
MEMORY PURGE(Redis 6.0+) - 效果：尝试释放不再使用的内存页。
- 评价：效果有限，通常配合其他方案使用。
方案三：自动碎片清理（⭐ 强烈推荐）
这是Redis 4.0引入的“黑科技”，可以在不重启的情况下在线整理内存。
配置步骤（直接复制到redis.conf或用config set）：
# 1. 开启总开关
config set activedefrag yes
# 2. 设置触发门槛（必须同时满足）
# 碎片空间达到100MB才开始整理
config set active-defrag-ignore-bytes 100mb
# 碎片率超过10%才开始整理
config set active-defrag-threshold-lower 10
# 3. 设置CPU占用（保护业务）
# 整理时最少占用5% CPU
config set active-defrag-cycle-min 5
# 整理时最多占用25% CPU（防止抢走业务资源）
config set active-defrag-cycle-max 25
# 4. 高级设置（可选）
# 碎片率超过100%时，尽最大努力整理
config set active-defrag-threshold-upper 100
参数避坑指南：
active-defrag-ignore-bytes和active-defrag-threshold-lower是 “与” 的关系。必须两个条件都满足才会触发。- CPU是代价：自动整理是在主线程中执行的，会消耗CPU。所以在高峰期要控制
cycle-max，避免影响正常请求。
七、最佳实践：从源头避免“发福”
最好的治理是预防。在日常开发中，注意以下几点可以极大减少碎片：
- 统一数据大小：尽量避免在一个实例里存几KB的小字符串和几MB的大JSON。如果必须存大对象，请考虑拆分或使用其他存储。
- 善用过期时间：给临时数据（如Session、验证码）设置TTL，让Redis自动回收，减少手动删除产生的碎片。
- 批量操作：多用
MSET/MGET，少用单个SET/GET，减少内存分配次数。 - 监控告警：在Prometheus/Grafana中监控
mem_fragmentation_ratio，设置阈值（如>1.4）报警。
八、写在最后
Redis内存碎片就像家里的灰尘，看不见摸不着，但积少成多就会引发大问题。
通过今天的分享，你应该已经掌握了：
- 如何通过
INFO memory一眼识别碎片问题。 - 理解了 jemalloc 的内存分配逻辑。
- 学会了利用
activedefrag在线治理碎片，无需重启服务。
记住一句话：只要开启了自动碎片清理，并合理配置CPU上限，内存碎片就不再是你的噩梦。
本文首发于掘金/CSDN，作者：卷毛的技术笔记
📢 关注《卷毛的技术笔记》，获取《Redis避坑指南》指南
你好，我是卷毛。
在这个公众号里，我不讲晦涩难懂的理论，只分享经过生产环境验证的实战经验。
如果你厌倦了网上的“Ctrl+C/V”式教程，渴望看到真实场景下的技术拆解，欢迎扫码关注。
在这里，你将获得：
- 一线大厂的故障复盘：从事故中学架构。
- 硬核中间件调优：MySQL、Redis的深度使用技巧。
- Java进阶之路：源码分析与高并发设计模式。
关注我，让我们一起在代码的世界里“卷”出未来！
