【Redis】key的设计格式
Redis 的 key 设计需遵循可读性高、易维护、避免冲突、便于扩展的原则，通常采用 “分层命名” 的方式，用分隔符（如:、_）划分不同维度，清晰体现 key 的业务含义。以下是详细设计规范及案例：
【1】key 设计通用规范
（1）命名格式：业务域:模块:主键:属性（层级从左到右由粗到细）
（2）分隔符：推荐用:（Redis 中无特殊含义，且视觉上更清晰）
（3）避免冗余：不包含无意义的固定前缀（如redis_）
（4）控制长度：key 不宜过长（影响内存和查询效率），通常不超过 64 字节
（5）区分大小写：Redis 的 key 区分大小写（如user:1和User:1是两个 key），建议统一小写
【2】详细案例（按业务场景分类）
（1）用户模块（user）
用户基本信息：业务域:用户ID:属性
user:1001:info → 存储用户 ID=1001 的完整信息（JSON 格式）
user:1001:name → 单独存储用户名（如需高频获取某个字段）
user:1001:phone → 单独存储手机号
用户关联数据：业务域:用户ID:关联类型
user:1001:orders → 存储用户 1001 的订单 ID 列表（List 结构）
user:1001:addresses → 存储用户 1001 的地址列表（Hash 或 List）
（2）订单模块（order）
订单基本信息：业务域:订单ID:属性
order:20230730001:info → 订单 20230730001 的完整信息
order:20230730001:status → 订单状态（如 “已支付”“已发货”）
订单与用户关联：业务域:关联维度:关联值
order:user:1001 → 用户 1001 的所有订单 ID 列表（便于查询用户的历史订单）
（3）商品模块（goods）
商品基本信息：业务域:商品ID:属性
goods:5001:info → 商品 5001 的完整信息（名称、价格、库存等）
goods:5001:stock → 商品 5001 的实时库存（高频更新字段，单独存储）
商品分类：业务域:分类ID:列表
goods:category:301 → 分类 ID=301 下的所有商品 ID 列表
（4）计数器 / 统计类
格式：业务域:统计维度:时间
login:count:20230730 → 2023 年 7 月 30 日的登录次数（用incr自增）
goods:view:5001:202307 → 商品 5001 在 2023 年 7 月的浏览量
（5）缓存与过期时间
临时数据需加过期时间（如验证码、令牌）：
verify☎️13800138000 → 手机号 13800138000 的验证码（设置 10 分钟过期）
token:user:1001 → 用户 1001 的登录令牌（设置 2 小时过期）
（6）集合类数据（List/Set/Hash）
Hash 结构：适合存储对象的多个字段（替代多个单 key）
user:1001（Hash 类型） → 字段name=“张三”，age=25，phone=“138xxx”
Set 结构：存储去重关联数据
user:1001:tags（Set 类型） → 元素 “学生”“会员”“新用户”
Sorted Set 结构：带权重的排序数据
goods:rank:sales（Sorted Set 类型） → 成员5001（商品 ID），分数1000（销量）
【3】反例（避免这样设计）
（1）无规则命名：abc123、userinfo（无法区分业务和主键）
（2）冗余前缀：redis_user_1001（redis是存储媒介，无需出现在 key 中）
（3）大小写混用：User:1001、user:1001（易冲突，不易维护）
（4）过长 key：mall:user:register:2023:07:30:1001:info（可简化为user:1001:info，时间维度通过其他 key 关联）
通过以上设计，既能清晰表达 key 的业务含义，又能方便后续维护和扩展，同时减少 key 冲突风险。