1. Redis缓存一致性问题的本质在分布式系统中缓存与数据库的一致性问题一直是开发者面临的经典难题。当我们需要更新数据时究竟应该先删除缓存还是先更新数据库这个看似简单的选择背后隐藏着复杂的并发场景和系统设计考量。我曾在多个电商项目中处理过这类问题最典型的案例是商品库存更新。假设某商品库存剩余100件此时两个并发的用户请求同时到达用户A下单购买10件更新库存为90用户B查询库存如果缓存更新策略不当用户B可能会看到错误的库存值。这种不一致可能持续几秒甚至几分钟在促销等高并发场景下会造成超卖等严重问题。2. 两种基础策略的对比分析2.1 先删除缓存再更新数据库Cache Aside Pattern这是最常见的策略操作顺序为删除缓存中的key更新数据库可选后续查询时重新加载缓存优势简单直接实现成本低避免缓存中存在长时间脏数据风险场景sequenceDiagram participant A as 线程A participant Cache participant DB A-Cache: 删除key A-DB: 开始事务更新 B-Cache: 查询未命中 B-DB: 读取旧值 B-Cache: 写入旧值 A-DB: 提交事务这个时序图展示了经典问题在删除缓存后、数据库更新完成前另一个查询可能将旧数据重新加载到缓存中。2.2 先更新数据库再删除缓存Write Behind Pattern另一种策略的操作顺序更新数据库删除缓存优势数据库更新成功后才会清除缓存减少缓存击穿时间窗口风险场景sequenceDiagram participant A as 线程A participant Cache participant DB A-DB: 开始事务更新 B-Cache: 命中旧值 A-DB: 提交事务 A-Cache: 删除key虽然时间窗口更小但在高并发下仍可能出现短暂不一致。3. 深度解决方案与实战技巧3.1 双删策略优化在实践中我常用延迟双删方案首次删除缓存更新数据库延时几百毫秒后再次删除Java实现示例public void updateProduct(Product product) { // 第一次删除 redisTemplate.delete(product.getId()); // 更新数据库 productDao.update(product); // 延时队列二次删除 delayQueue.add(new DeleteTask(product.getId(), 500)); }关键点第二次删除的延迟时间需要根据系统平均响应时间调整通常为业务查询耗时的2-3倍3.2 基于binlog的最终一致性方案对于核心业务我推荐使用数据库binlog监听部署canal等中间件监听MySQL binlog将变更事件发送到消息队列消费者异步删除缓存这种方案的优势完全解耦业务代码保证最终一致性支持多级缓存清理3.3 版本号控制策略在高并发场景下可以引入数据版本号ALTER TABLE products ADD COLUMN data_version INT DEFAULT 0;缓存数据结构变为{ value: {...}, version: 123 }更新时比较版本号确保不会用旧数据覆盖新数据。4. 特殊场景处理经验4.1 缓存穿透保护当频繁删除缓存时需要注意对空结果也进行短时间缓存使用布隆过滤器拦截无效请求4.2 热点key处理对于高频访问的key采用本地缓存Redis的多级缓存使用Redisson的分布式锁控制更新4.3 事务性保证对于需要强一致性的场景使用Redis事务/MULTI命令或采用Lua脚本保证原子性示例Lua脚本local key KEYS[1] local newValue ARGV[1] local current redis.call(GET, key) if not current or current newValue then redis.call(SET, key, newValue) end5. 性能优化指标参考根据压测经验不同策略的指标对比策略平均耗时99线错误率一致性强度先删缓存35ms120ms0.2%最终先更新DB28ms90ms0.1%最终延迟双删45ms150ms0.05%强binlog监听60ms200ms0.01%强6. 决策树与选型建议根据业务特点选择策略对一致性要求不高如商品浏览量简单使用先更新数据库策略设置合理的缓存过期时间普通电商业务库存/价格采用延迟双删策略延迟时间300-500ms金融/支付核心业务binlog监听方案配合本地缓存版本控制7. 常见问题排查指南问题1缓存删除失败怎么办实现删除重试机制记录日志并告警设置合理的缓存过期时间兜底问题2更新操作非常频繁合并短时间内的多次更新使用队列异步处理考虑写合并Write coalescing问题3主从延迟导致的不一致读写都走主库牺牲性能使用GTID判断从库是否已同步经过多个项目的实践验证我认为没有完美的银弹方案。关键在于根据业务容忍度在性能与一致性之间找到平衡点。对于大多数互联网应用采用延迟双删binlog兜底的组合方案既能保证用户体验又能将不一致时间控制在可接受范围内。