📚 课程目录第4章写缓存策略对比

4. 写缓存策略对比：Cache-Aside、Read-Through、Write-Through、Write-Behind

在分布式缓存架构中，选择正确的写缓存策略直接决定了系统的数据一致性、延迟和吞吐量。本章深入对比四种主流策略：Cache-Aside、Read-Through、Write-Through 和 Write-Behind，从架构视角分析其适用场景与工程落地代价。

四种策略在“谁负责缓存与数据库的同步”、“写入时机”和“一致性保证”上存在本质区别。下表从多个维度进行横向对比：

维度	Cache-Aside	Read-Through	Write-Through	Write-Behind
应用代码职责	显式管理缓存读写	只读缓存，写操作由应用处理	缓存层代理写操作	缓存层异步写回数据库
数据一致性	最终一致（需处理并发写）	强一致（读路径）	强一致（同步写）	最终一致（异步写）
写延迟	低（只写数据库）	中（需回填缓存）	高（双写）	极低（仅写缓存）
数据库写入频率	每次写操作	每次写操作	每次写操作	批量/延迟写入
缓存穿透风险	低（按需加载）	低（缓存层自动加载）	低（缓存始终有数据）	中（异步窗口期）
实现复杂度	低	中	中	高（需队列、重试、幂等）

Cache-Aside 是最常见的策略，应用代码直接与缓存和数据库交互。读操作先查缓存，未命中则从数据库加载并回填缓存；写操作直接更新数据库，并删除或更新缓存中的旧数据。

  关键要点：写操作优先更新数据库，再使缓存失效（删除而非更新），以避免并发写导致的脏数据问题。

工程建议：Cache-Aside 适合读多写少的场景，如用户会话、配置信息。注意并发写时需配合分布式锁或版本号机制防止缓存与数据库不一致。

Read-Through 将“未命中时回填缓存”的逻辑从应用代码下沉到缓存层。应用只与缓存交互，缓存层内部负责从数据库加载数据并回填。写操作仍由应用直接处理数据库。

注意：Read-Through 的写操作仍需应用自行处理数据库更新和缓存失效。如果写操作频繁，建议配合 Write-Through 或 Write-Behind 使用，否则缓存层与数据库之间可能出现长时间不一致。

Write-Through 将写操作也委托给缓存层。应用只写缓存，缓存层同步将数据写入数据库。这种策略保证了缓存与数据库的强一致性，但写延迟较高（需等待数据库写入完成）。

  适用场景：Write-Through 适合对数据一致性要求极高的场景，如金融交易、订单状态更新。代价是写操作延迟增加，且缓存层成为写路径的瓶颈点。

Write-Behind 是 Write-Through 的异步变体。应用只写缓存，缓存层立即返回成功，然后异步批量将数据写入数据库。这种策略大幅降低了写延迟，但引入了数据丢失和一致性的风险。

风险提示：Write-Behind 在缓存宕机时可能丢失未持久化的数据。工程上必须实现：① 持久化队列（如 Kafka/RocketMQ）；② 幂等写入机制；③ 失败重试与死信处理；④ 数据校验与补偿任务。

在实际架构设计中，可以根据以下条件快速选择策略：

  混合策略实践：大型系统常组合使用多种策略。例如：读路径使用 Read-Through + 本地缓存，写路径使用 Write-Behind + 消息队列，关键数据（如支付）使用 Write-Through 保证强一致。

选择策略后，需要关注以下指标进行持续优化：

指标	Cache-Aside	Read-Through	Write-Through	Write-Behind
P99 写延迟	< 5ms	< 10ms	< 20ms	< 2ms
缓存命中率	95%+	98%+	99%+	97%+
数据丢失窗口	无	无	无	队列积压时间
数据库写入合并	不支持	不支持	不支持	支持批量合并

选择缓存策略没有银弹，必须结合业务场景、一致性要求、延迟预算和运维能力综合决策。在分布式系统中，没有绝对正确的策略，只有最适合当前服务边界的策略。