数据库与缓存不一致是分布式系统中常见问题，本质是数据在缓存层和存储层出现版本差异。
一、并发写操作导致不一致（最常见）
-
场景描述
-
线程A更新数据库 → 线程B更新数据库 → 线程B更新缓存 → 线程A更新缓存
-
结果：缓存中存储的是线程A的旧数据
-
-
发生条件
-
解决方案
-
分布式锁：对同Key的写操作加锁
-
串行化队列：将写请求放入MQ顺序执行
-
二、先更新数据库后删除缓存失败（Cache-Aside模式）
-
场景描述
-
更新数据库成功
-
删除缓存失败（网络抖动/Redis超时）
-
结果：缓存中残留旧数据
-
-
关键代码风险点
public void updateData(Data data) {db.update(data); // 步骤1：数据库更新成功cache.delete(data.getId()); // 步骤2：缓存删除失败！ } -
解决方案
-
重试机制：
void deleteWithRetry(String key, int maxRetry) {int retry = 0;while (!cache.delete(key) && retry++ < maxRetry) {Thread.sleep(50);} } - 异步补偿：通过Binlog监听（如Canal）触发二次删除
-
三、主从延迟导致脏读（读写分离架构）
-
场景描述
-
主库更新成功 → 删除缓存
-
读请求从未同步的从库读取旧值 → 回填缓存
-
结果：缓存被旧数据污染
-
-
解决方案
-
延迟双删：
db.update(data); // 更新主库 cache.delete(key); // 首次删除 Thread.sleep(500); // 等待主从同步 cache.delete(key); // 二次删除 -
强制读主库：对一致性要求高的查询直连主库
-
四、缓存过期时高并发读（Cache Miss风暴）
-
场景描述
-
缓存过期瞬间涌入大量读请求
-
请求1查DB → 请求2查DB → ... → 请求N查DB
-
多个线程同时回填缓存（可能乱序）
-
结果：缓存可能被中间状态数据覆盖
-
-
极端案例
-
请求1读取到旧值V1，回填耗时久
-
请求2读取新值V2并先完成回填
-
请求1最终将V1写入缓存（覆盖V2）
-
-
解决方案
-
互斥锁重建：仅允许一个线程重建缓存
-
逻辑过期：物理缓存永不过期，通过逻辑时间控制
-
五、批量操作与部分失效
-
场景描述
-
场景1：批量更新数据库成功，但部分缓存删除失败
-
场景2：分页查询缓存无法感知单条数据变更
-
结果：缓存中存在部分脏数据
-
-
典型案例
-
商品列表页缓存无法感知单个商品价格变更
-
订单列表缓存未失效时，订单状态已更新
-
-
解决方案
-
缓存维度拆分：按查询条件设计缓存Key
-
增量广播：通过消息队列通知相关缓存失效
-
短过期时间：对聚合查询设置更短TTL
-
六、跨服务数据变更
-
场景描述
-
服务A更新数据库 → 服务B的缓存未失效
-
原因：服务间缺乏缓存协同机制
-
结果：跨服务缓存残留旧数据
-
-
微服务常见问题
-
解决方案
-
领域事件通知：通过消息队列（Kafka/RabbitMQ）广播变更
-
统一缓存层：所有服务通过SDK操作缓存，SDK统一处理失效
-
七、终极解决之道：取舍策略
根据业务需求选择合适的一致性级别：
| 策略 | 一致性强度 | 性能影响 | 适用场景 |
|---|---|---|---|
| 先删缓存再更新DB | 中 | 低 | 写少读多 |
| 先更新DB再删缓存 | 中 | 低 | 通用方案（需重试） |
| 双写+事务 | 高 | 高 | 金融交易 |
| 延迟监听（Binlog） | 最终一致 | 中 | 高并发写场景 |
| 忽略不一致+短TTL | 弱 | 无 | 允许短暂脏读的业务 |
重要原则：不要尝试绝对强一致，除非接受性能断崖式下降。通常建议采用 "更新DB + 延迟双删 + 重试队列" 的组合策略。
)