2. 缓存更新策略：Cache-Aside、Read-Through、Write-Through、Write-Behind 模式详解与对比

在分布式缓存系统中，选择正确的缓存更新策略直接决定了系统的数据一致性、读写性能和架构复杂度。本章深入剖析四种主流缓存更新模式：Cache-Aside、Read-Through、Write-Through 和 Write-Behind，从工作原理、适用场景到一致性保障进行系统性对比。

2.1 Cache-Aside（旁路缓存）模式

Cache-Aside 是最常见、最灵活的缓存模式，应用程序直接同时管理缓存和数据库。读操作时先查缓存，未命中则回源数据库并回填缓存；写操作时先更新数据库，再删除缓存。

Cache-Aside 关键实现

// 读操作
public User getUser(String userId) {
    // 1. 先查缓存
    User user = cache.get("user:" + userId);
    if (user != null) {
        return user;
    }
    // 2. 缓存未命中，回源数据库
    user = db.query("SELECT * FROM users WHERE id = ?", userId);
    if (user != null) {
        // 3. 回填缓存，设置过期时间
        cache.set("user:" + userId, user, 3600);
    }
    return user;
}

// 写操作
public void updateUser(User user) {
    // 1. 先更新数据库
    db.execute("UPDATE users SET name = ? WHERE id = ?", user.getName(), user.getId());
    // 2. 再删除缓存（延迟淘汰）
    cache.del("user:" + user.getId());
}

2.2 Read-Through（穿透读）模式

Read-Through 将缓存层升级为“缓存代理”，应用只与缓存交互，缓存组件内部自动处理回源逻辑。当缓存未命中时，缓存服务自身负责从数据库加载数据并回填，对应用透明。

Read-Through 与 Cache-Aside 对比

2.3 Write-Through（穿透写）模式

Write-Through 模式要求写操作必须经过缓存层：应用先写入缓存，缓存组件同步将数据写入数据库。只有缓存和数据库都写入成功，写操作才算完成。这种模式保证了缓存与数据库的强一致性，但写延迟较高。

2.4 Write-Behind（异步写）模式

Write-Behind 模式（也称 Write-Back）采用异步写回策略：应用只写入缓存即返回成功，缓存组件在后台异步批量将数据写入数据库。这种模式极大降低了写延迟，但存在数据丢失风险。

2.5 四种模式综合对比

2.6 选型建议与避坑指南

• 优先选择 Cache-Aside：大多数业务场景的首选，灵活可控，社区资料丰富。配合延迟双删策略可进一步提升一致性。
• Read-Through 适合标准化团队：当多个微服务需要统一缓存访问模式时，通过缓存代理减少重复代码。
• Write-Through 用于强一致场景：如账户余额、库存扣减，但需接受写延迟增加。可配合本地事务保证缓存与数据库的原子性。
• Write-Behind 慎用：仅当业务能容忍数据丢失（如缓存宕机）且写性能是核心瓶颈时考虑。必须配置持久化缓存（如 Redis AOF）和故障恢复机制。