很多内存估算会犯一个错误：只算 value 大小，不算 key 自己和 Redis 对象系统的开销。等到线上 used_memory 超出预期，才发现一个 key 远不只是那几个字节。
一个普通键值对至少会进入数据库字典，key 是 SDS，value 外面有 redisObject，可能还有过期字典里的 TTL 元数据。逻辑上的一条数据，物理上是一组结构。
先把机制边界说清楚
这一篇讲 keyspace 和对象模型，不重复展开每种数据类型的内部结构。目标是建立一个内存估算坐标：key 数、key 长度、value 编码和 TTL 都会影响成本。
整体路径
上面这张图先把主线铺开：redisDb.dict 连接 key SDS、redisObject 与底层编码。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- Redis 数据库核心是字典，key 指向 value 对象。
- redisObject 记录 type、encoding、LRU/LFU 元信息和 ptr，不同编码决定 ptr 指向什么。
- 设置 TTL 后，还会在 expires 字典里维护过期时间。
- 同样的业务数据，用不同 key 粒度和编码方式，内存账可能差很多。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
Redis 适合大量小对象，但「大量」不等于免费。key 越碎，元数据占比越高；value 越大，分配器对齐和碎片越明显。
典型问题：用机制化例子排查
- 容量规划按 key 数量、平均 key 长度、value 编码和 TTL 四项估算。
- 大量布尔或小字段不要拆成无数小 key，优先考虑 Hash、Bitmap 或 Set。
- 用抽样
MEMORY USAGE验证估算，而不是只看业务 payload。 - 命名规范要克制，key 可读和 key 过长之间要取平衡。
收束：一句判断
Redis 内存优化的第一步，是承认一个 key 不只是一个 key。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
