线上看 Redis 内存时，经常会遇到一个让人不安的问题：used_memory 已经降了，但进程 RSS 还高高挂着。这不是监控坏了，而是内存分配层的正常代价。
Redis 申请内存要经过分配器，小对象会进入 size class，对齐和复用都会产生碎片。数据删除后，内存也不一定立刻还给操作系统。
先把机制边界说清楚
这一篇讨论 Redis 进程内存和操作系统内存之间的差距，不把所有内存上涨都归因于碎片。先分清数据增长、复制缓冲、客户端输出缓冲和 allocator 碎片。
整体路径
上面这张图先把主线铺开：业务数据、分配器对齐、操作系统页不是同一件事。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- used_memory 主要反映 Redis 分配出去的对象和缓冲区。
- RSS 是操作系统视角下进程占用的物理页，包含分配器保留但未归还的内存。
- 小对象频繁创建删除、value 大小变化、embstr/raw 转换都会影响碎片。
- 主动碎片整理能缓解部分问题，但会消耗 CPU，不应无脑打开到激进参数。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
内存碎片是性能和复用之间的代价。完全追求 RSS 下降，可能换来更多分配开销和延迟抖动。
典型问题：用机制化例子排查
- 先看
INFO memory里的 fragmentation 指标，再结合业务写入删除模式判断。 - 大规模删除用
UNLINK或分批处理，避免阻塞和瞬时碎片波动。 - 容量规划预留碎片空间，不要按 payload 精确贴边部署。
- 碎片率异常时同时排查大 key、输出缓冲和后台 fork，不要只怪 jemalloc。
收束：一句判断
Redis 内存治理要看两本账：对象账和操作系统账。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
