旁路缓存 (Cache Aside)

旁路缓存 (Cache Aside Pattern) 是目前最常用的缓存架构模式。在这种模式下，业务系统（应用层）负责维护数据库和缓存之间的同步关系，缓存只是作为数据库的一个“侧路”存在。

其核心思想是：以数据库为准，缓存仅作为加速访问的手段。

---

核心操作流程

一、读操作 (Read Path)

场景 1：缓存命中 (Cache Hit)

sequenceDiagram
    participant App as 应用程序
    participant Cache as 缓存

    App->>Cache: 1. 查询数据
    Cache-->>App: 2. 返回命中数据

场景 2：缓存失效 (Cache Miss)

sequenceDiagram
    participant App as 应用程序
    participant Cache as 缓存
    participant DB as 数据库

    App->>Cache: 1. 查询数据
    Cache-->>App: 2. 缓存中无数据 (Miss)
    App->>DB: 3. 读取数据库
    DB-->>App: 4. 返回原始数据
    App->>Cache: 5. 将数据回填至缓存
    App-->>App: 6. 返回结果给调用方

1. 查询缓存：应用程序先从缓存中查找数据。
2. 命中返回：如果缓存中有数据（Cache Hit），则直接返回结果。
3. 失效补偿：如果缓存中没有数据（Cache Miss）：
   • 从数据库中读取原始数据。
   • 将读取到的数据写入缓存，以便下次访问。
   • 返回数据给调用方。

二、写操作 (Write Path)

sequenceDiagram
    participant App as 应用程序
    participant Cache as 缓存
    participant DB as 数据库

    App->>DB: 1. 更新数据库
    App->>Cache: 2. 删除缓存 (Invalidate)

1. 更新数据库：先更新数据库中的数据。
2. 删除缓存：直接将缓存中对应的 Key 删除。

---

深度思考

在实际落地旁路缓存时，开发者通常需要权衡以下几个核心问题：

• 操作策略：为什么选择“删除”而非“更新”？
• 执行顺序：先更库还是先删缓存？顺序重要吗？
• 一致性增强：如何进一步保证双写一致性？

---

适用场景

维度	描述
读写比例	读多写少：如新闻资讯、商品详情等，缓存收益最大。
计算复杂度	数据计算逻辑复杂：缓存对象需经多表关联或聚合计算得到时，可显著降低 DB 负载。
空间利用率	冷热数据分明：仅加载热数据（Lazy Loading），节省内存空间。
架构灵活性	解耦要求高：缓存与数据库完全解耦，易于更换缓存介质。

---

总结

• 优点：实现简单，不存在“更新顺序”导致的并发安全问题，冷数据不会占用缓存空间。
• 缺点：在缓存失效或写操作频繁时，会有一次 Cache Miss 的性能开销。
• 核心结论：它是绝大多数通用业务场景下的首选缓存策略。