1.1 命名目标#

好的 Key 应同时满足：

• 唯一：不同环境、租户、业务和对象不会冲突；
• 可读：看到 Key 能快速判断归属和用途；
• 稳定：不把容易变化的展示字段写进 Key；
• 紧凑：避免无意义重复，降低内存、网络和持久化开销；
• 可治理：能按业务前缀统计、扫描、限流和迁移；
• 兼容 Cluster：需要共槽的 Key 提前规划 Hash Tag。

推荐格式：

1
业务:对象:标识[:维度]
2

3
示例：
4
shop:user:10086
5
shop:product:sku-123
6
shop:cart:{10086}:items
7
shop:cart:{10086}:meta

约定建议：

1.2 “44 字节”不是 Key 的硬限制#

一些旧资料建议 Key 不超过 44 字节，理由是 Redis 的 embstr 编码。这个结论不能直接用于 Key 设计：

1. embstr 阈值属于特定版本的 String 对象内部实现；
2. Redis 数据库 Key 和 Value 的对象组织、分配开销并不能简化为“Key 小于某值就一定省一次分配”；
3. 阈值和编码会随版本变化；
4. 可维护性与可观测性也有价值，不能为了省几个字节使用不可理解的缩写。

正确做法是：对高基数 Key 保持简洁，并在目标 Redis 版本、真实数据分布和真实 allocator 下，用 MEMORY USAGE 或离线样本测量。Key 多出 10 字节，在一亿个 Key 上就是约 1 GB 的原始字符差异，因此“大规模时短 Key 很重要”仍然成立，但没有统一的 44 字节红线。

1.3 不要把查询能力寄托在 Key 名上#

Redis 不是按 Key 前缀建立索引的关系数据库。生产请求中不要通过：

1
KEYS order:2026-08-04:*

来查询业务数据。KEYS 会遍历当前数据库，Key 多时会阻塞服务。替代方案：

• 明确 ID 直接访问；
• 用 Set/ZSet 维护业务索引；
• 用 Hash 组织同一聚合对象；
• 用 Redis Query Engine 等专用索引能力；
• 运维遍历使用 SCAN，并接受它的迭代语义。

1.4 TTL 是数据模型的一部分#

所有缓存 Key 在设计阶段都应回答“何时失效”：

1
# 写值和 TTL 一次完成，避免 SET 成功而 EXPIRE 失败
2
SET session:token-xxx payload EX 1800
3

4
# 对大量同周期缓存加入应用侧随机抖动，例如基础 1h + 0~10min

不要无条件续期。滑动过期会让长期活跃的垃圾数据永不释放，应结合业务状态和最大生命周期。

2.1 选择表#

2.2 String 与 Hash 如何选择#

假设存储一个用户：

1
方案 A：String
2
user:10086 -> JSON {name, age, city, ...}
3

4
方案 B：Hash
5
user:10086 -> name=Alice, age=28, city=Beijing, ...

不要为了减少 Key 数，把一个租户或一张表的所有数据塞入单个 Hash。Key 数减少了，但故障域、迁移成本、单线程处理时间和热点都会集中。

2.3 内部编码是优化细节，不是业务契约#

小型 Hash、Set、ZSet 等可能使用 listpack、intset 等紧凑编码，超过元素数或元素大小阈值后自动转换。Redis 7.0 及以后常见配置名包括：

1
hash-max-listpack-entries 512
2
hash-max-listpack-value 64
3
zset-max-listpack-entries 128
4
zset-max-listpack-value 64
5
set-max-intset-entries 512

旧版本可能使用带 ziplist 的配置名。注意：

• 默认值和可用项需以目标版本 redis.conf 为准；
• 把阈值调得很大可能省内存，但会增加线性扫描和编码转换成本；
• 先基准测试，再修改默认值；
• 用 OBJECT ENCODING key 观察编码，但应用逻辑不能依赖编码结果。

3.1 定义#

BigKey 不是“Key 名很长”，而是 Key 对应的 Value 占用大、成员多、单次操作耗时长或响应大。没有全行业统一阈值，应按类型分别定义：

真正阈值应来自：延迟 SLO、最大网络响应、复制/迁槽时间、内存预算、删除耗时和备份恢复时间。

3.2 危害#

1
写入/更新 BigKey
2
  → 主线程处理或复制大负载
3
  → AOF、复制链路、网络带宽升高
4

5
读取 BigKey
6
  → 大响应进入客户端输出缓冲区
7
  → 网络拥塞、慢消费者、内存突增
8

9
删除/过期 BigKey
10
  → 大量对象需要释放
11
  → DEL 可能阻塞；UNLINK 可异步释放但仍有调度和内存压力
12

13
Cluster 迁槽
14
  → BigKey 迁移时间长
15
  → 槽位重平衡尾延迟上升

3.3 发现 BigKey#

低风险到高精度的常见路径：

1
# 按类型扫描并报告较大的 Key/基数
2
redis-cli --bigkeys
3

4
# 关注内存占用；具体选项随 redis-cli 版本变化
5
redis-cli --memkeys
6
redis-cli --keystats

抽样检查：

1
TYPE some:key
2
STRLEN some:string
3
HLEN some:hash
4
LLEN some:list
5
SCARD some:set
6
ZCARD some:zset
7
XLEN some:stream
8
MEMORY USAGE some:key SAMPLES 5

注意事项：

• --bigkeys 主要按类型的长度/基数寻找大对象，不等于精确内存排行；
• MEMORY USAGE 对聚合类型会抽样，SAMPLES 0 全量采样可能昂贵；
• 在副本或离线环境做深度扫描，仍需评估 CPU、网络和缓存污染；
• 禁止通过生产 KEYS * 全量拉取后逐个检查；
• SCAN 的 COUNT 是提示，不保证每次返回固定条数。

3.4 SCAN 的正确语义#

1
cursor = 0
2
do:
3
    cursor, keys = SCAN cursor MATCH pattern COUNT hint
4
    处理本批 keys
5
until cursor == 0

必须接受：

• 单次调用近似 O(1)，完整遍历总体 O(N)；
• COUNT 只是工作量提示；
• 遍历期间数据变化时可能重复返回；调用方要能去重或幂等处理；
• 它不是一致性快照，不能据此做强一致账务统计；
• Cluster 中通常要对各主节点/槽范围执行，客户端行为需确认。

3.5 治理 BigKey#

Hash 分桶示例：

1
原模型：
2
user:all -> field=userId, value=userJson
3

4
分桶模型（bucket = stableHash(userId) mod 256）：
5
user:bucket:000
6
user:bucket:001
7
...
8
user:bucket:255

分桶数不是越多越好。应让单桶最大值有明确上限，并避免使用会在不同语言/进程变化的默认 hashCode。

3.6 安全删除#

1
UNLINK huge:key

UNLINK 会先从 Keyspace 解绑，再由后台线程释放多数内存，通常比 DEL 更不容易造成长阻塞。但它不是零成本：

• 从字典解绑仍需主线程工作；
• 短时间大量 UNLINK 会让后台释放堆积，内存下降滞后；
• 复制和 AOF 仍需传播删除命令；
• 如果业务不断重建该 Key，必须先停止写入或切换命名空间。

推荐流程：停止生产 → 重命名/版本切换隔离 → 小批删除或 UNLINK → 监控 RSS、lazyfree、延迟 → 验证回收。

4.1 识别#

• 应用侧按 Key/业务维度采样统计；
• 观察单分片 CPU、网络、命令量是否倾斜；
• 使用客户端代理或可观测平台的热点分析；
• 结合 INFO commandstats 判断热命令，但它不直接给出 Key；
• 生产使用 MONITOR 要极其谨慎，它会增加开销并暴露数据。

4.2 治理#

热点副本会引入一致性成本。对于强一致读取，不应仅靠随机副本解决。

5.1 购物车#

1
# 同一用户一个 Hash，field 是 sku，value 是数量
2
HSET cart:{10086}:items sku-1 2 sku-2 1
3
EXPIRE cart:{10086}:items 2592000

优点：字段级更新；同一用户相关 Key 可通过 {10086} 共槽。风险：超大购物车要限制商品数，不能用单个 {tenantId} 让全租户购物车集中到一个槽。

5.2 排行榜#

1
ZADD rank:daily:2026-08-04 980 user-1 870 user-2
2
ZREVRANGE rank:daily:2026-08-04 0 99 WITHSCORES
3
EXPIRE rank:daily:2026-08-04 604800

按天分 Key 控制规模；翻页越深成本越高，应限制最大页数或改用基于 score/member 的游标。

5.3 防止缓存雪崩#

1
错误：10 万个 Key 全部 TTL=3600，且同一秒写入
2
建议：TTL = 3600 + random(0, 600)

同时配合：预热、限流、熔断、分级缓存、回源并发合并。随机 TTL 只能打散过期时间，不能解决所有回源故障。