📚 课程目录第2章缓存更新策略对比

2. 缓存更新策略对比：Cache-Aside、Read-Through、Write-Through、Write-Behind 原理与适用场景

在缓存一致性治理中，选择正确的更新策略是决定系统性能与数据一致性的核心决策。四种主流策略——Cache-Aside、Read-Through、Write-Through、Write-Behind——在读写路径、一致性保证、复杂度上各有取舍。本节从原理出发，结合适用场景进行系统性对比。

2.1 策略全景对比

策略	读路径	写路径	一致性保证	复杂度	典型延迟
Cache-Aside	应用先查缓存，miss 则查 DB 并回填	应用先写 DB，再删除/更新缓存	最终一致性（需处理并发写）	低	低（读 miss 时略高）
Read-Through	缓存层代理 DB 查询，自动回填	同 Cache-Aside 或委托缓存层	最终一致性	中	低（缓存层优化后）
Write-Through	同 Read-Through	缓存层同步写 DB，写成功后更新缓存	强一致性（写路径）	中	中（双写延迟）
Write-Behind	同 Read-Through	缓存层异步批量写 DB	弱一致性（有窗口期）	高	极低（异步落盘）

选型速判： 对一致性要求严苛（如金融交易）优先 Write-Through；对读多写少、允许短暂不一致（如内容详情页）选 Cache-Aside；对写吞吐极高、可接受异步落盘（如日志、计数）选 Write-Behind。

2.2 Cache-Aside（旁路缓存）

这是最广泛使用的策略，应用层直接管理缓存与数据库的交互。读操作先查缓存，未命中则查数据库并回填；写操作先更新数据库，再删除（或更新）缓存。

  适用场景： 读多写少、缓存命中率高的业务（如用户信息、商品详情）。应用层对缓存操作有完全控制权，便于定制化失效逻辑。

2.3 Read-Through（穿透读）

Read-Through 将“查 DB + 回填缓存”的逻辑下沉到缓存层（如 Redis 的 cache-aside 模式或使用缓存代理）。应用只与缓存交互，缓存层负责在 miss 时加载数据。

// 伪代码：Read-Through 缓存层逻辑
public Value load(String key) {
    Value val = cache.get(key);
    if (val == null) {
        // 缓存层自动查 DB 并回填
        val = database.query(key);
        cache.set(key, val, ttl);
    }
    return val;
}

优势： 应用代码简化，缓存层可统一实现回填策略、限流、熔断。适合微服务架构中多个消费者共享同一缓存层的场景。

2.4 Write-Through（穿透写）

Write-Through 要求缓存层在更新缓存的同时同步写入数据库，保证写路径的强一致性。应用只写缓存，缓存层代理双写。

避坑： Write-Through 不能解决“缓存与 DB 双写”的原子性问题。若缓存写成功但 DB 写失败，需引入补偿事务或回滚机制。生产环境常配合本地消息表或事务性发件箱模式使用。

2.5 Write-Behind（异步写回）

Write-Behind 将写操作先写入缓存，然后异步批量合并后写入数据库。缓存层作为写缓冲区，大幅降低 DB 写压力。

特性	Write-Behind	Write-Through
写延迟	极低（仅缓存写）	中（双写同步）
DB 写入模式	异步批量合并	同步逐条
数据丢失风险	高（缓存宕机未落盘）	低
一致性窗口	秒级到分钟级	无窗口
典型场景	日志、计数、埋点	订单、账户余额

// 伪代码：Write-Behind 异步合并写入
public void write(String key, Value val) {
    cache.set(key, val);  // 立即更新缓存
    writeBuffer.add(new WriteTask(key, val));  // 加入异步缓冲区
}

// 后台线程每 5 秒或积累 1000 条时批量刷 DB
ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
executor.scheduleAtFixedRate(() -> {
    List batch = writeBuffer.drainAll();
    database.batchUpsert(batch);  // 批量写入
}, 5, 5, TimeUnit.SECONDS);

  适用场景： 写吞吐极高、对数据一致性不敏感的业务。例如：用户行为日志、页面访问计数、实时推荐特征更新。需配合缓存持久化（如 Redis AOF/RDB）降低数据丢失风险。

2.6 策略选择决策树

以下决策树可帮助团队快速匹配业务需求与缓存策略：

实践建议： 大多数业务系统从 Cache-Aside 起步，当出现写瓶颈或需要统一缓存治理时，再逐步引入 Read-Through 或 Write-Behind。避免过早引入复杂策略增加运维成本。