4. 缓存更新策略：Cache-Aside、Read/Write Through、Write Behind Caching 原理与对比

在高并发系统中，缓存与数据库之间的数据一致性是核心挑战。选择错误的更新策略可能导致缓存雪崩、数据不一致或性能瓶颈。本章深入剖析三种主流缓存更新策略的原理、适用场景与工程取舍。

4.1 策略全景与核心权衡

所有缓存更新策略都在解决同一个问题：当数据在数据库中发生变更时，如何同步更新缓存，以保证后续读取不会返回脏数据？ 三种策略的核心差异在于：谁负责协调写入顺序（应用还是缓存系统）以及写入是同步还是异步。

4.2 Cache-Aside（旁路缓存）

这是最广泛使用的策略，应用程序直接管理缓存与数据库的交互。核心原则是：读时回填，写时失效。

4.2.1 读流程

1. 应用先查询缓存。
2. 缓存命中（Cache Hit），直接返回数据。
3. 缓存未命中（Cache Miss），应用查询数据库。
4. 将数据库结果写入缓存，并设置过期时间（TTL）。
5. 返回数据给调用方。

4.2.2 写流程

1. 应用更新数据库（先写DB）。
2. 应用删除或失效缓存中的对应键（后删缓存）。

// Cache-Aside 写操作伪代码（正确顺序）
public void updateUser(User user) {
    // 1. 先更新数据库
    database.update(user);
    // 2. 再删除缓存（延迟双删可进一步保障）
    cache.delete("user:" + user.getId());
    // 可选：延迟几百毫秒后再删一次，应对主从延迟
}

4.2.3 适用场景

• 读多写少：缓存命中率高，写操作代价可控。
• 数据一致性要求不极端：允许短时间（TTL窗口内）的不一致。
• 缓存系统简单：如Redis/Memcached，无需额外代理层。

4.3 Read/Write Through（读写穿透）

缓存层充当数据库的代理，应用程序只与缓存交互，缓存负责与数据库同步。这种策略将一致性逻辑封装在缓存内部，对应用透明。

4.3.1 Read Through 流程

1. 应用请求缓存获取数据。
2. 缓存未命中时，缓存组件自动查询数据库。
3. 缓存组件将数据库结果写入自身，再返回给应用。
4. 应用无需感知数据库的存在。

4.3.2 Write Through 流程

1. 应用写入缓存。
2. 缓存组件同步将数据写入数据库。
3. 只有数据库写入成功，缓存才返回写入成功给应用。

4.3.3 适用场景

• 需要强一致性：如金融交易、库存扣减。
• 缓存系统提供代理能力：如使用支持Write Through的Redis模块或专用缓存中间件（如Apache Ignite、Hazelcast）。
• 应用希望解耦：团队希望将缓存策略下沉到基础设施层。

4.4 Write Behind Caching（异步回写）

与Write Through类似，应用只与缓存交互。但区别在于：写入缓存后立即返回成功，缓存异步批量将数据回写到数据库。这是性能最高的策略，但一致性最弱。

4.4.1 流程

1. 应用写入缓存。
2. 缓存将写入操作放入内部队列，立即返回成功。
3. 后台线程或定时任务批量将队列中的数据刷新到数据库。
4. 如果缓存宕机，队列中未刷新的数据可能丢失。

4.4.2 关键参数

4.5 三种策略对比总结

4.6 策略选择决策树

在实际架构设计中，可以按以下决策路径选择策略：

1. 是否需要强一致性？
   • 是 → 考虑 Read/Write Through。
   • 否 → 进入下一步。
2. 写并发是否极高？
   • 是 → 考虑 Write Behind（如日志、计数）。
   • 否 → 进入下一步。
3. 团队是否希望简化应用逻辑？
   • 是 → 考虑 Read/Write Through（引入缓存中间件）。
   • 否 → 使用 Cache-Aside（最灵活，最常用）。