1. 缓存一致性概述
1.1 缓存一致性问题定义
在分布式系统与多级缓存架构中，缓存一致性是指缓存节点中的数据与数据源（数据库、上游服务）中的数据在任意时刻保持逻辑等价的状态。当数据源发生写操作后，缓存中对应的副本若未同步更新，即产生数据不一致。
核心矛盾：缓存通过牺牲强一致性来换取低延迟与高吞吐。一致性越强，性能损耗越大；性能越高，不一致窗口越宽。
缓存一致性问题通常表现为以下三类场景：
| 场景 | 描述 | 典型后果 |
|---|---|---|
| 脏读 | 缓存中保留已过期的旧数据，新写入未及时生效 | 用户看到错误信息，业务逻辑出错 |
| 不可重复读 | 同一请求内多次读取缓存，结果不一致 | 事务内数据状态混乱 |
| 缓存穿透 | 缓存与数据库均无数据，请求直接打到数据库 | 数据库压力激增，缓存失效 |
1.2 CAP 理论在缓存中的体现
CAP 理论指出，分布式系统在一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者中最多同时满足两项。缓存系统作为分布式数据副本的典型代表，其设计决策本质上是 CAP 的权衡。
- C（一致性）：所有缓存节点在同一时刻返回相同的数据。强一致性要求写操作完成后，任何后续读操作都能读到最新值。
- A（可用性）：每个请求都能获得非错误的响应，即使缓存节点故障或网络分区。
- P（分区容错性）：系统在节点间网络分区时仍能继续运行。分布式缓存必须选择 P，因为网络分区是常态。
因此，缓存架构的实际选择落在 CP 与 AP 之间：
| 选择 | 典型缓存策略 | 适用场景 |
|---|---|---|
| CP（一致 + 分区容忍） | 强一致性缓存（如 ZooKeeper 作为元数据缓存） | 配置中心、分布式锁、金融交易 |
| AP（可用 + 分区容忍） | 最终一致性缓存（如 Redis 主从异步复制） | 商品详情页、用户会话、Feed 流 |
实践建议：绝大多数互联网业务场景选择 AP 模型，通过 TTL 过期、异步回写、补偿机制将不一致窗口控制在毫秒级，同时保持缓存的高吞吐。
1.3 一致性与性能的权衡
缓存的核心价值在于用空间换时间，但一致性保障会引入额外的同步开销。以下表格对比了不同一致性级别下的性能特征：
| 一致性级别 | 读延迟 | 写延迟 | 吞吐量 | 实现复杂度 |
|---|---|---|---|---|
| 强一致性 | 高（需验证） | 高（同步写所有副本） | 低 | 高 |
| 最终一致性 | 低（直接读本地） | 低（异步复制） | 高 | 低 |
| 读写一致性 | 中（读时校验） | 中（部分同步） | 中 | 中 |
性能陷阱：过度追求强一致性会导致缓存退化为“慢速代理”，失去缓存意义。例如，每次读请求都去数据库校验版本号，会使缓存命中率下降 60% 以上，延迟增加 3-5 倍。
在实际工程中，一致性治理的目标不是消除不一致，而是将不一致窗口控制在业务可接受的范围内，同时最大化缓存性能。常见的治理手段包括：
- TTL 过期：设置合理的过期时间，自动淘汰旧数据。
- 缓存失效通知：数据变更时主动删除或更新缓存。
- 版本号/时间戳：通过元数据判断数据新鲜度。
- 读写分离：读缓存、写数据库，异步同步。
1.4 一致性治理的工程意义
缓存一致性治理不是纯理论问题，而是直接影响系统 SLA 的工程决策。以下是一个典型的治理决策流程：
- 识别业务容忍度：确定业务允许的最大不一致窗口（如 1s、5s、30s）。
- 选择一致性模型：根据容忍度选择最终一致性、读写一致性或强一致性。
- 设计失效策略：基于模型选择 TTL、主动失效、版本校验等策略。
- 监控与补偿：通过日志、指标监控不一致事件，并设计补偿机制。
关键指标：不一致窗口（Inconsistency Window）——从数据源写入到缓存最终一致的时间差。该指标应作为缓存系统的核心 SLA 进行监控。