4、主键索引设计：使用 String/Hash 构建主键索引，内存占用与查询性能对比

在 Redis 缓存索引设计中，主键索引是最基础也是最关键的索引类型。它直接决定了单条记录的存取效率与内存开销。本章深入对比 String 与 Hash 两种数据结构在构建主键索引时的内存占用、查询性能及适用场景，帮助你在实际架构中做出最优选择。

4.1 两种主键索引模型

假设我们需要缓存用户信息，每条记录包含 uid、name、age、city 四个字段。两种索引模型的核心差异在于：String 模型将整个对象序列化为一个值，而 Hash 模型将对象的每个字段独立存储。

对比维度 String 主键索引 Hash 主键索引
Key 结构 user:{uid} → 序列化 JSON user:{uid} → field:value 映射
写入命令 SET user:1001 '{"name":"Alice","age":30,"city":"BJ"}' HSET user:1001 name Alice age 30 city BJ
读取单字段 全量反序列化 → 解析 JSON → 取字段 HGET user:1001 name 直接返回
读取全量 GET + 反序列化 HGETALL 返回所有 field-value
更新单字段 全量读取 → 修改 → 全量写入 HSET user:1001 age 31 原地更新
内存开销 较低（单 Key + 单 Value） 较高（Key + 多个 field 元数据）
架构决策提示： 当业务场景以“全量读取”为主（如展示用户详情页），且字段数量较少（≤10 个）时，String 模型更省内存；当业务场景以“频繁更新单字段”或“读取部分字段”为主（如修改用户年龄、查询用户姓名），Hash 模型能显著降低网络开销与 CPU 序列化成本。

4.2 内存占用深度对比

Redis 的内存开销由 Key 对象、Value 对象 以及 元数据 三部分组成。我们以一个 4 字段用户对象为例，实测两种模型的内存差异。

4.2.1 String 模型内存结构

  • Key：user:1001（9 字节）→ SDS 对象 + dictEntry ≈ 56 字节
  • Value：JSON 序列化字符串 {"name":"Alice","age":30,"city":"BJ"}（约 40 字节）→ SDS 对象 + 实际数据 ≈ 72 字节
  • 总内存：约 128 字节

4.2.2 Hash 模型内存结构

  • Key：user:1001（9 字节）→ SDS 对象 + dictEntry ≈ 56 字节
  • Hash 对象：ziplist 或 hashtable 编码 + 4 个 field-value 对
  • field 与 value 各自存储：每个 field 和 value 都是独立的 SDS 对象
  • 总内存：约 200~240 字节（取决于 field 名称长度与编码方式）
字段数 String 模型（字节） Hash 模型（字节） Hash 额外开销比例
2 ~100 ~130 +30%
4 ~128 ~220 +72%
8 ~180 ~380 +111%
16 ~280 ~680 +143%
注意： 当 Hash 的 field 数量较少（<512 个）且每个 field 的 value 长度较短（<64 字节）时，Redis 会使用 ziplist 编码，内存效率接近 String 模型。一旦超过阈值，编码切换为 hashtable，内存开销会急剧上升。务必通过 hash-max-ziplist-entries 和 hash-max-ziplist-value 控制编码行为。

4.3 查询性能对比

性能对比需要区分 单字段读取、全量读取 和 单字段更新 三种场景。以下数据基于 Redis 6.2 单实例、100 万条用户数据、4 字段模型压测结果。

操作类型 String 模型（QPS） Hash 模型（QPS） 性能差异
单字段读取 ~45,000 ~85,000 Hash 快 89%
全量读取 ~42,000 ~38,000 String 快 11%
单字段更新 ~12,000 ~80,000 Hash 快 567%

性能差异原因分析：

  • 单字段读取：String 模型需要传输整个 JSON 字符串并在客户端反序列化，网络带宽和 CPU 开销远高于 Hash 的 HGET 直接返回。
  • 全量读取：String 模型只需一次 GET 命令，而 Hash 模型需要 HGETALL 遍历所有 field，当字段数较多时性能略低。
  • 单字段更新：String 模型必须执行“读取→反序列化→修改→序列化→写入”五步操作，而 Hash 模型只需一次 HSET，性能差距可达 5 倍以上。

4.4 主键索引选择决策树

以下 SVG 图展示了在不同业务特征下，如何选择 String 或 Hash 作为主键索引的数据结构。

主键索引数据结构选择决策树 主键索引设计 是否频繁更新单字段？ 是 → 推荐 Hash 模型 否 → 是否全量读取为主？ 是 → 推荐 String 模型 否 → 字段数是否 ≤10？ 是 → 推荐 String 模型 否 → 推荐 Hash 模型 决策说明： • 频繁更新单字段 → Hash 模型避免全量序列化开销 • 全量读取为主且字段少 → String 模型内存更优 • 字段数多且读写混合 → Hash 模型灵活性与性能平衡更好

4.5 实战案例：用户会话缓存

某社交应用需要缓存用户会话信息，包含 uid、token、login_time、expire_time、device_type、last_ip 共 6 个字段。业务特征如下：

  • 读取模式：每次请求需要读取全部 6 个字段（全量读取）
  • 更新模式：仅当 token 刷新或设备变更时更新单字段（低频更新）
  • 数据量：1000 万在线用户

方案对比：

指标 String 方案 Hash 方案
单条内存 ~160 字节 ~280 字节
1000 万条总内存 ~1.6 GB ~2.8 GB
全量读取延迟（P99） 0.8 ms 1.2 ms
单字段更新延迟（P99） 2.5 ms 0.6 ms
最终选型： 由于全量读取是绝对主流操作，且内存节省 1.2 GB 对成本影响显著，选择 String 模型。同时配合 SETEX 命令直接设置过期时间，简化代码逻辑。

4.6 编码与配置最佳实践

无论选择哪种模型，以下配置和编码规范能帮助你最大化性能与内存效率：

# redis.conf 关键配置
# 控制 Hash 编码为 ziplist 的阈值
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# 控制 String 大 Value 的阈值（超过后建议拆分）
# 建议单 Value 不超过 10 KB
# 可通过 bigkeys 扫描发现大 Key
// Java 客户端示例（Jedis）
// String 模型：使用 JSON 序列化
String key = "user:" + uid;
String json = objectMapper.writeValueAsString(user);
jedis.setex(key, 3600, json);

// Hash 模型：使用 field-value 映射
String key = "user:" + uid;
Map<String, String> fields = new HashMap<>();
fields.put("name", user.getName());
fields.put("age", String.valueOf(user.getAge()));
jedis.hset(key, fields);
jedis.expire(key, 3600);
避坑指南：
  • 不要将 Hash 的 field 名称设计过长（如使用完整字段名 user_name 而非 name），每个 field 名称都会占用内存。
  • String 模型下，避免使用 APPEND 或 SETRANGE 修改 JSON 片段，这会导致 Value 碎片化，增加内存占用。
  • 监控 used_memory_peak 和 mem_fragmentation_ratio，确保内存碎片率低于 1.5。

4.7 本章小结

场景 推荐模型 核心原因
全量读取为主，字段数 ≤10 String 内存占用低，单次 GET 即可完成
频繁更新单字段 Hash 避免全量序列化，HSET 原子更新
字段数多（>10），读写混合 Hash 灵活存取部分字段，减少网络传输
对象结构固定，极少修改 String 序列化一次，后续只读，内存最优

主键索引没有银弹。String 模型在内存效率和全量读取上占优，Hash 模型在字段级操作灵活性和更新性能上领先。架构师需要根据业务的实际读写比例、字段数量、更新频率做出权衡，并在编码阶段通过配置参数进一步优化底层存储结构。

← 上一章 📖 返回目录 下一章 →