1. 缓存一致性概述
1.1 缓存一致性问题定义
在分布式系统中，缓存一致性（Cache Consistency）是指缓存节点中的数据与后端数据源（如数据库、配置中心）中的数据保持同步的程度。当数据在多个缓存副本或缓存层与持久层之间出现差异时，即发生了缓存不一致问题。
核心矛盾：缓存通过牺牲强一致性来换取高性能与低延迟，而业务系统往往要求数据在可接受的时间窗口内收敛到一致状态。
缓存不一致的典型场景包括：
- 写后读不一致：用户写入数据库后立即读取缓存，缓存仍返回旧数据。
- 跨副本不一致：同一份数据在多个缓存节点（如 Redis 集群分片）中存储不同版本。
- 缓存与数据库双写冲突：并发更新操作导致缓存与数据库最终状态不同。
- 缓存穿透/击穿/雪崩：大量请求绕过缓存直接访问数据库，导致缓存与数据库状态脱节。
| 不一致类型 | 触发原因 | 影响范围 | 典型修复策略 |
|---|---|---|---|
| 写后读不一致 | 缓存更新延迟或失败 | 单用户会话 | Cache-Aside 模式 + 延迟双删 |
| 跨副本不一致 | 主从同步延迟、网络分区 | 全局用户 | Quorum 读写 + 版本向量 |
| 双写冲突 | 并发更新未加锁或未做 CAS | 热点数据 | 分布式锁 + 最终补偿 |
| 缓存穿透 | 缓存未命中且未做空值缓存 | 数据库负载 | 布隆过滤器 + 空值缓存 |
1.2 CAP 理论在缓存中的应用
CAP 理论指出，分布式系统在 一致性（Consistency）、可用性（Availability） 和 分区容错性（Partition Tolerance） 三者中最多同时满足两项。缓存系统作为分布式数据层的核心组件，其架构设计必须在 CAP 之间做出明确取舍。
缓存系统的 CAP 选择：绝大多数生产级缓存（如 Redis Cluster、Memcached）优先保证 AP（可用性 + 分区容错性），通过异步复制或最终一致性机制来弥补一致性短板。只有强一致性场景（如分布式锁、金融交易）才会选择 CP（一致性 + 分区容错性），但需接受可用性下降的风险。
下表对比了不同缓存架构在 CAP 维度上的典型表现：
| 缓存架构 | 一致性 | 可用性 | 分区容错性 | 典型场景 |
|---|---|---|---|---|
| 单机缓存（Local Cache） | 强一致（单节点） | 低（单点故障） | 无 | 单体应用、开发环境 |
| Redis 主从 + 哨兵 | 最终一致（异步复制） | 高（自动故障转移） | 高 | 读多写少、会话缓存 |
| Redis Cluster | 最终一致（异步复制） | 高（分片 + 副本） | 高 | 大规模分布式缓存 |
| ZooKeeper / Etcd | 强一致（Raft 共识） | 中（Leader 选举期间不可用） | 高 | 分布式协调、配置中心 |
| 一致性哈希 + 本地缓存 | 弱一致 | 高 | 中 | CDN、边缘缓存 |
1.3 最终一致性与强一致性对比
在缓存一致性设计中，强一致性 和 最终一致性 是两种最核心的模型选择。理解它们的差异是设计缓存回滚策略的前提。
强一致性（Strong Consistency）
- 写入操作完成后，所有后续读取操作都能立即看到最新数据。
- 实现方式：同步复制、分布式共识协议（Raft/Paxos）、分布式锁。
- 代价：写入延迟高、可用性降低（分区时可能不可用）。
- 适用场景：金融交易、库存扣减、分布式锁、配置中心。
最终一致性（Eventual Consistency）
- 写入操作完成后，系统保证在没有新更新的情况下，所有副本最终会达到一致状态。
- 实现方式：异步复制、消息队列补偿、CRDT（无冲突复制数据类型）。
- 代价：存在不一致窗口（通常毫秒到秒级），需要业务容忍。
- 适用场景：用户会话、商品详情页、社交 Feed、CDN 缓存。
| 对比维度 | 强一致性 | 最终一致性 |
|---|---|---|
| 读取延迟 | 高（需等待多数节点确认） | 低（本地副本直接返回） |
| 写入延迟 | 高（同步复制到多数节点） | 低（写入主节点后异步复制） |
| 可用性 | 低（分区时可能拒绝写入） | 高（分区时仍可写入） |
| 不一致窗口 | 无 | 存在（通常 < 1s） |
| 实现复杂度 | 高（共识算法、版本控制） | 中（异步复制、冲突解决） |
| 典型缓存实现 | ZooKeeper、Etcd、Redis RedLock | Redis 主从、Memcached、CDN |
常见误区：不要认为最终一致性就是“弱一致性”。最终一致性提供了明确的收敛保证——只要系统停止写入，所有副本最终会一致。而弱一致性（如 DNS 缓存）可能永远不收敛。在缓存回滚策略中，最终一致性是可以通过补偿机制（如重试、版本对比、回滚日志）来弥补的，而弱一致性则无法可靠回滚。
设计启示：在《后端安全合规缓存一致性闭环》课程中，我们将基于最终一致性模型构建缓存回滚策略。原因在于：生产环境缓存系统几乎都选择 AP 架构，强一致性带来的可用性损失和延迟成本在大多数业务场景中不可接受。我们的回滚策略将通过 版本向量、延迟双删、补偿事务 和 回滚日志 来缩小不一致窗口，并在安全合规要求下保证数据可追溯。