📚 课程目录第1章缓存一致性概述

1. 缓存一致性概述

1.1 缓存一致性问题定义

在分布式后端系统中，缓存一致性是指缓存层与底层数据源（如数据库、外部服务）之间数据状态的对等程度。当业务数据发生变更时，若缓存未能同步更新，就会产生缓存与数据源之间的数据偏差，即缓存一致性问题。

  核心矛盾：缓存层追求高性能（低延迟、高吞吐），数据源追求高可靠（持久化、事务性）。两者之间的同步延迟或失败，直接导致用户读到“过期数据”或“脏数据”。

缓存一致性问题通常表现为以下三类场景：

场景	描述	典型后果
缓存穿透	查询一个不存在的数据，缓存未命中，请求直接打到数据库	数据库压力激增，可能引发雪崩
缓存击穿	热点 key 在失效瞬间，大量并发请求同时回源	数据库单点过载，响应超时
缓存雪崩	大量缓存 key 在同一时间过期或缓存节点宕机	数据库被洪水般请求冲垮
缓存与数据库双写不一致	写操作同时更新缓存和数据库，因时序或失败导致数据不同步	用户读到旧数据或数据丢失

1.2 CAP 理论在缓存中的应用

CAP 理论是分布式系统设计的基石，它指出一个分布式系统在一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）三者中最多只能同时满足两个。在缓存场景中，CAP 的权衡直接影响架构选型。

C（一致性）：所有节点在同一时刻看到相同的数据。在缓存中，意味着缓存与数据库数据完全同步。
A（可用性）：每个请求都能获得一个非错误的响应。在缓存中，意味着缓存服务始终可读可写。
P（分区容错性）：系统在网络分区（节点间通信中断）时仍能正常运行。在缓存中，意味着缓存集群在部分节点失联时仍能提供服务。

缓存架构的典型取舍：
• CP 系统（如 ZooKeeper、Etcd）：优先保证一致性，牺牲部分可用性。适用于配置中心、分布式锁等场景。
• AP 系统（如 Redis Cluster 默认模式、CDN）：优先保证可用性，允许短暂不一致。适用于高并发读、用户会话等场景。
• CA 系统：在分布式缓存中几乎不存在，因为网络分区是常态，必须容忍 P。

下图展示了 CAP 理论在缓存系统中的三种典型架构选择：

1.3 最终一致性与强一致性对比

在缓存一致性设计中，强一致性和最终一致性是两种最核心的模型。选择哪种模型，直接决定了系统的复杂度、性能和可用性。

对比维度	强一致性	最终一致性
定义	写操作完成后，任何后续读操作都能立即读到最新数据	写操作完成后，系统保证在一段时间后所有读操作都能读到最新数据
延迟	高（需要同步等待所有副本确认）	低（异步复制，无需等待）
吞吐量	低（串行化或锁机制）	高（无锁或乐观并发）
可用性	较低（部分节点故障可能导致写失败）	高（容忍节点故障，异步补偿）
实现复杂度	高（需要分布式锁、事务、共识算法）	中等（需要版本号、补偿机制、重试队列）
典型场景	金融交易、库存扣减、配置下发	用户资料、新闻 feed、商品详情
缓存策略	Write-Through / 同步双写	Cache-Aside / 异步回写

安全合规视角：在涉及资金、合同、用户隐私等强监管数据时，必须采用强一致性模型或通过分布式事务（如 TCC、Saga）保证最终一致性下的数据不丢失。仅靠缓存异步回写可能导致合规审计失败。

下图展示了两种一致性模型在缓存读写流程中的核心差异：

1.4 一致性模型选择决策树

在实际项目中，选择强一致性还是最终一致性，可以依据以下决策路径：

数据是否涉及资金、合同或法律合规？ → 是 → 强一致性（分布式事务 + 缓存同步锁）
数据是否允许短暂过期（秒级）？ → 否 → 强一致性（Write-Through 或 Read-Through + 锁）
系统是否要求高可用（99.99%+）？ → 是 → 最终一致性（Cache-Aside + 异步补偿）
写并发是否极高（万级 QPS）？ → 是 → 最终一致性（异步队列 + 版本号）
默认选择：大多数业务场景推荐 Cache-Aside + 最终一致性，配合补偿机制保证数据不丢失。

最佳实践：在同一个系统中，可以混合使用两种模型。例如：订单金额使用强一致性（Redis 分布式锁 + 数据库事务），而商品描述使用最终一致性（缓存异步更新 + 定期对账）。这种“分层一致性”策略在大型电商系统中被广泛采用。