2. 缓存基础与常见模式：穿透、击穿、雪崩与读写策略

缓存是后端系统中提升读取性能最直接的手段，但若使用不当，反而会成为系统稳定性的隐患。本章从两类问题（缓存失效引发的故障）和三类模式（数据同步策略）入手，建立缓存中间件调优的底层认知。

2.1 三大缓存失效问题

缓存穿透、缓存击穿、缓存雪崩是面试与生产故障中最常出现的三个概念，其本质都是“请求绕过缓存直接打到数据库”，但触发场景与影响范围截然不同。

2.1.1 缓存穿透

攻击者或异常请求持续查询一个数据库中也不存在的 ID（如 -1 或 99999999），缓存永远无法命中，每次请求都穿透到数据库。解决方案包括：

• 空值缓存：将数据库查询为空的 key 也写入缓存，TTL 设置较短（如 30~60 秒）。
• 布隆过滤器：在缓存层之前拦截一定不存在的 key，降低无效穿透。

2.1.2 缓存击穿

热点 key（如热搜、爆款商品）在过期瞬间，大量并发请求同时回源查询数据库。核心解决思路是互斥锁或逻辑过期：

• 互斥锁（Mutex）：只允许一个线程去数据库加载数据，其他线程等待或快速失败。
• 逻辑过期：缓存中额外存储一个过期时间字段，异步线程负责刷新，业务线程直接返回旧数据。

2.1.3 缓存雪崩

雪崩的破坏力最大。预防措施分为“预防过期”和“预防宕机”两个维度：

• 过期时间打散：在基础 TTL 上增加随机偏移（如 ±10%~20%），避免大量 key 同时过期。
• 缓存高可用：使用 Redis 哨兵或集群模式，避免单点故障。
• 限流降级：在数据库访问层增加限流，保护后端。

2.2 缓存数据同步三大模式

缓存与数据库之间的数据一致性是后端架构的核心难题。业界沉淀出三种经典模式：旁路缓存（Cache-Aside）、读写穿透（Read/Write-Through）、异步回写（Write-Behind）。

2.2.1 旁路缓存（Cache-Aside）

这是最常用的模式，应用代码显式管理缓存。读时先查缓存，未命中则查 DB 并回填；写时先更新 DB，然后删除缓存（而非更新），下次读时自然回填新数据。

// 旁路缓存 - 读流程（Java 伪代码）
public String get(String key) {
    String value = cache.get(key);
    if (value == null) {
        // 分布式锁防止击穿
        value = db.query(key);
        cache.set(key, value, 300); // TTL 300s
    }
    return value;
}

// 旁路缓存 - 写流程
public void update(String key, String newValue) {
    db.update(key, newValue);
    cache.del(key); // 删除缓存，而非更新
}

2.2.2 读写穿透（Read/Write-Through）

缓存层作为数据访问的唯一入口，应用不直接操作数据库。缓存组件内部封装了与 DB 的同步逻辑，对应用透明。这种模式通常需要自定义缓存中间件或使用支持该模式的缓存系统（如 Oracle Coherence）。

• Read-Through：缓存 miss 时，缓存层自动加载 DB 数据并返回。
• Write-Through：写请求先写缓存，缓存层同步写 DB，两者在同一个事务中完成。

2.2.3 异步回写（Write-Behind）

写操作只更新缓存，立即返回；缓存层异步批量合并后写入数据库。这种模式能极大提升写吞吐量，但存在数据丢失风险（缓存宕机时未落盘的数据会丢失）。

• 优点：写性能极高，适合日志、计数、埋点等场景。
• 缺点：数据一致性弱，需要配合持久化或 WAL（Write-Ahead Log）机制。

2.3 模式选型决策矩阵

在实际项目中，选择哪种模式取决于对一致性、吞吐量和实现复杂度的权衡。以下矩阵可作为选型参考：