当前位置：首页 > web >正文

详解Redis数据库和缓存不一致的情况及解决方案

web 2025/6/23 11:46:20

数据库与缓存不一致是分布式系统中常见问题，本质是数据在缓存层和存储层出现版本差异。

关键代码风险点

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);}
}

解决方案

延迟双删：

db.update(data);          // 更新主库
cache.delete(key);        // 首次删除
Thread.sleep(500);       // 等待主从同步
cache.delete(key);        // 二次删除

场景描述
- 缓存过期瞬间涌入大量读请求
- 请求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	弱	无	允许短暂脏读的业务