2. 缓存一致性基础理论：CAP、BASE 与一致性模型
在分布式缓存系统中，一致性不是“全有或全无”的二元选择，而是一组在延迟、可用性与数据正确性之间的连续权衡。本章从 CAP 与 BASE 理论出发，定义强一致性、弱一致性、最终一致性在缓存场景下的具体含义，并给出工程取舍原则。
2.1 CAP 理论在缓存场景下的重新解读
CAP 定理指出：分布式系统最多同时满足 一致性（Consistency）、可用性（Availability） 和 分区容错性（Partition Tolerance） 中的两项。在缓存系统中，网络分区是常态，因此实际是在 C 与 A 之间做选择。
| CAP 组合 | 缓存典型场景 | 一致性表现 | 可用性表现 |
|---|---|---|---|
| CP（放弃 A） | 分布式锁、配置中心缓存 | 写入后所有读节点必须同步 | 分区时部分节点不可用 |
| AP（放弃 C） | 商品详情页、用户会话缓存 | 允许短暂不一致，最终收敛 | 分区时所有节点持续服务 |
| CA（放弃 P） | 单机缓存、本地缓存 | 强一致 | 无分区风险，可用性高 |
工程经验： 生产环境几乎不可能放弃 P。网络分区一定会发生，因此缓存架构设计本质上是在“分区发生时优先保一致”还是“优先保可用”之间做选择。
2.2 BASE 理论：缓存一致性的实践基石
BASE 理论是对 CAP 中 AP 路线的工程化补充，由 eBay 架构师 Dan Pritchett 提出。其核心思想是：基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventually Consistent）。
- 基本可用： 缓存节点故障时，系统允许降级响应（如返回旧缓存、限流），而非完全不可用。
- 软状态： 缓存数据允许存在中间状态（如写后未同步），不要求时刻一致。
- 最终一致性： 在没有新写入的情况下，经过足够时间，所有副本最终达到一致。
关键认知： BASE 不是对 ACID 的否定，而是对分布式缓存场景下“一致性延迟”的承认。最终一致性是缓存系统最普遍的一致性模型。
2.3 三种一致性模型在缓存中的定义与取舍
| 一致性模型 | 缓存定义 | 读延迟 | 写延迟 | 典型实现 |
|---|---|---|---|---|
| 强一致性 | 写入完成后，任何后续读操作都能读到最新值 | 高（需同步等待） | 高（需所有副本确认） | ZooKeeper、Etcd、同步双写 |
| 弱一致性 | 写入后，读操作可能读到旧值，不保证何时一致 | 低 | 低 | DNS 缓存、CDN 边缘节点 |
| 最终一致性 | 写入后，系统保证在没有新写入时，所有副本最终一致 | 低 | 中（异步复制） | Redis 主从异步复制、Couchbase |
常见误区： 最终一致性不等于“弱一致性”。最终一致性有明确的收敛保证（如版本向量、时钟同步），而弱一致性没有任何时间承诺。缓存设计应优先选择最终一致性，而非弱一致性。
2.4 缓存一致性取舍的工程决策矩阵
在实际架构中，选择哪种一致性模型取决于业务对 数据新鲜度 和 系统可用性 的容忍度。以下矩阵帮助决策：
| 业务场景 | 数据新鲜度要求 | 可用性要求 | 推荐一致性模型 | 缓存策略 |
|---|---|---|---|---|
| 分布式锁 / 选主 | 极高 | 中 | 强一致性 | ZooKeeper / Etcd |
| 库存扣减 | 高 | 高 | 强一致性 + 最终补偿 | Redis RedLock + 异步对账 |
| 商品详情页 | 中 | 极高 | 最终一致性 | Redis 主从 + 缓存失效 TTL |
| 用户会话 | 低 | 极高 | 最终一致性 | Redis 集群 + 会话粘滞 |
| CDN 静态资源 | 极低 | 极高 | 弱一致性 | CDN 边缘 + 版本号刷新 |
架构建议： 不要在整个系统中统一使用一种一致性模型。按业务域拆分：核心交易链路使用强一致性，非核心展示链路使用最终一致性，静态资源使用弱一致性。通过 OpenAPI 契约显式声明每个缓存接口的一致性级别，让调用方明确预期。
2.5 本章小结
- CAP 理论在缓存中本质是“分区时选 C 还是选 A”，BASE 理论为 AP 路线提供了工程化指导。
- 强一致性保证读最新，但牺牲延迟和可用性；最终一致性是缓存系统最实用的模型；弱一致性仅适用于容忍度极高的场景。
- 一致性选择应基于业务场景，通过决策矩阵匹配数据新鲜度与可用性要求。
- 下一章将深入 缓存更新模式（Cache-Aside、Read-Through、Write-Through 等），并分析每种模式在一致性治理中的适用边界。