1. 缓存闭环概述
什么是缓存闭环
缓存闭环是指围绕缓存数据的写入、更新与失效三个核心环节，形成一套可自洽、可追溯、可度量的数据生命周期管理机制。在 Redis 搜索缓存场景中，闭环意味着从业务请求发起、缓存命中/未命中、数据回写、一致性校验到缓存淘汰，所有路径都被显式定义，不存在“悬空”的缓存条目或不可控的过期行为。
核心定义：缓存闭环 = 写入策略 + 更新协议 + 失效触发器，三者缺一不可。
为什么需要缓存闭环
没有闭环的缓存系统会逐渐退化为“不可预测的加速层”，具体表现为：
- 数据不一致：数据库已变更，缓存仍返回旧值，用户看到过期搜索结果。
- 缓存穿透：大量请求绕过缓存直接打向数据库，导致后端过载。
- 内存泄漏：无效或废弃的缓存条目长期占用 Redis 内存，无法被及时淘汰。
- 运维黑盒：无法判断缓存命中率下降的原因，是写入策略问题还是失效策略失效。
| 问题 | 无闭环表现 | 闭环后效果 |
|---|---|---|
| 数据一致性 | 缓存与数据库长期偏离 | 写入即同步，失效即清除 |
| 缓存穿透 | 空结果未缓存，重复查询 | 空值占位 + 布隆过滤器 |
| 内存利用率 | 过期数据堆积 | TTL + 主动淘汰双保障 |
| 可观测性 | 命中率波动无解释 | 闭环日志可回溯每次操作 |
闭环的三大核心要素
缓存闭环由三个相互咬合的动作构成，任何一环缺失都会导致闭环断裂。
- 写入（Write） — 决定何时、以何种格式、在哪个层级写入缓存。包括：Cache-Aside 写入、Read-Through 写入、Write-Through 写入。
- 更新（Update） — 当数据源发生变更时，缓存如何同步。常见模式：双删 + 延迟双删、异步消息通知、CDC（Change Data Capture）监听。
- 失效（Invalidate） — 缓存条目何时被标记为不可用或直接删除。包括：TTL 到期、主动删除、LRU/LFU 淘汰、版本号比对失效。
实践要点：写入与更新是“正向”操作，失效是“逆向”操作。正向操作保证数据可用，逆向操作保证数据正确。闭环的健壮性取决于逆向操作的及时性与覆盖度。
闭环在搜索缓存中的特殊挑战
搜索缓存与普通键值缓存不同，其数据具有多维性和聚合性：
- 维度组合爆炸：搜索条件（关键词、分类、排序、分页）组合远多于单键查询。
- 聚合结果易失效：新增一条数据可能影响多个搜索结果页。
- 部分更新困难：搜索缓存通常是序列化后的完整结果集，无法像字段缓存那样做局部更新。
| 对比维度 | 普通键值缓存 | 搜索缓存 |
|---|---|---|
| 缓存键粒度 | 单实体 ID | 查询条件组合 |
| 失效影响范围 | 单条记录 | 可能波及多个分页/排序结果 |
| 更新策略 | 直接覆盖或删除 | 需重建索引或批量失效 |
| 写入成本 | 低（单次序列化） | 高（需执行完整搜索查询） |
常见误区：不要将搜索缓存的 TTL 设置得过长（如 1 小时以上），否则数据新鲜度会急剧下降。推荐初始 TTL 为 30~120 秒，配合主动失效机制使用。
闭环落地检查清单
在设计和评审搜索缓存方案时，建议逐项确认以下闭环完整性：
- ✅ 写入路径是否覆盖了所有可能的查询入口（精确搜索、模糊搜索、分页搜索）？
- ✅ 更新触发是否包含了数据源变更的所有场景（新增、修改、删除、批量导入）？
- ✅ 失效策略是否考虑了“写后即读”的一致性问题（是否需要延迟双删）？
- ✅ 是否对空结果和异常结果做了缓存占位，防止缓存穿透？
- ✅ 缓存键的设计是否包含了版本号或时间戳，支持主动比对失效？
推荐实践：在 Redis 中为每个搜索缓存条目额外存储一个
_meta 字段，记录写入时间戳和数据源版本号。失效时优先比对版本号，而非仅依赖 TTL。