1. 缓存闭环概述：搜索系统中的缓存角色、闭环定义、Redis在闭环中的核心位置
1.1 搜索系统的性能瓶颈与缓存引入
现代搜索系统面临的核心矛盾是：海量数据 × 高并发查询 × 毫秒级响应。直接穿透到后端存储（如 Elasticsearch、数据库）的每一次查询，都会带来磁盘 I/O、倒排索引合并、评分计算等高成本操作。当 QPS 达到万级甚至十万级时，后端存储会成为系统吞吐量的天花板。
缓存正是打破这一瓶颈的关键手段。通过在数据流路径中插入高速存储层，将热点查询结果、中间聚合数据、字典/倒排片段等“复用价值高”的数据暂存起来，从而大幅降低后端负载，缩短响应时间。
关键指标对比：
- 无缓存场景：P99 延迟 200~500ms，单机 QPS 上限 ~2000
- 引入 Redis 缓存后：P99 延迟 1~5ms，单机 QPS 可达 10 万+
- 缓存命中率每提升 10%，后端存储压力降低约 30%~50%
1.2 缓存闭环定义：从请求到回写的数据生命周期
“缓存闭环”不是简单的“查缓存→命中→返回”，而是一套覆盖数据写入、存储、查询、失效、回源、预热、一致性保障的完整数据生命周期管理机制。一个标准的搜索缓存闭环包含以下 6 个阶段：
| 阶段 | 动作 | 说明 |
|---|---|---|
| 1. 写入 | 数据进入缓存 | 首次查询回源后写入，或后台预热/订阅变更写入 |
| 2. 存储 | 数据结构化保存 | 选择合适的数据结构（String/Hash/ZSet/JSON） |
| 3. 查询 | 缓存命中/穿透 | 根据 key 模式快速检索，决定是否回源 |
| 4. 失效 | TTL 过期/主动淘汰 | 保证数据新鲜度，避免“脏缓存” |
| 5. 回源 | 穿透后加载数据 | 从 ES/DB 重新拉取，回填缓存 |
| 6. 预热 | 提前加载热点 | 系统启动或大促前主动构建缓存 |
闭环的核心价值在于：让每一次缓存操作都不是孤立的 get/set，而是可观测、可控制、可自愈的完整链路。
1.3 Redis 在闭环中的核心位置
在搜索缓存闭环中，Redis 处于“数据枢纽”的位置。它既不是最上游的数据源，也不是最下游的展示层，而是连接查询入口与后端存储的高速中间层。Redis 之所以能承担这一角色，源于以下 5 个核心能力：
- 微秒级延迟：纯内存操作，单次读写延迟通常在 0.1~1ms 之间
- 丰富的数据结构：String（缓存结果）、Hash（字段级缓存）、ZSet（热词排序）、Bloom Filter（缓存穿透防御）
- 高并发吞吐：单实例可达 10 万+ QPS，集群模式可线性扩展
- 过期与淘汰策略：TTL、LRU、LFU、Random 等，精准控制缓存生命周期
- 分布式一致性：主从复制、哨兵、Redis Cluster 保障高可用
实战经验：在搜索场景中，Redis 通常承载 3 类缓存：
① 查询结果缓存（key=query_hash, value=搜索结果 JSON）
② 字典/词典缓存（key=term, value=倒排列表指针）
③ 聚合统计缓存（key=agg_key, value=计数/排名数据）
① 查询结果缓存（key=query_hash, value=搜索结果 JSON）
② 字典/词典缓存（key=term, value=倒排列表指针）
③ 聚合统计缓存（key=agg_key, value=计数/排名数据）
1.4 搜索缓存闭环架构图
下图展示了搜索系统中 Redis 在缓存闭环中的完整位置与数据流向：
1.5 Redis 在闭环中的 4 个关键职责
| 职责 | 对应闭环阶段 | Redis 能力支撑 | 典型命令/结构 |
|---|---|---|---|
| 1. 查询加速 | 查询 | O(1) 键值查找，避免后端计算 | GET / MGET、HGETALL |
| 2. 穿透防御 | 查询 → 回源 | Bloom Filter 拦截不存在 key | BF.ADD / BF.EXISTS |
| 3. 数据回填 | 回源 → 写入 | 原子性写入 + TTL 设置 | SETEX、HSET + EXPIRE |
| 4. 失效管理 | 失效 | 主动淘汰 + 惰性删除 + 定期删除 | DEL、UNLINK、EXPIRE |
1.6 闭环设计的关键原则
- 数据一致性优先于缓存命中率：宁可缓存穿透，不可返回脏数据。使用 TTL + 版本号或订阅变更主动失效。
- 缓存粒度与搜索场景匹配：查询结果缓存适合短 TTL（秒级），词典/字典缓存适合长 TTL（小时级），聚合统计缓存使用 ZSet 增量更新。
- 闭环可观测：每个阶段都要有监控指标——命中率、回源率、缓存延迟、淘汰数量、内存使用率。
- 闭环可自愈：当 Redis 宕机或网络抖动时，搜索服务应降级为“直连后端”，恢复后自动预热重建缓存。
常见误区：很多团队只关注“缓存命中率”这一个指标，忽略了缓存闭环中的失效策略和一致性保障。结果出现“高命中率但搜索结果过时”的严重问题。缓存闭环的终极目标不是 100% 命中，而是 在可接受的一致性窗口内，最大化系统吞吐与响应速度。