3. 缓存基础理论：缓存穿透、缓存击穿、缓存雪崩的定义与解决方案
在构建高并发搜索系统时，缓存层是保护后端数据库与提升响应速度的第一道防线。然而，如果缓存策略设计不当，极易引发三种经典故障模式：缓存穿透、缓存击穿与缓存雪崩。本章将逐一剖析其成因、危害，并给出经过生产验证的解决方案。
3.1 缓存穿透
3.1.1 定义与成因
缓存穿透指查询一个根本不存在的数据，缓存层与数据库层均无法命中，导致每次请求都直接穿透到数据库。恶意攻击或大量无效查询可瞬间压垮数据库。
3.1.2 解决方案
| 方案 | 核心原理 | 适用场景 | 注意事项 |
|---|---|---|---|
| 缓存空对象 | 对查询结果为 null 的 key 也缓存一个短过期时间的空值 | 数据量不大，空 key 有限 | 需防范大量空 key 占用内存；设置较短 TTL |
| 布隆过滤器 | 在缓存前加一层 Bloom Filter，快速判断 key 是否存在 | 数据量大，空 key 多，对误判率容忍 | 需定期重建过滤器；存在小概率误判 |
| 参数校验与限流 | 对非法 ID（如负数、超长字符串）直接拒绝 | 所有场景 | 只能拦截明显非法请求，无法防御合法 ID 但数据不存在 |
生产建议：推荐组合使用“布隆过滤器 + 缓存空对象”。布隆过滤器拦截大部分不存在 key，少量误判请求由空对象缓存兜底，避免数据库压力。
3.2 缓存击穿
3.2.1 定义与成因
缓存击穿指一个热点 key 在缓存过期瞬间，大量并发请求同时涌入，全部穿透到数据库，导致数据库负载瞬间飙升甚至崩溃。
3.2.2 解决方案
- 互斥锁（Mutex Key）：当缓存失效时，只允许一个线程去数据库加载数据，其他线程等待或快速返回。适用于并发量极高且数据一致性要求严格的场景。
- 逻辑过期（主动续期）：缓存中不设置物理 TTL，而是存储一个逻辑过期时间。后台异步线程检测到逻辑过期后主动刷新缓存，避免热点 key 同时失效。
- 永不过期 + 后台更新：对顶级热点 key 设置为永不过期，由定时任务或消息队列异步更新缓存。适用于数据变更不频繁但访问量极大的场景。
关键对比：互斥锁方案会短暂阻塞请求，但能保证数据强一致；逻辑过期方案无阻塞，但存在短暂数据不一致窗口。搜索场景通常优先选择逻辑过期或后台更新，以保障高可用。
3.3 缓存雪崩
3.3.1 定义与成因
缓存雪崩指大量 key 同时过期，或缓存节点整体宕机，导致海量请求直接压向数据库，引发连锁故障。
3.3.2 解决方案
| 维度 | 具体措施 | 说明 |
|---|---|---|
| 过期策略 | 均匀过期：基础 TTL + 随机偏移 | 避免大量 key 在同一秒过期 |
| 多级过期：热点 key 设置不同 TTL 层级 | 核心数据 TTL 更长，次要数据更短 | |
| 高可用 | 缓存集群：主从 + 哨兵 / Redis Cluster | 单节点宕机不影响整体服务 |
| 本地缓存（L1 Cache）兜底 | 即使远端缓存全部失效，本地缓存仍可扛住部分流量 | |
| 限流降级 | 对数据库访问做熔断、限流、排队 | 保护数据库不被瞬间击垮 |
避坑提醒：很多团队只关注“均匀过期”而忽略了“缓存节点宕机”场景。务必为缓存层配置主从切换或集群分片，并配合本地缓存作为最后一道防线。
3.4 三种故障对比总览
| 故障类型 | 触发条件 | 影响范围 | 核心解决思路 |
|---|---|---|---|
| 缓存穿透 | 查询不存在的数据 | 单个 key 反复穿透 | 布隆过滤器 / 空对象缓存 |
| 缓存击穿 | 热点 key 过期瞬间高并发 | 单个热点 key | 互斥锁 / 逻辑过期 / 后台更新 |
| 缓存雪崩 | 大量 key 同时过期 / 缓存节点宕机 | 全局或大面积 | 均匀过期 + 高可用 + 限流降级 |
3.5 缓存故障防御架构图
3.6 本章小结
- 缓存穿透的核心在于“数据不存在”，解决方案是前置过滤（布隆过滤器）与空值兜底。
- 缓存击穿的核心在于“热点 key 过期瞬间”，解决方案是互斥锁或逻辑过期，避免并发穿透。
- 缓存雪崩的核心在于“大规模同时失效”，解决方案是均匀过期、高可用集群与限流降级三位一体。
- 在 Ent 搜索系统中，建议对元数据缓存采用“布隆过滤器 + 逻辑过期 + 本地缓存”的组合策略，以最低成本实现闭环缓存一致性。