1. 缓存一致性核心问题
1.1 问题定义
缓存一致性是指缓存（如 Redis、Memcached）中的副本数据与后端存储（如 MySQL、PostgreSQL）中的主数据之间保持逻辑等价的状态。当应用程序通过缓存加速读取时，任何对数据的更新必须确保缓存与存储最终或实时一致；否则将产生数据不一致，导致业务逻辑错误。
从架构边界看，该问题覆盖从应用层到存储层的全链路：
- 应用层：读/写请求的发起者，负责选择缓存策略（旁路、穿透、异步）。
- 缓存层：热数据副本载体，提供快速读取，但自身缺乏事务保障。
- 存储层：持久化权威数据源，保证强一致性但吞吐受限。
核心矛盾：缓存的“高性能”与存储的“强一致”天然存在张力，任何分布式系统中缓存与存储之间都存在 CAP 权衡 —— 分区容忍性（P）下，可用性（A）与一致性（C）难以两全。
1.2 数据不一致场景
| 场景 | 描述 | 典型触发条件 |
|---|---|---|
| 写后更新缓存失败 | 数据库更新成功，但缓存更新（或失效）因网络/超时失败 | 写请求吞吐高、缓存连接池耗尽 |
| 并发写覆盖 | 两个写请求先后更新数据库，但缓存更新顺序与数据库相反，导致缓存保留旧值 | 无锁缓存更新、异步写回 |
| 读写并发 | 读请求在写请求更新数据库但未更新缓存的时间窗口内，读到脏数据 | 缓存过期时间较长、写操作延迟 |
| 缓存淘汰 | 缓存被淘汰后，新写请求未加载最新数据，后续读请求直接穿透至旧数据库记录 | 内存不足触发 LRU，但数据库同时被其他事务修改 |
| 分布式缓存节点同步延迟 | 主从缓存架构中，主节点更新后从节点未及时复制，读请求命中从节点得到旧值 | 网络分区、从节点同步 backlog 不足 |
风险警示：以上场景在读写比例 > 5:1 的高并发系统中尤其严重，因为缓存命中率越高，不一致数据被扩散的概率越大。
1.3 业务影响分析
缓存一致性问题对业务的影响取决于数据对一致性的敏感度，从轻微体验问题到严重资损错误：
- 用户体验下降：用户看到过时信息（如商品价格、库存数量），导致决策错误。
- 库存超卖：电商秒杀场景下，缓存中的库存余量未及时同步，导致同一商品被多次下单。
- 金融交易错误：账户余额、汇率等敏感数据不一致，可能引发资金损失或合规风险。
- 数据修复成本：不一致数据扩散后，需要额外开发对账脚本、手动修正，增加运维复杂度。
- 系统信任崩塌：核心数据不可信，开发团队被迫增加全量穿透查询，缓存价值降低。
落地建议：在项目初期明确定义每类数据的一致性级别（强一致/最终一致/弱一致），根据业务容忍度选择缓存策略，避免“一刀切”强一致导致性能劣化或“一刀切”最终一致导致资损。
1.4 本章小结与后续方向
缓存一致性问题的本质是分布式系统中副本数据与权威数据之间的时序冲突。通过识别典型不一致场景（表1）和分析业务影响（1.3），我们可以建立以下认知边界：
- 信任链路：缓存应被视为“可丢失副本”，存储才是唯一权威源，所有写入必须以存储状态为准。
- 控制流关键点：写请求必须同步/异步更新缓存，且需处理失败回退与重试。
- 选型权衡：强一致方案（如分布式锁、事务性缓存）会降低可用性与吞吐，需在性能和正确性之间找到平衡点。