Key 命名规范是什么
统一的键命名是运维、监控与排障的地基：推荐「环境:业务:对象:ID[:子资源]」的分层结构，用冒号分隔，长度尽量控制在 100 字节以内。集群环境下还需要用哈希标签（大括号）把必须同槽的键绑定在一起，让多键命令与事务可用；规范一旦确定就写进团队文档，并落到监控告警前缀与清理脚本的扫描模式上。
基本信息
| 适用版本 | Redis 全版本；哈希标签在 Cluster 模式生效 |
|---|---|
| 推荐结构 | <env>:<业务>:<对象>:<id>[:<子资源>] |
| 分隔符 | 统一用冒号，避免空格、换行与特殊字符 |
| 长度 | 尽量小于 100 字节，键名本身也占内存 |
| 环境前缀 | prod/test 前缀隔离，防误操作与串数据 |
| 哈希标签 | {} 内的内容参与分片计算，{} 外不参与 |
典型使用场景
- 集群多键操作：让同一实体的多个键落在同一槽，避免 CROSSSLOT
- 按前缀统计：用 SCAN 按业务前缀统计内存与键数量
- 清理与过期策略：按前缀批量清理测试数据或过期业务
- 权限隔离：结合 ACL 的键模式限制服务只能访问自己的前缀
- 故障定位：从键名一眼看出业务归属与所属环境
命名示例
命名示例
# 分层结构：环境:业务:对象:ID[:子资源]
prod:user:1001:profile
prod:order:20261012:1001
prod:rate:api:1001:202610121530
# 哈希标签：让相关键落同一槽（集群多键操作的前提）
{user:1001}:profile
{user:1001}:cart
# 按前缀统计（生产环境务必用 SCAN，不要用 KEYS）
SCAN 0 MATCH prod:user:* COUNT 1000
DBSIZE规范要点
| 要素 | 建议做法 | 原因 |
|---|---|---|
| 分隔符 | 统一冒号 | 便于脚本解析与人工阅读 |
| 层级 | 环境 → 业务 → 对象 → ID | 前缀统计与权限隔离都依赖它 |
| 长度 | 小于 100 字节 | 键名参与内存占用，长名在大键量下可观 |
| 字符集 | 仅字母数字与冒号连字符 | 特殊字符会干扰监控与脚本解析 |
| 哈希标签 | 只包住需要同槽的部分 | 标签范围过大导致数据倾斜 |
命名规范落地的三个检查点：监控告警是否按前缀区分业务、清理脚本的扫描模式是否匹配、容量报告能否按前缀统计内存。规范不落到工具链上，很快就会被新加入的服务绕过。
哈希标签滥用会造成严重的分片倾斜：如果所有键都带同一个标签前缀，整个集群的数据会挤到一个槽、一个节点上，集群的意义完全丧失。标签只包住「确实需要同槽」的实体标识。