1. 为什么数据库与缓存一致性是个难题第一次在线上环境遇到缓存与数据库不一致的问题是在一个促销活动的高峰期。当时商品库存显示还有1000但实际下单时却提示库存不足。排查后发现Redis里的库存数据比数据库慢了整整30秒这30秒里已经有500多笔订单创建。这种数据不一致问题在分布式系统中几乎无法完全避免但我们可以通过合理的架构设计将其影响降到最低。数据库与缓存的不一致主要源于三种场景更新数据库成功但更新缓存失败缓存自动过期后数据库有更新但未及时回填并发写操作导致执行顺序错乱关键认知缓存不是数据库的镜像而是性能与一致性的权衡产物。我们需要根据业务场景选择合适的一致性级别。2. 主流解决方案的技术实现2.1 Cache Aside Pattern旁路缓存这是最常用的模式核心逻辑// 读流程 1. 先查缓存命中则返回 2. 未命中时查数据库 3. 将结果写入缓存设置合理TTL // 写流程 1. 更新数据库 2. 删除缓存非更新为什么是删除而不是更新缓存避免两个并发的写操作导致缓存脏数据减少计算开销可能涉及复杂聚合实测案例某电商平台商品详情页采用该模式后缓存不一致时间从分钟级降至秒级。2.2 Read/Write Through读写穿透由缓存组件统一管理数据流动读时自动回填缓存写时同步更新缓存和数据库适合场景缓存组件支持事务如Redis 6.0数据模型较简单2.3 Write Behind Caching异步回写高风险但高性能的方案先更新内存缓存异步批量持久化到数据库使用禁忌金融交易类业务绝对禁用必须配合WAL日志防丢失3. 进阶场景的解决方案3.1 双写一致性保障对于核心业务数据可以采用def update_data(key, value): # 先写数据库 db.update(key, value) # 再删缓存带重试 retry(3, lambda: cache.delete(key)) # 最终一致性检查 async_check_consistency(key)3.2 分布式锁方案高并发下的优化写法RLock lock redisson.getLock(product_ sku); try { lock.lock(); // 执行更新操作 updateDBAndCache(); } finally { lock.unlock(); }3.3 延迟双删策略针对极端并发场景先删除缓存更新数据库休眠500ms取决于业务耗时再次删除缓存4. 实战避坑指南4.1 缓存雪崩预防错误做法所有key设置相同TTL正确方案基础TTL 随机抖动如30min±5min永不过期后台更新4.2 热点Key处理我们曾遇到单商品QPS 10w的案例本地缓存Redis多级缓存使用bloom filter过滤无效请求4.3 监控指标建设必须监控的核心指标指标项报警阈值缓存命中率90%数据库查询突增同比上涨300%不一致持续时间5s5. 不同业务场景的选型建议5.1 强一致性要求如支付系统分布式事务TCC/SAGA同步写串行化读牺牲部分性能5.2 最终一致性如商品信息消息队列补偿版本号比对定时对账任务5.3 弱一致性如UV统计直接内存计算定期全量刷新允许短期误差在最近一次大促中我们通过组合使用延迟双删本地缓存降级将核心业务的不一致时间窗口控制在200ms内。记住没有银弹方案只有适合业务现状的权衡选择。