4. 缓存一致性理论：CAP、BASE 与一致性模型在缓存场景下的取舍
在分布式缓存系统中，一致性不是非黑即白的选择，而是业务场景、性能与可用性之间的权衡。本章从 CAP 与 BASE 理论出发，梳理强一致性、弱一致性、最终一致性在缓存场景下的适用边界与工程取舍。
4.1 CAP 理论：缓存系统的三角约束
CAP 理论指出，一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两项。在缓存场景中，分区容错性是必须保证的，因此实际选择在 C 与 A 之间展开。
| 组合 | 典型缓存场景 | 代价 |
|---|---|---|
| CP（一致性 + 分区容错） | 分布式锁缓存、配置中心缓存 | 节点故障或网络分区时，缓存服务不可写 |
| AP（可用性 + 分区容错） | 商品详情缓存、用户会话缓存 | 允许短暂读取到旧数据，最终一致 |
| CA（一致性 + 可用性） | 单机缓存（非分布式） | 无法容忍网络分区，不适合分布式部署 |
工程经验：生产环境缓存集群几乎都选择 AP 模型。例如 Redis Cluster 在分区时允许部分节点继续服务，牺牲强一致性换取高可用。对于需要强一致的场景（如库存扣减），应使用分布式锁或数据库事务，而非依赖缓存。
4.2 BASE 理论：缓存一致性的工程基石
BASE 理论是对 CAP 中 AP 模型的实践延伸，强调基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。缓存系统正是 BASE 理论的典型代表。
- 基本可用：缓存集群允许部分节点故障，整体服务不降级。例如 Redis Sentinel 在主节点宕机时自动切换。
- 软状态：允许缓存数据在一段时间内处于不一致的中间状态。例如缓存与数据库之间的写后延迟。
- 最终一致性：经过一定时间后，所有副本数据最终达到一致。这是缓存一致性治理的核心目标。
核心观点：BASE 理论不是对 ACID 的否定，而是对大规模分布式系统可用性优先的务实选择。在缓存场景中，我们通常接受秒级甚至毫秒级的最终一致性窗口，以此换取高吞吐和低延迟。
4.3 三种一致性模型在缓存中的取舍
根据业务对数据新鲜度的容忍程度，缓存一致性模型可分为强一致性、弱一致性和最终一致性。下表对比了三种模型在缓存场景下的典型实现与适用场景。
| 模型 | 定义 | 缓存实现方式 | 延迟影响 | 适用场景 |
|---|---|---|---|---|
| 强一致性 | 写操作完成后，任何读操作立即返回最新值 | 同步双写 + 分布式锁 + 缓存穿透保护 | 高（写放大，锁竞争） | 库存、余额、分布式锁 |
| 弱一致性 | 写操作后，读操作可能返回旧值，不保证何时一致 | 异步写回、Cache-Aside 无强制同步 | 低（无额外开销） | 日志、监控指标、非关键聚合数据 |
| 最终一致性 | 写操作后，经过一段时间所有副本最终一致 | 延迟双删、消息队列异步同步、TTL 过期 | 中（可接受窗口期） | 商品详情、用户资料、配置缓存 |
4.4 最终一致性在缓存场景的落地模式
最终一致性是生产环境缓存治理中最常用的模型。以下三种模式覆盖了绝大多数业务场景。
- Cache-Aside + 延迟双删：更新数据库后，先删除缓存，再延迟几百毫秒后二次删除。解决并发读写导致的脏数据问题。
- 异步消息同步：数据库变更后发送 MQ 消息，消费者异步更新或失效缓存。适用于写多读少、对一致性窗口不敏感的场景。
- TTL 兜底：为缓存设置合理的过期时间（如 5 分钟），即使同步机制失效，缓存也会自动过期，从数据库重新加载。
避坑提醒：延迟双删的“延迟”时间需要根据业务并发度调整。如果延迟太短，并发读请求仍可能写入旧数据；如果延迟太长，会放大不一致窗口。建议延迟时间 = 缓存查询平均耗时 × 2 + 100ms 冗余。
4.5 一致性模型选择决策树
在实际架构设计中，可以按照以下决策树快速确定缓存一致性模型：
- 业务是否允许短暂读到旧数据？
- 是 → 进入下一步
- 否 → 使用强一致性（分布式锁 + 同步双写）
- 不一致窗口能否控制在秒级？
- 是 → 使用最终一致性（延迟双删 / MQ 同步）
- 否 → 使用弱一致性（异步写回，不保证时效）
- 缓存数据是否可接受 TTL 过期后自动修复？
- 是 → 设置合理 TTL 作为兜底
- 否 → 必须依赖主动失效机制
推荐实践：在 development 环境中，建议默认采用最终一致性 + TTL 兜底。对于需要强一致的场景（如测试环境中的分布式锁），单独标注并配置独立的缓存实例，避免影响主链路的可用性。