2. 缓存更新策略全景：Cache-Aside、Read-Through、Write-Through、Write-Behind 对比

缓存更新策略决定了数据在缓存与数据库之间如何同步，直接影响到读/写延迟、一致性等级和系统复杂度。本章从边界、分层、组件职责、数据流/控制流、信任链路、选型权衡、风险点、落地步骤与验收标准九个维度，逐一拆解四种主流策略：Cache-Aside、Read-Through、Write-Through、Write-Behind。

2.1 问题边界：为什么需要显式更新策略？

引入缓存后，数据在缓存和数据库之间存在两个副本。如果不定义更新策略，就会出现缓存与数据库数据不一致：读请求可能命中陈旧数据，写请求可能只更新了其中一个副本。策略的核心目标是在读性能、写性能和一致性等级之间取得可接受的平衡。

2.2 策略全景：四类策略的组件职责与数据流

2.2.1 Cache-Aside（旁路缓存）

组件职责：应用程序负责所有读写逻辑；缓存层只做键值存取；数据库层负责持久化。

• 读路径：应用先查缓存 → 命中则返回；未命中则查数据库 → 将结果写入缓存 → 返回。
• 写路径：应用先更新数据库 → 然后使缓存失效（Delete）或更新缓存。
• 信任链路：应用完全控制缓存与数据库的操作顺序，缓存失效由应用显式触发。

# 读流程伪码
val = cache.get(key)
if val is None:
    val = db.read(key)
    cache.set(key, val, ttl=300)
return val

# 写流程伪码（常用失效模式）
db.write(key, newVal)
cache.delete(key)        # 使缓存失效，而非直接更新

2.2.2 Read-Through（穿透读）

组件职责：缓存层承担回源加载职责；应用只需与缓存交互；缓存内部集成回源组件（Cache Loader）。

• 读路径：应用请求缓存 → 缓存未命中 → 缓存调用回源组件加载数据库数据 → 存入缓存 → 返回给应用。
• 写路径：应用直接写数据库（或同样经过缓存），缓存通常由数据库变更事件触发失效。
• 信任链路：应用信任缓存层完成回源；缓存层需要与数据库建立连接。

# 缓存层内部逻辑（以 Redis 企业版或 EVCache 为例）
on_cache_miss(key):
    value = db.load(key)          # 回源加载
    cache.set(key, value, ttl)
    return value

2.2.3 Write-Through（穿透写）

组件职责：缓存层同时处理读和写；应用只与缓存交互；缓存负责同步写入数据库。

• 写路径：应用写缓存 → 缓存同步写数据库 → 数据库确认后 → 缓存返回成功。
• 读路径：应用读缓存（可配合 Read-Through）。
• 信任链路：缓存层代理所有数据库写操作；应用必须信任缓存层的写可靠性。

# 缓存层写流程
on_write(key, value):
    db.write(key, value)          # 同步写数据库
    cache.set(key, value)         # 更新本地缓存
    return OK

2.2.4 Write-Behind（异步回写）

组件职责：缓存层接收写请求后立即返回；异步队列/线程批量或延迟写入数据库。

• 写路径：应用写缓存 → 缓存立即返回成功 → 后台任务合并/延迟写入数据库。
• 读路径：应用读缓存（可配合 Read-Through）。
• 信任链路：应用容忍短暂数据丢失风险；缓存层需要持久化队列保证不丢消息。

# 异步回写组件
on_write(key, value):
    cache.set(key, value)
    write_behind_queue.push((key, value))   # 异步入队
    return OK

# 后台消费者
while True:
    batch = write_behind_queue.pop_batch()
    db.batch_write(batch)

2.3 策略对比总表

2.4 选型权衡：从一致性、延迟与成本出发

• 一致性等级：Write-Through 提供写后读强一致；Cache-Aside 和 Read-Through 提供最终一致；Write-Behind 最终一致且窗口期最长。
• 写吞吐：Write-Behind 最高（异步合并写库）；Write-Through 最低（每次写都双写）。
• 缓存污染风险：Cache-Aside 写后失效可防止脏数据残留；Write-Through 和 Write-Behind 直接更新缓存，需配合版本号或 CAS 防并发覆盖。
• 运维成本：Cache-Aside 无需额外组件；Write-Behind 需要引入消息队列或 WAL，增加故障域。

2.5 风险点与应对措施

2.6 落地步骤建议

1. 评估一致性需求：与业务方确认可接受的最大不一致窗口。
2. 选定主策略：根据读/写比例、延迟要求选择主策略（如 Cache-Aside + 按需失效）。
3. 定义缓存失效契约：明确哪些操作触发失效（Delete vs Update），以及 TTL 上限。
4. 实现回源/回写组件：对于 Read-Through/Write-Behind，封装统一的回源 Loader 和异步 Writer。
5. 注入可观测性：监控缓存命中率、回源延迟、写队列积压、异常失效次数。
6. 混沌测试：模拟缓存节点宕机、网络分区、高并发回源场景，验证一致性边界。

2.7 验收标准

• 一致性检查：在连续写后立即读，缓存值与数据库一致（Write-Through 要求 100% 一致，其他策略允许 TTL 窗口内最终一致）。
• 延迟指标：P99 读延迟 < 5ms（缓存命中），P99 写延迟符合策略预期（Cache-Aside < 20ms，Write-Behind < 2ms）。
• 缓存命中率：稳定在 95% 以上（Read-Through/Cache-Aside 在正常负载下）。
• 故障恢复：缓存节点重启后，热数据能在 1 个 TTL 内自动回源，不产生长时间空洞。
• 数据零丢失：Write-Behind 模式下，缓存进程崩溃后未回写数据可从持久化队列恢复，丢失量 < 1 条（需提供审计日志）。

2.8 组合策略与迁移路径

实际生产环境通常混合使用多种策略：

• 热点数据：Read-Through + Write-Through 保证强一致；
• 非核心数据：Cache-Aside + TTL 最终一致；
• 日志/监控类数据：Write-Behind 异步回写，容忍丢失。

从简单策略向复杂策略迁移时，建议先做读策略升级（Cache-Aside → Read-Through），稳定后再引入写策略升级（Cache-Aside → Write-Through → Write-Behind），每一步都需要验证一致性 SLA 和延迟预算。