3. 支付订单缓存设计原则
支付订单的缓存设计直接决定了系统的吞吐能力、数据一致性和故障恢复速度。本章从 缓存Key规范、过期时间策略 和 缓存粒度选择 三个维度，给出可落地的设计原则与工程实践。
3.1 缓存Key设计规范
支付订单的缓存Key必须满足 全局唯一、可反查、防冲突 三个基本要求。推荐采用 业务前缀 + 域 + 标识符 + 版本号 的分段式结构。
| 分段 | 示例值 | 说明 |
|---|---|---|
| 业务前缀 | pay |
区分业务线，避免与其他模块Key冲突 |
| 域 | order |
标识资源类型，如订单、退款单、对账单 |
| 标识符 | 20250315001 |
订单号、用户ID或商户ID，保证唯一性 |
| 版本号 | v2 |
用于缓存结构升级时的平滑迁移 |
规范示例：
pay:order:20250315001:v2 // 单笔订单缓存
pay:user:10086:orders:v2 // 用户订单列表缓存
pay:merchant:merchant_001:orders:v2 // 商户订单列表缓存
避坑提示：禁止使用
order_id 作为唯一Key而不加前缀。当多个业务线共用同一Redis集群时，无前缀的Key极易发生覆盖，导致缓存数据错乱。
3.2 过期时间策略
支付订单的过期时间需要平衡 缓存命中率 与 数据时效性。根据订单状态的不同阶段，应采用差异化的TTL策略。
| 订单状态 | 推荐TTL | 策略说明 |
|---|---|---|
| 待支付 | 15分钟 | 与支付超时时间对齐，超时后自动失效 |
| 支付中 | 5分钟 | 高频轮询状态，短TTL防止脏数据滞留 |
| 支付成功 | 1小时 | 用户频繁查看，但最终一致性要求不高 |
| 已退款/已关闭 | 30分钟 | 终态数据，短TTL释放内存 |
关键原则：所有缓存必须设置 绝对过期时间，禁止使用永不过期。同时配合 主动失效 机制——当订单状态变更时，立即删除对应缓存Key，由下一次读取重新加载。
3.3 缓存粒度选择
缓存粒度决定了每次查询的 数据量 和 缓存更新成本。支付订单场景下，通常有三种粒度可选：订单级、用户级、商户级。
| 粒度 | Key示例 | 适用场景 | 优缺点 |
|---|---|---|---|
| 订单级 | pay:order:{order_id} |
单笔订单详情查询 | 优点：更新成本低，只影响单个订单 缺点：批量查询需多次IO |
| 用户级 | pay:user:{user_id}:orders |
用户订单列表、我的订单页 | 优点：一次查询返回全部订单 缺点：任一订单变更需更新整个列表 |
| 商户级 | pay:merchant:{merchant_id}:orders |
商户后台、对账系统 | 优点：适合商户维度的批量查询 缺点：数据量大，缓存更新延迟高 |
推荐组合策略：
- 订单级 作为基础粒度，保证单笔查询的实时性。
- 用户级 作为列表缓存，设置较短TTL（如5分钟），并采用 增量更新 而非全量替换。
- 商户级 仅在后台管理场景使用，配合 分页缓存 和 异步刷新 避免大Key问题。
工程建议：在支付订单场景中，优先采用 订单级 + 用户级 的双层缓存架构。订单级保证单笔查询的实时性，用户级提升列表页的响应速度。商户级缓存仅在后台管理系统中启用，且必须设置 最大条目数限制 和 惰性淘汰 机制，防止内存溢出。