1. 缓存一致性概述
1.1 缓存一致性问题的定义
缓存一致性（Cache Consistency）是指在分布式系统中，缓存层与后端数据源（如数据库、文件系统、外部服务）之间保持数据同步的程度。当业务数据发生变更时，缓存中的副本必须及时更新或失效，否则系统将面临数据不一致的风险。
从严格意义上讲，缓存一致性包含三个维度：
| 维度 | 定义 | 典型违反场景 |
|---|---|---|
| 强一致性 | 写入操作完成后，任何后续读取都能立即看到最新值 | 写后立即读，缓存仍返回旧值 |
| 最终一致性 | 写入后经过一段窗口期，所有副本最终达到一致 | 主从延迟导致短暂读到旧数据 |
| 因果一致性 | 有因果关系的操作按正确顺序被观察到 | 先更新A再更新B，但读请求看到B新值、A旧值 |
核心观点：缓存一致性不是非黑即白的选择题，而是业务场景与性能之间的权衡。大多数互联网业务接受最终一致性，但金融、库存、支付等场景必须追求强一致性。
1.2 产生原因分析
缓存一致性问题的根源在于数据副本的异步传播。以下从两个典型场景展开：
1.2.1 写后读不一致
这是最常见的缓存一致性问题。当应用程序先更新数据库，再更新缓存（或删除缓存）时，如果两个操作之间发生并发读取，就会读到旧数据。
// 典型的不一致时序（Java伪代码）
// 线程A：写操作
updateDatabase(key, newValue); // 步骤1：更新数据库
// 此时线程B读取缓存，返回旧值
deleteCache(key); // 步骤2：删除缓存（或更新缓存）
// 线程B：读操作（发生在步骤1之后、步骤2之前）
Object cached = getFromCache(key); // 返回旧值
return cached;
写后读不一致的常见诱因：
- 缓存更新滞后于数据库更新：先写库后删缓存，中间存在时间窗口
- 并发写入冲突：多个写线程同时操作同一数据，缓存更新顺序与数据库不一致
- 缓存淘汰策略干扰：LRU/LFU淘汰恰好发生在写后读的间隙
- 分布式事务缺失：数据库与缓存操作不在同一个事务上下文中
1.2.2 主从延迟
在读写分离架构中，主库负责写入，从库负责读取。当缓存失效后，应用从从库读取数据，但主库的变更尚未同步到从库，导致缓存中写入的是旧值。
| 延迟类型 | 典型延迟范围 | 影响程度 |
|---|---|---|
| MySQL 半同步复制 | 1ms ~ 50ms | 低，极少出现不一致 |
| MySQL 异步复制 | 100ms ~ 数秒 | 中，高并发下频繁出现 |
| Redis 主从同步 | 亚毫秒 ~ 10ms | 低，但网络抖动时加剧 |
| 跨机房主从同步 | 数十毫秒 ~ 数秒 | 高，需特殊治理策略 |
实战陷阱：很多团队在缓存失效后直接查询从库，认为“从库数据应该是最新的”。实际上，主从延迟可能让缓存写入一个比旧缓存更旧的值——这就是“缓存污染”的典型成因。
1.3 对业务的影响
缓存一致性问题的业务影响因场景而异，以下从三个维度评估：
| 业务场景 | 不一致后果 | 可接受度 | 治理优先级 |
|---|---|---|---|
| 商品详情页 | 用户看到过时的价格/库存 | 低（秒级可接受） | 高 |
| 用户会话信息 | 登录状态异常、权限错乱 | 极低 | 最高 |
| 新闻/资讯Feed | 内容延迟展示 | 高（分钟级可接受） | 低 |
| 金融交易流水 | 余额显示错误、重复扣款 | 不可接受 | 必须强一致 |
| 配置中心 | 配置未生效导致功能异常 | 低 | 高 |
从系统层面看，缓存不一致还会引发：
- 数据污染扩散：脏数据被下游服务读取并二次缓存，形成“脏数据链”
- 业务逻辑错误：基于过期数据做决策（如库存扣减、价格计算）
- 排查成本剧增：不一致问题偶发、难复现，定位耗时是普通Bug的3~5倍
- SLA受损：数据一致性不达标，影响服务等级协议
经验法则：如果业务允许“写后5秒内读到最新值”，那么大部分缓存一致性方案都能满足。如果要求“写后立即读到最新值”，则需要引入分布式锁、读写屏障或缓存双删等强一致手段。
1.4 一致性治理的切入点
理解缓存一致性问题的本质后，治理策略可以从以下四个层面展开：
- 操作顺序优化：采用“先更新数据库，再删除缓存”的经典模式，配合延迟双删策略
- 读写路由控制：写后强制读主库，或通过版本号/时间戳判断缓存有效性
- 异步补偿机制：通过消息队列异步同步缓存，配合重试和幂等设计
- 监控与告警：建立缓存与数据库的对比校验，及时发现不一致并修复