适用读者：要给 Redis 做容量规划、或定 key 命名规范的人。
前置：S12-A02、S12-B02。
覆盖旧文：866（Key 与 Value 设计原则，103 点）。
覆盖扩展：E-S12-017（容量估算公式）。
上一篇：S12-A02 · 热 Key 与大 Key 治理
下一篇：S12-X01 · 八股速查。

---

1. 一句话结论

Redis 的容量不是"数据大小"，是"数据 + 每个 key 的元数据开销（约 50–100 字节）"。key 命名规范决定可维护性，元数据决定成本。

---

2. Key 设计四条规范（A-866）

规范	示例	原因
业务前缀	user:profile:{id}	避免冲突、便于按业务清理
分隔符统一	统一用 :	可读、可解析
长度适中	20–50 字节	太长浪费（每个 key 都有开销）
避免热 key	见 A02	分布均匀

"user:123:name 还是 u123"：前者可读、可批量扫描（但注意 SCAN 匹配仍会扫全库）。

---

3. 容量估算（E-S12-017）

总内存 ≈ Σ(value 大小 + key 大小 + 元数据开销)

项	经验值
key + value 的元数据	约 50–100 字节/键
编码开销	listpack 更省（B02）
碎片率	mem_fragmentation_ratio 1.0–1.5 正常

举例（估算，非实测）：

100 万个 key，平均 key 30 B + value 100 B + 元数据 60 B
≈ 190 B × 1e6 ≈ 190 MB（未计碎片与复制/持久化开销）

"为什么要留冗余"：持久化（AOF buffer）、复制缓冲区、碎片都会额外占内存 —— 规划时常按 1.5–2 倍估。

---

4. Value 设计原则

原则	说明
别存大 JSON	读一次全量、改一次全量（大 key 风险）
用 hash 存对象字段	可单字段更新（但注意别变大 key）
数值用 string + INCR	原子计数
时间序列用 zset/Stream	按分数/时间取范围

---

5. 可观测性：三个必看指标

指标	含义	告警阈值（经验）
used_memory vs maxmemory	是否接近上限	> 80%
evicted_keys 增长	是否在丢数据	非 0 且持续增长
keyspace_hits/misses	命中率	命中率下降要查

"为什么 evicted_keys 最重要"：它意味着"缓存正在丢数据"（B03 实测 29,803 个）。

---

6. 五个误区

误区	真相
"容量=数据大小"	元数据开销不可忽略
"key 越短越好"	太短不可维护；20–50 字节合适
"命中率低是 Redis 的问题"	常是 TTL/热点设计问题
"碎片率无所谓"	> 1.5 要关注
"估算一次就够"	数据增长要复查

---

7. 自检（架构师版）

1. key 设计的四条规范？
2. 容量估算的三个组成部分？
3. 为什么规划要留 1.5–2 倍冗余？
4. 三个必看可观测指标？
5. evicted_keys 增长意味着什么？

---

8. 下一篇

S12-X01 · Redis 八股速查

最后一篇是附录：57 道 Redis 八股压成"题 → 一句话答案 → 正文位置"。

---

本篇属于系列《S12 · Redis 与缓存》。旧文来源：A-866；扩展点 E-S12-017。估算为经验公式（非实测）。