3. 缓存基础知识回顾：缓存穿透、缓存击穿、缓存雪崩
在信用评分特征服务中，缓存是降低数据库压力、提升响应速度的核心手段。然而，若缓存策略设计不当，极易引发三类经典故障：缓存穿透、缓存击穿与缓存雪崩。本节将系统回顾三者的定义、成因及常规解决方案，为后续优化实战奠定理论基础。
3.1 缓存穿透
定义：查询一个根本不存在的数据，缓存和数据库中都查不到，导致每次请求都直接穿透缓存打到数据库。
成因：
- 恶意攻击或爬虫频繁请求不存在的用户ID、订单号等。
- 业务逻辑缺陷，未对非法参数进行前置校验。
- 缓存未对“空结果”做特殊处理，导致每次穿透。
常规解决方案：
| 方案 | 原理 | 适用场景 |
|---|---|---|
| 缓存空对象 | 对查询结果为null的key，也缓存一个短TTL的空值占位符 | 数据量不大，空值比例可控 |
| 布隆过滤器 | 将所有可能存在的数据哈希到一个bitmap中，请求先过过滤器 | 数据量大，内存敏感，允许极低误判率 |
| 参数校验 | 在API网关或服务入口拦截非法ID（如负数、超长字符串） | 所有场景，作为第一道防线 |
信用评分场景提示：用户画像查询中，若恶意请求大量不存在的用户ID，建议优先使用布隆过滤器前置拦截，避免缓存空对象占用过多内存。
3.2 缓存击穿
定义：一个热点key在缓存过期瞬间，大量并发请求同时涌入，全部穿透到数据库，导致数据库压力骤增。
成因：
- 热点数据（如头部用户评分、热门产品特征）缓存过期。
- 高并发场景下，多个线程同时发现缓存失效，同时回源查询。
- 没有互斥锁或分布式锁保护回源过程。
常规解决方案：
| 方案 | 原理 | 优缺点 |
|---|---|---|
| 互斥锁（Mutex） | 缓存失效后，只允许一个线程去数据库加载，其他线程等待 | 实现简单，但可能增加响应延迟 |
| 逻辑过期 | 缓存永不过期，但存储一个逻辑过期时间，异步刷新 | 无锁竞争，但需额外异步线程 |
| 热点数据永不过期 | 对极端热点数据设置极长TTL，配合后台定时更新 | 管理成本高，需保证数据一致性 |
信用评分场景提示：头部用户（如高净值客户）的评分特征key是典型热点。建议采用逻辑过期 + 异步刷新策略，避免锁等待影响用户体验。
3.3 缓存雪崩
定义：大量缓存key在同一时间集中过期，或缓存节点宕机，导致海量请求直接打到数据库，引发连锁故障。
成因：
- 批量加载缓存时设置了相同的过期时间（如统一凌晨过期）。
- 缓存服务集群整体宕机或网络分区。
- 缓存预热策略不当，导致重启后大量key同时失效。
常规解决方案：
| 方案 | 原理 | 实施要点 |
|---|---|---|
| 过期时间加随机值 | 在基础TTL上增加随机偏移（如±10%~30%） | 避免大量key同时过期 |
| 缓存集群高可用 | 使用Redis Sentinel/Cluster，避免单点故障 | 需额外运维成本 |
| 多级缓存 | 本地缓存（Caffeine）+ 分布式缓存（Redis）分层 | 本地缓存扛住第一波流量 |
| 限流降级 | 对数据库访问进行限流，超出阈值直接返回降级数据 | 保护数据库不被击穿 |
3.4 三种故障对比总结
| 故障类型 | 核心原因 | 影响范围 | 首选防御手段 |
|---|---|---|---|
| 缓存穿透 | 查询不存在的数据 | 单个key反复穿透 | 布隆过滤器 + 参数校验 |
| 缓存击穿 | 热点key过期瞬间高并发 | 单个热点key | 互斥锁 / 逻辑过期 |
| 缓存雪崩 | 大量key同时过期 / 缓存宕机 | 全局性故障 | TTL随机化 + 多级缓存 + 高可用 |
实战警示：信用评分特征服务中，三种故障可能并发出现。例如：凌晨批量刷新特征缓存时，若大量key同时过期（雪崩），其中热点key被高并发查询（击穿），同时恶意请求不存在的用户ID（穿透），将导致数据库瞬间崩溃。因此，必须组合使用上述方案，构建多层防护体系。