Redis 数据模型与契约：基本数据类型、键值对契约设计、数据序列化契约

在缓存架构中，数据模型的选择直接决定了系统的性能边界与维护成本。Redis 并非简单的“大 Map”，其每种数据类型都对应一种特定的数据结构与操作语义。本章将围绕 Redis 基本数据类型、键值对契约设计 和 数据序列化契约 三个核心维度，建立缓存数据模型的契约化设计方法。

2.1 Redis 基本数据类型与领域语义映射

Redis 提供了 5 种基本数据类型，每种类型都有其最适合的领域场景。将领域对象映射到正确的数据类型，是缓存契约设计的第一步。

2.2 键值对契约设计

键值对契约定义了缓存数据的 键命名规则、值结构约束 和 过期策略。这是缓存架构中最容易被忽视但影响最大的设计环节。

2.2.1 键命名契约

键名应具备 可读性、可分类性 和 唯一性。推荐采用 业务域:实体名:标识符:字段 的分层命名法。

# 推荐格式
user:profile:1001:name
order:detail:ORD20250301:status

# 反例（无层次、易冲突）
name1001
statusORD20250301

2.2.2 值结构契约

值结构契约定义了 字段类型、空值表示 和 边界值处理。对于 Hash 类型，字段名也应遵循命名规范。

# Hash 值结构契约示例
# 键：user:profile:1001
# 字段契约：
#   - name: string, 非空, 最大 50 字符
#   - age: integer, 0-150, 默认 0
#   - email: string, 可为空, 格式校验
#   - tags: JSON 数组字符串, 最大 10 个标签

HSET user:profile:1001 name "张三" age 28 email "zhangsan@example.com" tags '["vip","2024"]'

2.3 数据序列化契约

序列化契约决定了缓存数据的 存储格式、跨语言兼容性 和 版本演进能力。错误的序列化选择会导致数据无法读取或迁移困难。

2.3.1 序列化格式对比

2.3.2 序列化契约版本化

当缓存数据结构发生变化时，必须通过 序列化版本号 来标识不同格式，避免旧数据反序列化失败。

// 序列化契约版本化示例（JSON 方式）
{
  "_version": 2,
  "name": "张三",
  "age": 28,
  "email": "zhangsan@example.com",
  // v2 新增字段
  "phone": "13800138000"
}

// 反序列化时根据 _version 字段选择对应的解析逻辑
if (data._version === 1) {
  // 兼容旧版本
} else if (data._version === 2) {
  // 新版本处理
}

2.4 数据模型与契约关系总览

下图展示了 Redis 数据模型、键值对契约与序列化契约之间的整体关系，以及它们在缓存架构中的协作位置。

2.5 契约设计检查清单

在实际项目中，建议使用以下检查清单来验证缓存契约的完整性：

• 数据类型选择：是否选择了最匹配操作语义的数据类型？
• 键命名：是否遵循了 业务域:实体:ID 的分层规范？
• 键版本：是否在键名中嵌入了版本号以支持平滑迁移？
• 过期时间：是否所有缓存键都显式设置了 TTL？
• 值结构：是否定义了字段类型、空值处理和边界值约束？
• 序列化格式：是否选择了适合跨语言和版本演进的序列化方案？
• 版本标识：序列化数据中是否包含 _version 字段？
• 向后兼容：新增字段是否不会导致旧数据反序列化失败？