1. 缓存一致性概述
1.1 缓存一致性问题定义
缓存一致性（Cache Consistency）是指在分布式系统或多级缓存架构中，不同缓存节点或缓存层与数据源之间，对同一份数据所持有的副本在任意时刻都保持逻辑等价的状态。当某个副本被更新后，其他副本未能同步反映该变更，即产生缓存一致性问题。
核心定义：缓存一致性 = 所有缓存副本与数据源之间的数据等价性。一旦出现偏差，系统便处于不一致状态。
1.2 产生原因
缓存一致性问题并非单一因素导致，而是由以下四类典型场景共同诱发：
| 原因类别 | 具体描述 | 典型场景 |
|---|---|---|
| 并发写入 | 多个服务实例同时更新同一数据，缓存与数据库写入顺序不一致 | 库存扣减、账户余额变更 |
| 缓存失效延迟 | 数据已更新，但缓存 TTL 未到期，旧数据仍被读取 | 配置中心、商品详情页 |
| 网络分区 | 缓存节点与数据库节点之间网络中断，更新无法传播 | 跨机房部署、边缘缓存 |
| 删除/更新顺序错乱 | 先删缓存后写数据库，或先写数据库后删缓存，时序颠倒导致脏数据 | Cache-Aside 模式下的竞态条件 |
测试视角：上述四类原因中，“并发写入”和“删除/更新顺序错乱”是自动化测试最容易覆盖的入口，建议在集成测试阶段构造时序竞争用例。
1.3 对系统稳定性的影响
缓存不一致对系统稳定性的破坏是渐进且隐蔽的，通常表现为以下三个层次：
- 数据层污染：脏数据被下游服务消费后，可能写入其他存储系统，造成跨系统数据污染。
- 业务逻辑异常：用户看到过期价格、重复下单、库存超卖等直接业务故障。
- 雪崩效应：不一致导致缓存击穿或穿透，大量请求回源数据库，引发级联故障。
故障案例：某电商平台因缓存未及时失效，用户看到已售罄商品仍可下单，最终导致 2 万笔超卖订单，直接经济损失超 500 万元。事后排查发现，缓存 TTL 设置过长且未配置变更通知机制。
1.4 缓存一致性问题的分类矩阵
根据数据更新频率和一致性容忍度，可将缓存一致性问题划分为四种类型，便于制定差异化的治理策略：
| 类型 | 更新频率 | 一致性容忍度 | 典型数据 | 推荐策略 |
|---|---|---|---|---|
| 强一致 | 低 | 零容忍 | 账户余额、订单状态 | 同步失效 + 分布式锁 |
| 最终一致 | 高 | 秒级容忍 | 用户头像、商品描述 | 异步通知 + TTL 兜底 |
| 弱一致 | 极高 | 分钟级容忍 | 排行榜、热门推荐 | 定时刷新 + 版本号 |
| 读写分离不一致 | 中等 | 视业务而定 | 报表数据、统计摘要 | 主从延迟监控 + 缓存标记 |
1.5 一致性窗口与测试度量
缓存一致性问题可以用 一致性窗口（Consistency Window） 来量化：从数据源更新完成到所有缓存副本感知到该变更之间的时间差。窗口越短，系统一致性越好。
测试度量指标：
- 窗口时长：从写入数据库到缓存失效或更新完成的时间间隔（单位：ms）
- 不一致率：在窗口期内读取到旧数据的请求占比
- 恢复时间：从检测到不一致到恢复一致的平均耗时