线上看 Redis 内存时，经常会遇到一个让人不安的问题：used_memory 已经降了，但进程 RSS 还高高挂着。这不是监控坏了，而是内存分配层的正常代价。
Redis 申请内存要经过分配器，小对象会进入 size class，对齐和复用都会产生碎片。数据删除后，内存也不一定立刻还给操作系统。
先把机制边界说清楚
这一篇讨论 Redis 进程内存和操作系统内存之间的差距，不把所有内存上涨都归因于碎片。先分清数据增长、复制缓冲、客户端输出缓冲和 allocator 碎片。
整体路径
上面这张图先把主线铺开：业务数据、分配器对齐、操作系统页不是同一件事。所以看 Redis 内存不能只盯 used_memory，RSS 和碎片率才是操作系统视角的真实账本。
底层机制
- used_memory 主要反映 Redis 分配出去的对象和缓冲区。
- RSS 是操作系统视角下进程占用的物理页，包含分配器（Redis 默认 jemalloc）保留但未归还的内存。
- 小对象频繁创建删除、value 大小变化、embstr/raw 转换都会影响碎片。碎片来源是 jemalloc 的 size class 对齐 padding 和小对象 slab 分配——即使删除了对象，分配器也往往把内存留在自己的池里以便复用，而不是立刻归还给操作系统。
- 判断碎片程度的核心指标是
INFO memory里的mem_fragmentation_ratio，等于used_memory_rss / used_memory。经验阈值：大于 1.5 就要关注（碎片接近一半），严重时（如 >2）要干预；小于 1 是另一种异常，通常意味着 overcommit（Swap 使用）或内存超卖，同样需要排查。 - 主动碎片整理
activedefrag（Redis 4.0+，依赖 jemalloc）能在运行时把碎片整理掉，但会消耗 CPU，不应无脑打开到激进参数。
内存碎片是性能和复用之间的代价。完全追求 RSS 下降，可能换来更多分配开销和延迟抖动。
取舍与边界
内存碎片是性能和复用之间的代价。完全追求 RSS 下降，可能换来更多分配开销和延迟抖动。
典型问题：用机制化例子排查
- 先看
INFO memory里的mem_fragmentation_ratio（关注 >1.5 或 <1 的异常），再结合业务写入删除模式判断。 - 大规模删除用
UNLINK或分批处理，避免阻塞和瞬时碎片波动。 - 容量规划预留碎片空间，不要按 payload 精确贴边部署。
- 碎片率异常时同时排查大 key、输出缓冲和后台 fork，不要只怪 jemalloc。
收束：一句判断
Redis 内存治理要看两本账：对象账和操作系统账。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
