Redis Key 和 Value 设计原则

设计 Redis 的 Key 和 Value 时，需要兼顾可读性、内存占用、访问效率和后续维护成本。

Key 应能清楚表达数据含义，便于排查和运维。

makefile 复制代码

user:1001:profile
order:20260807:12345
product:10086:stock

避免使用没有业务含义的 Key：

复制代码

a1b2c3d4

建议使用英文半角冒号 : 分隔业务层级，避免不同模块的 Key 冲突。

makefile 复制代码

user:1001:profile
user:1001:settings
cache:product:10086
session:token:abc123

Key 会占用内存，也会参与网络传输、持久化和日志输出，因此不宜过长。应在可读性和长度之间取得平衡，避免把完整 JSON、长 URL 等内容作为 Key。

建议 Key 主要由大小写字母、数字、冒号 :、下划线 _、连字符 - 和点号 . 组成，避免空格、控制字符和含义不明确的特殊字符。

缓存型 Key 应设置合理的 TTL，避免内存无限增长。

ruby 复制代码

SETEX cache:user:1001:profile 3600 "{...}"

实际使用中，可在基础过期时间上增加少量随机值，避免大量 Key 同时失效导致缓存雪崩。

若多个 Key 必须落在同一个槽位，以支持 Lua 脚本或多 Key 操作，可使用 {} 指定相同的 Hash Tag。

css 复制代码

cart:{1001}:items
cart:{1001}:total

arduino 复制代码

String：简单值、序列化对象、计数器
Hash：对象的多个字段
List：队列、按顺序的数据
Set：去重、标签、关系集合
ZSet：排行榜、按分数排序的数据
Stream：消息流和消费组

例如，频繁更新用户年龄、昵称等单个字段时，使用 Hash 往往比存储整段 JSON 更合适：

ruby 复制代码

HSET user:1001:profile name Alice age 18

大 Key 不仅指 String 的 Value 很大，也包括 List、Hash、Set、ZSet 等集合类型中元素数量过多的情况。

大 Key 可能导致网络传输慢、命令执行耗时长、删除阻塞、持久化压力增大，以及集群迁移困难。

应按日期、用户范围、业务维度或分片进行拆分：

makefile 复制代码

online-users:2026-08-07:shard:01
online-users:2026-08-07:shard:02

不要让单个 List、Hash、Set 或 ZSet 无限增长。对于日志、排行榜、消息、历史记录等数据，应设置长度上限、过期时间或按时间维度拆分。

临时数据、验证码、会话、缓存和限流计数等，应设置适当 TTL，以自动清理无效数据并控制内存使用。

对于较大的、压缩率高的文本或 JSON 数据，可在写入 Redis 前压缩，以减少内存和网络开销。但压缩和解压缩会消耗 CPU，因此需要结合实际压测决定。

Redis 会根据对象大小、元素数量等条件，自动选择更节省内存的内部编码。较新版本中常见的是 listpack 等紧凑结构。

应用开发中更应关注：

vbnet 复制代码

元素数量是否过多
单个元素是否过大
是否频繁随机访问或修改
是否需要拆分 Key

总结：Key 应做到"语义清晰、层级统一、长度适中、合理过期"；Value 应做到"选对数据类型、避免大 Key、控制集合规模、按需设置 TTL"。