2. 缓存一致性基础理论
在分布式缓存系统中，一致性是决定系统行为与可靠性的核心约束。本章从 CAP 理论与 BASE 理论出发，分析它们在缓存场景下的具体表现，并对比强一致性与最终一致性的适用边界。
2.1 CAP 理论在缓存场景下的应用
CAP 理论指出，分布式系统最多同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两项。在缓存中间件中，网络分区是常态，因此必须在 C 和 A 之间做出权衡。
缓存场景下的 CAP 解读：
- C（一致性）：所有缓存节点在同一时刻返回相同的数据。写入缓存后，任何读取请求都能立即看到最新值。
- A（可用性）：每个请求都能获得非错误的响应，即使缓存节点故障或网络延迟，系统仍能返回数据（可能是旧数据）。
- P（分区容错性）：系统能容忍网络分区，即节点间通信中断时仍能继续运行。缓存集群必须支持 P。
实践建议：大多数缓存场景选择 AP 系统（如 Redis 集群在分区时继续服务），但关键业务数据（如支付状态）应使用 CP 系统或引入外部一致性协调器。
2.2 BASE 理论在缓存场景下的应用
BASE 理论是对 CAP 中 AP 策略的延伸，强调基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。缓存系统通常采用 BASE 思想来平衡性能与一致性。
| BASE 要素 | 缓存场景含义 | 典型实现 |
|---|---|---|
| 基本可用 | 缓存节点故障时，系统降级返回旧数据或默认值，保证请求不失败 | 本地缓存 + 远程缓存双降级策略 |
| 软状态 | 缓存数据允许存在中间状态，不同节点可能持有不同版本的数据 | 多级缓存中各级数据版本号不一致 |
| 最终一致性 | 经过一定时间后，所有缓存节点最终会达到数据一致 | 异步刷新、TTL 过期、消息队列同步 |
注意：BASE 理论不保证实时一致性。在缓存更新后到最终一致前的窗口期内，应用层必须能容忍读取到旧数据。对于金融、库存等强约束场景，需要额外引入分布式锁或事务消息。
2.3 强一致性与最终一致性的区别与选择
强一致性和最终一致性是缓存一致性策略的两个极端。理解它们的差异是设计缓存一致性闭环的基础。
2.3.1 核心区别对比
| 对比维度 | 强一致性 | 最终一致性 |
|---|---|---|
| 读取延迟 | 高，需等待所有副本确认 | 低，直接返回本地缓存值 |
| 写入延迟 | 高，同步复制阻塞 | 低，异步复制非阻塞 |
| 数据准确性 | 实时准确，无脏读 | 存在不一致窗口期 |
| 系统吞吐 | 低，受限于最慢副本 | 高，可水平扩展 |
| 故障容忍 | 弱，副本故障导致写入失败 | 强，副本故障不影响写入 |
| 典型协议 | Paxos、Raft、ZAB | Gossip、CRDT、TTL 刷新 |
2.3.2 选择策略
选择决策树：
- 业务是否允许读取到旧数据？
- 不允许 → 使用强一致性（如分布式锁 + 同步复制）
- 允许 → 使用最终一致性（如 TTL 缓存 + 异步刷新）
- 系统对写入延迟是否敏感？
- 敏感 → 使用最终一致性，避免同步阻塞
- 不敏感 → 可接受强一致性带来的写入延迟
- 缓存节点故障时是否允许降级？
- 允许降级 → 最终一致性 + 本地缓存兜底
- 不允许降级 → 强一致性 + 多副本冗余
混合策略：实际生产环境中，常采用“读写分离 + 最终一致性”方案。写操作直接更新数据库并异步刷新缓存；读操作优先读取缓存，缓存缺失时回源数据库并回填。对于关键数据，可在缓存更新后设置短暂锁（如 1 秒）强制读库，实现准强一致性。