1. 缓存一致性概述

1.1 为什么需要缓存

在分布式系统中，缓存是提升数据读取性能、降低数据库负载的核心手段。当大量请求直接穿透到数据库时，磁盘 I/O 和连接池会成为瓶颈，导致响应延迟飙升甚至服务雪崩。引入缓存层后，热点数据可以直接从内存返回，将读延迟从毫秒级降至微秒级。

典型应用场景包括：

• 热点商品详情页：秒杀/大促期间，商品信息几乎全部命中缓存。
• 用户会话状态：Session 数据从关系库迁移到 Redis，避免频繁建连。
• 配置/规则中心：业务规则、黑白名单等低频变更数据，缓存后减少 DB 查询。

1.2 缓存与数据库的差异

缓存系统（如 Redis、Memcached）与关系型数据库（如 MySQL、PostgreSQL）在底层设计上存在本质区别，这些差异直接决定了它们无法天然保持数据一致。

1.3 一致性问题产生的根源

当应用程序同时操作缓存和数据库时，由于写入顺序、并发冲突、网络分区等因素，缓存中的值与数据库中的真实值可能产生偏差。这种偏差就是缓存一致性问题。

问题根源可归纳为以下三类：

1. 双写时序不一致：更新数据库后，缓存更新失败或延迟，导致旧数据被后续请求读取。
2. 并发覆盖：多个线程/节点同时读写同一 Key，后写入的缓存可能覆盖了正确的数据库值。
3. 缓存淘汰与回填竞争：缓存过期后被淘汰，回填时数据库数据已被其他事务修改，导致回填了旧值。

1.4 一致性问题的典型表现

在实际生产环境中，缓存一致性问题会以多种形态暴露出来，测试人员需要能够识别并分类这些异常现象。

1.5 一致性模型分类

在讨论缓存一致性之前，需要明确不同的一致性模型定义。分布式系统中常见的一致性模型如下：

• 强一致性（Linearizability）：写入完成后，任何后续读取都能立即看到最新值。实现代价高，通常需要分布式共识协议（如 Paxos/Raft）。
• 最终一致性（Eventual Consistency）：在没有新写入的情况下，经过足够长的时间，所有副本最终会收敛到相同的值。缓存系统默认采用此模型。
• 因果一致性（Causal Consistency）：有因果关系的操作按顺序可见，无因果关系的操作可以并发。
• 读己之写（Read-Your-Writes）：客户端写入后，总能读到自己的写入，但其他客户端可能暂时看不到。