3. 缓存一致性挑战：缓存穿透、缓存击穿、缓存雪崩的定义与危害

在微服务与高并发架构中，缓存层是抵御数据库压力的第一道防线。然而，若缓存策略设计不当，极易引发三种经典故障模式：缓存穿透、缓存击穿与缓存雪崩。这三种现象虽名称相似，但成因、影响范围与治理手段截然不同。本节将逐一剖析其定义、触发场景及系统性危害。

3.1 三种故障模式的定义与对比

3.2 缓存穿透：空值与布隆过滤器

缓存穿透的危害在于：攻击者可以利用少量请求，持续消耗数据库连接资源。例如，一个恶意脚本不断请求 /user/info?id=-1，由于ID为负数，数据库永远返回空，缓存也永远不会写入，导致每次请求都直连数据库。

3.2.1 危害量化

• 数据库QPS飙升：正常缓存命中率从95%骤降至0%，数据库需承受全部请求量。
• 连接池阻塞：数据库连接数被无效查询占满，导致正常业务请求排队超时。
• 数据不一致风险：若穿透请求携带恶意参数，可能触发数据库异常SQL执行。

3.2.2 常见治理手段

• 缓存空对象：即使数据库返回空结果，也将其以短TTL（如30秒）写入缓存。后续相同请求直接返回空，避免穿透。
• 布隆过滤器（Bloom Filter）：在缓存层之前加一层位图过滤器，快速判断Key是否“可能存在”。若过滤器判定不存在，则直接拒绝请求。

3.3 缓存击穿：热点Key的互斥锁与逻辑过期

缓存击穿是“单点并发”问题。假设一个商品详情页的缓存Key product:1001 在10:00:00失效，此时有1000个并发请求同时到达。若不加控制，这1000个请求会同时查询数据库，导致数据库CPU瞬间飙高。

3.3.1 危害特征

• 瞬时热点：仅影响单个或少数几个热点Key，但该Key的访问量可能占整体流量的30%以上。
• 响应时间抖动：数据库查询耗时从1ms变为100ms，导致接口P99延迟大幅上升。
• 级联超时：下游服务因等待数据库响应而阻塞，可能引发线程池耗尽。

3.3.2 治理策略对比

3.4 缓存雪崩：批量失效与高可用

缓存雪崩是破坏力最强的故障模式。例如，开发环境将所有缓存Key的过期时间统一设置为1小时，那么每小时整点，数据库就会迎来一次请求洪峰。更严重的是，若Redis集群因网络分区或内存溢出而整体宕机，所有请求将瞬间压向数据库。

3.4.1 危害等级

• 数据库宕机：数据库无法承受10倍以上的瞬时流量，导致写入失败、主从延迟。
• 服务雪崩：数据库不可用 → 应用线程阻塞 → 上游服务超时 → 网关熔断 → 全站不可用。
• 数据丢失风险：在缓存与数据库双写不一致的情况下，雪崩可能导致部分数据未持久化。

3.4.2 预防与治理

• 过期时间打散：在基础TTL上增加随机偏移量（如 ±10%），避免大量Key同时失效。
• 缓存高可用：部署Redis Sentinel或Cluster模式，避免单点故障。
• 本地缓存兜底：在应用层使用Caffeine或Guava Cache作为二级缓存，即使Redis宕机，本地缓存仍可支撑部分读请求。
• 限流与熔断：对数据库访问接口实施限流，超出阈值直接返回降级响应。

3.5 三种故障模式的关系图

下图从请求流向的角度，直观展示缓存穿透、击穿与雪崩在系统架构中的位置与差异：

3.6 开发环境中的治理优先级

在Development环境中，由于流量规模远小于生产环境，治理重点应放在逻辑正确性验证与降级链路可观测性上。建议按以下优先级进行治理：

1. 第一优先级：缓存穿透治理 —— 最容易通过单元测试覆盖，且空对象缓存逻辑简单，适合作为缓存治理的入门实践。
2. 第二优先级：缓存雪崩预防 —— 通过配置随机过期时间与本地缓存兜底，避免开发环境因重启或数据刷新导致数据库被打满。
3. 第三优先级：缓存击穿治理 —— 热点Key在开发环境中不易复现，但可通过模拟并发请求来验证互斥锁或逻辑过期方案的稳定性。