Redis 大 Key 怎样拆分而不改变业务读取

Redis 大 Key 治理的关键不是把一个名字机械地改成三个名字，而是把存储布局藏在访问门面后面：业务仍然调用 GetProfile(userID)，门面再从多个小 Hash 读取并合并结果。这样可以降低单次操作的对象规模，也能把迁移、回滚和旧数据兼容控制在数据层。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/memory-optimization/

本文只讨论“一个对象内部字段过多或值过大”的大 Key，不讨论 Redis 实例整体内存不足，也不把 key 数量很多误认为单个大 Key。

先确认大 Key 到底大在哪里

先确认问题是字段数量、字段值大小，还是一次读取把所有字段都取出。Redis 官方文档说明，Hash 等聚合类型会根据规模采用不同的内部编码，因此拆分前要先看真实对象和真实访问路径，不能只凭 key 名称判断。

# 只测目标对象的近似内存占用，不要把整个实例的 used_memory 当成单个 Key 的大小
redis-cli MEMORY USAGE user:profile:10086 SAMPLES 0

# 查看字段数量，结合业务读取代码判断是否经常执行 HGETALL
redis-cli HLEN user:profile:10086

# 迁移前只抽取少量字段观察结构，避免用一次全量读取制造新的峰值
redis-cli HMGET user:profile:10086 name email locale

字段分组应按读取场景和变更频率划分。例如基础资料可以放入 user:{id}:base，联系方式放入 user:{id}:contact，偏好设置放入 user:{id}:preference。不要仅按字段名字母排序切片，否则后续读取仍然需要访问所有分片。

让读取门面屏蔽新的 Key 布局

存储拆分后，最容易破坏业务的是让每个调用方都知道新 key。更稳妥的做法是保留一个逻辑对象模型，由仓储层统一读取分组 Hash，再把结果合并为原来的返回结构。

type Profile struct {
    Name     string
    Email    string
    Locale   string
    Timezone string
    Theme    string
}

// GetProfile 只暴露逻辑对象；分片 key 的变化不会扩散到业务层。
func (r *ProfileRepo) GetProfile(ctx context.Context, id string) (Profile, error) {
    // 使用固定字段清单，避免 HGETALL 把不必要的大字段全部搬回应用。
    base, err := r.redis.HMGet(ctx, "user:"+id+":base", "name", "locale").Result()
    if err != nil {
        // 任一分片读取失败都返回错误，避免把半个对象当成完整对象。
        return Profile{}, err
    }
    contact, err := r.redis.HMGet(ctx, "user:"+id+":contact", "email", "timezone").Result()
    if err != nil {
        return Profile{}, err
    }
    preference, err := r.redis.HMGet(ctx, "user:"+id+":preference", "theme").Result()
    if err != nil {
        return Profile{}, err
    }

    // 只在门面内完成字段合并，业务调用方仍得到同一个 Profile。
    return Profile{
        Name: base[0], Locale: base[1],
        Email: contact[0], Timezone: contact[1],
        Theme: preference[0],
    }, nil
}

生产实现还要明确“缺字段”和“分片不存在”的区别。可选字段可以保留空值，但核心字段缺失时应返回未完成对象或触发回退读取；不要因为某个分片为空就静默覆盖缓存中的旧对象。

用双写和回填完成平滑迁移

不要先删除旧 Hash 再创建新 Hash。迁移期间可以让写入适配层同时写旧结构和新分组，后台任务分批从旧 Hash 读取字段并补到新 Hash，读取门面则按版本标记选择新结构，缺失时短暂回退旧结构。

# 迁移写入示例：同一用户的字段分别落到三个新 Hash；实际应用应通过事务或批量命令封装
MULTI
# 基础字段只写入 base 分片，便于按读取场景取数
HSET user:{10086}:base name "Lin" locale "zh-CN"
# 联系字段独立存放，修改邮箱时不触碰基础资料
HSET user:{10086}:contact email "lin@example.com" timezone "Asia/Shanghai"
# 偏好字段单独维护，避免一个对象持续膨胀
HSET user:{10086}:preference theme "dark"
# 版本标记供读取门面判断新结构是否已经准备好
SET user:{10086}:profile_schema v2
EXEC

示例中的 {10086} 是 Redis Cluster 的 hash tag，目的是让同一个用户的相关 key 落在同一槽位，便于需要事务边界时使用。若应用并不运行 Cluster，也不要把 hash tag 当成必须的命名格式。

回填任务必须可重复执行：按游标或字段清单分批处理，写入时保留统一的序列化规则，并记录成功、跳过和失败计数。切换前先确认新分片覆盖率达到目标，再把读取优先级切到新结构；观察一个完整业务周期后，才考虑下线旧 Hash。

TTL、Cluster 和删除边界不能漏掉

拆分后最容易出现的是过期时间失配。旧对象只有一个 TTL，而新对象有多个 key；写入适配层应把同一个过期策略同步到每个分片，回填也要按剩余 TTL 写入，不能让迁移任务把本应过期的数据重新变成长驻数据。

# 回填时把 TTL 当作迁移数据的一部分；没有 TTL 时不要凭空补一个过期时间
ttl=$(redis-cli TTL user:profile:10086)
if [ "$ttl" -gt 0 ]; then
  # 先写入分片，再把同一剩余秒数应用到全部新 key
  redis-cli EXPIRE user:{10086}:base "$ttl"
  redis-cli EXPIRE user:{10086}:contact "$ttl"
  redis-cli EXPIRE user:{10086}:preference "$ttl"
fi

# 旧 Key 下线优先使用异步删除，避免大对象同步释放阻塞主线程
redis-cli UNLINK user:profile:10086

如果某个字段需要独立过期，不能简单复制对象级 TTL，而应在数据模型中明确字段级有效期。对于 Cluster，多 key 操作还必须满足同槽位约束；如果不能满足，就把跨 key 一致性降级为应用层补偿，而不是假设一条事务能覆盖所有分片。

发布前用一张表确认是否真的拆对

最终目标不是让 key 数量越多越好，而是让一次读取只访问必要的字段组、一次写入只影响相关分片，并且在迁移失败时还能回退。若对象本身是一个必须原子替换的大 JSON，或者每次业务都必须全量读取全部字段，拆分带来的额外网络往返可能抵消收益，此时应先重新评估数据模型。

相关问题

拆成多个 Hash 后，业务读取是不是一定更快？

不一定。只有当读取路径能按场景减少字段和传输量时才更可能受益；如果每次都把全部分片读回来，网络往返和合并开销可能变大。

旧 Hash 什么时候可以删除？

新分片回填完成、读取门面稳定走新结构、关键业务周期观察完且具备回滚记录后再删除。删除前先保留迁移失败批次和版本标记。

为什么示例里要给 key 加大括号？

大括号是 Redis Cluster 的 hash tag 写法，可让同一用户的多个 key 使用同一槽位；单机 Redis 不需要依赖它，但统一命名有助于未来迁移。