2. 缓存一致性基础

2.1 缓存一致性问题定义

在分布式系统中，缓存一致性（Cache Consistency）是指缓存节点中的数据与数据源（如数据库、上游服务）中的数据保持同步的程度。当数据在多个缓存副本或缓存层与持久层之间出现差异时，即发生了缓存不一致问题。

缓存不一致的典型场景包括：

• 写后读不一致：用户更新数据后立即读取，缓存仍返回旧值。
• 并发写冲突：两个线程同时更新同一数据，缓存与数据库的更新顺序不一致。
• 缓存与数据库双写：先写数据库后写缓存，写缓存失败导致数据永久不一致。
• 主从延迟：缓存从数据库从库读取数据，主库已更新但从库尚未同步。

2.2 常见缓存一致性模型

缓存一致性模型定义了系统对数据一致性的保证强度。不同业务场景需要选择不同的模型来平衡性能与正确性。

2.2.1 强一致性（Strong Consistency）

强一致性要求：数据更新完成后，任何后续的读操作都能立即读取到最新值。系统对外表现为只有一个数据副本。

• 实现方式：分布式锁、同步复制、读写锁（Write-Through + 锁）。
• 优点：编程模型简单，业务逻辑无需处理不一致。
• 缺点：写入延迟高，吞吐量受限，可用性降低（CAP 中的 CP）。
• 适用场景：金融交易、库存扣减、配置中心。

2.2.2 最终一致性（Eventual Consistency）

最终一致性保证：如果系统在一段时间内没有新的写入，那么所有副本最终会达到一致状态。中间状态允许读取到旧值。

• 实现方式：异步复制、消息队列、补偿机制（如 TCC、Saga）。
• 优点：高可用、高吞吐、低延迟。
• 缺点：业务需要容忍短暂的不一致，需设计幂等和补偿逻辑。
• 适用场景：社交动态、商品详情、用户评论。

2.2.3 弱一致性（Weak Consistency）

弱一致性不保证更新后何时能读到新值，甚至不保证最终一定能读到。系统只保证“某些条件下”可能一致。

• 实现方式：无缓存同步、TTL 过期、概率性同步。
• 优点：性能最高，实现最简单。
• 缺点：数据可靠性最低，业务风险大。
• 适用场景：实时日志、监控指标、非关键性展示。

2.3 缓存失效与更新策略

缓存失效与更新策略决定了缓存数据何时被清除或刷新。策略的选择直接影响一致性的强弱和系统的性能表现。

2.3.1 常见失效策略

• TTL（Time-To-Live）过期：缓存项设置存活时间，到期自动失效。实现简单，但存在“过期风暴”风险（大量缓存同时失效）。
• 主动失效：数据更新时，显式删除或更新缓存。精确控制，但需要业务代码配合。
• LRU/LFU 淘汰：缓存满时淘汰最久未使用或最不常用的数据。与一致性无关，但影响命中率。

2.3.2 常见更新策略

2.4 策略选择与集成测试的关联

在《缓存一致性治理中的集成测试安全权限配置》课程中，缓存策略的选择直接决定了测试用例的设计方向：

• 强一致性 + Write-Through：测试重点在于缓存层故障时的回滚机制和权限配置的原子性。
• 最终一致性 + Cache-Aside：测试重点在于异步队列的可靠性、消息去重和权限生效的延迟窗口。
• 弱一致性 + TTL：测试重点在于过期时间的准确性、缓存穿透防护和权限变更的最终生效时间。