一、为什么需要关注一致性在互联网高并发场景中Redis作为缓存层几乎成了标配。但引入缓存后一个经典问题随之而来如何保证Redis缓存与数据库中的数据保持一致这个问题之所以棘手是因为独立存储数据库和Redis是两套独立的存储系统没有原生分布式事务支持。并发交织高并发下读请求和写请求的操作顺序难以预测。网络与故障分布式环境下存在网络延迟、节点宕机、主从同步延迟等。一个真实案例某电商网站在大促期间由于缓存与数据库不一致导致商品价格显示错误用户下单后实际扣款金额与显示不符引发大量客诉。这就是不一致的代价。二、一致性的三种级别更精细的定义级别说明实现代价适用场景强一致性任何时刻、任何节点读到的最新写入数据需要分布式锁/同步协议性能极低银行余额、库存扣减极少用缓存最终一致性允许短暂的不一致但保证经过“有限时间”后数据一致高吞吐易实现大部分业务用户昵称、商品描述、文章阅读数弱一致性不保证最终一致可能出现永久不一致无代价日志、排行榜允许误差实际开发中我们追求的是最终一致性并将不一致窗口控制在毫秒级。三、常见更新策略详解含并发时序图3.1 先更新数据库再删除缓存推荐策略原理流程text写请求开始事务 → 更新数据库 → 提交事务 → 删除缓存 读请求查缓存 → 未命中 → 查数据库 → 写缓存为什么删除而不是更新更新缓存需要业务计算例如缓存是一个复杂的聚合对象用户订单数等级每次更新都要重新计算开销大。删除是幂等的多次删除效果相同不会出错。懒加载只有真正被读取时才填充缓存避免“写多读少”场景下浪费资源。详细代码含事务、异常处理、重试javaService Slf4j public class UserService { Autowired private UserMapper userMapper; Autowired private RedisTemplateString, String redisTemplate; /** * 更新用户信息保证最终一致性 * param user 新用户信息 */ Transactional(rollbackFor Exception.class) public void updateUser(User user) { // 1. 更新数据库业务核心 int rows userMapper.updateById(user); if (rows 0) { throw new BusinessException(更新失败用户不存在); } // 2. 删除缓存允许失败但要重试 String key user: user.getId(); try { redisTemplate.delete(key); log.info(删除缓存成功, key{}, key); } catch (Exception e) { log.error(删除缓存失败, key{}, key, e); // 这里可以发送MQ异步重试或者记录到重试表 sendRetryMessage(key); } } /** * 查询用户先读缓存再读库最后回填 */ public User getUser(Long id) { String key user: id; // 1. 尝试读缓存 String cached redisTemplate.opsForValue().get(key); if (cached ! null) { // 注意需要处理空值缓存防止穿透 if (.equals(cached)) { return null; } return JSON.parseObject(cached, User.class); } // 2. 读数据库 User user userMapper.selectById(id); // 3. 回填缓存设置合理的过期时间避免一直占用内存 if (user ! null) { redisTemplate.opsForValue().set(key, JSON.toJSONString(user), 3600, TimeUnit.SECONDS); // 1小时过期作为兜底 } else { // 缓存空对象防止缓存穿透过期时间短一些 redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); } return user; } }并发不一致窗口分析重要很多人认为这个策略是绝对安全的但在读写分离主从延迟场景下仍然有极短的不一致窗口text时间轴 T1: 写线程A 更新主库 user新值 (commit) T2: 写线程A 删除缓存 (成功) T3: 读线程B 缓存未命中去读从库 T4: 从库尚未同步主库binlog读到旧值 T5: 读线程B 将旧值写入缓存 T6: 主从同步完成从库变为新值 结果缓存中是旧值数据库是新值窗口时长≈ 主从延迟通常0.1~2秒 读请求耗时~10ms。发生概率低并发下几乎为0高并发大事务从库压力大时可能频发。解决方案采用“延迟双删”或“订阅binlog”方案见第四章。什么时候该用这个策略✅ 读多写少绝大多数业务✅ 可以容忍毫秒~秒级的不一致✅ 数据库非读写分离或读写分离但延迟很低3.2 先删除缓存再更新数据库不推荐但需理解并发问题详细时序时间线程A写线程B读数据库缓存T1删除缓存 (keyuser:1)-V1(旧)空T2-读缓存未命中V1空T3-读数据库得到V1V1空T4-将V1写入缓存V1V1T5更新数据库为V2 (commit)-V2V1脏数据脏数据持续时间直到下一次删除或过期。如果写入缓存时设置了TTL1小时那么脏数据会存在1小时。为什么还有人用在写操作非常频繁且读操作很少的极端场景下先删缓存可以减少一次缓存删除操作因为后面可能再次覆盖。但弊远大于利不推荐。改进方案延迟双删Delayed Double DeletejavaTransactional public void updateUserWithDoubleDelete(User user) { String key user: user.getId(); // 第一次删除 redisTemplate.delete(key); // 更新数据库 userMapper.updateById(user); // 延迟一段时间关键参数 int delayMs calculateDelay(); // 动态计算 try { Thread.sleep(delayMs); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } // 第二次删除 redisTemplate.delete(key); } /** * 计算合理的延迟时间 * 公式延迟 主从预估最大延迟 读请求平均耗时 缓冲 * 通常取值500~1500ms */ private int calculateDelay() { // 可以从配置中心读取动态值或根据监控自适应 return 800; // 毫秒 }延迟时间如何精确确定监控主从延迟的P99值如通过SHOW SLAVE STATUS的Seconds_Behind_Master。加上业务侧读请求的平均耗时例如50ms。再乘以1.5~2倍的安全系数。缺点延迟双删会导致写请求的响应时间增加因为sleep不适用于低延迟要求的接口。3.3 先更新数据库再更新缓存强烈不推荐并发写导致缓存被旧值覆盖时间线程A线程B数据库缓存T1读旧值V1-V1V1T2更新DB为V2-V2V1T3-读旧值V1V2V1T4-更新DB为V3V3V1T5更新缓存为V2-V3V2旧值覆盖新值另外的问题如果更新缓存需要关联查询会拖慢写请求。缓存可能被从未被读取的数据占用内存。唯一适用场景缓存的数据就是数据库中的原始值且更新代价极低如计数器且业务允许覆盖。即便如此也建议用删除代替更新。四、极端场景下的解决方案深度展开4.1 读写并发导致的不一致针对“先更新DB再删缓存”的漏洞方案一订阅binlogCanal—— 推荐原理MySQL的binlog记录了所有数据变更Canal伪装成从库拉取binlog然后异步删除缓存。详细配置步骤缩短版但关键点保留MySQL开启binlog格式设为ROW。部署Canal Server配置canal.properties。编写Canal Client解析Entry提取表名、主键ID。删除对应缓存。java// Canal Client核心代码更详细的解析逻辑 CanalEventListener public class BinlogCacheCleaner { Autowired private RedisTemplateString, String redisTemplate; ListenPoint(destination example, schema shop, table {user}) public void onUserChange(CanalEntry.Entry entry) { // 获取变更类型 CanalEntry.EventType eventType entry.getHeader().getEventType(); if (eventType ! CanalEntry.EventType.UPDATE eventType ! CanalEntry.EventType.DELETE) { return; } for (CanalEntry.RowData rowData : entry.getRowDataList()) { // 对于UPDATE获取修改后的ID对于DELETE获取删除前的ID ListCanalEntry.Column columns (eventType CanalEntry.EventType.DELETE) ? rowData.getBeforeColumnsList() : rowData.getAfterColumnsList(); String userId null; for (CanalEntry.Column col : columns) { if (id.equals(col.getName())) { userId col.getValue(); break; } } if (userId ! null) { String cacheKey user: userId; redisTemplate.delete(cacheKey); log.info(通过binlog删除缓存, key{}, eventType{}, cacheKey, eventType); } } } }优势业务代码零侵入更新数据库后无需手动删缓存。天然解决主从延迟问题因为binlog是从主库拉取的已经是最新数据。劣势架构复杂引入Canal和MQ。删除缓存失败时需要重试机制可配合MQ。方案二设置极短的缓存过期时间如果业务允许将缓存TTL设为1~5秒那么不一致窗口最多也就几秒。适合对一致性要求不极高、但要求简单的场景。javaredisTemplate.opsForValue().set(key, value, 3, TimeUnit.SECONDS);4.2 缓存穿透/击穿/雪崩生产级实现缓存穿透查询不存在的数据现象大量请求查询一个不存在的ID缓存没有每次都打到数据库可能压垮DB。解决方案一布隆过滤器javaComponent public class BloomFilterService { private BloomFilterString bloomFilter; PostConstruct public void init() { // 预计数据量100万期望误判率0.01 bloomFilter BloomFilter.create(Funnels.stringFunnel(Charset.defaultCharset()), 1000000, 0.01); // 从数据库加载所有存在的user id ListLong allIds userMapper.selectAllIds(); for (Long id : allIds) { bloomFilter.put(user: id); } } public boolean mightExist(String key) { return bloomFilter.mightContain(key); } } // 在查询前使用 if (!bloomFilterService.mightExist(user: id)) { return null; // 直接返回不查库 }注意布隆过滤器有误判认为存在实际不存在所以仍需配合空值缓存。解决方案二缓存空对象javaUser user userMapper.selectById(id); if (user null) { // 缓存空值过期时间短60秒 redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); return null; }缓存击穿热点Key过期现象一个热点Key如秒杀商品在过期瞬间大量并发请求同时查询数据库。解决方案互斥锁推荐javapublic Product getHotProduct(Long id) { String key product: id; String lockKey lock:product: id; // 1. 先查缓存 String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseObject(cached, Product.class); } // 2. 尝试获取分布式锁使用setnx 过期时间 Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { // 双重检查避免其他线程已经填充了缓存 cached redisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseObject(cached, Product.class); } // 查询数据库 Product product productMapper.selectById(id); if (product ! null) { redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 3600, TimeUnit.SECONDS); } else { redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); } return product; } finally { // 释放锁需要确保是自己的锁用lua脚本或value判断 redisTemplate.delete(lockKey); } } else { // 未获取到锁自旋等待一小段时间后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return getHotProduct(id); // 递归重试 } }其他方案逻辑过期缓存不设置物理过期而是存储一个逻辑过期时间由后台异步刷新但实现更复杂。缓存雪崩现象大量缓存同时过期或Redis宕机导致所有请求直接打到DB。解决方案过期时间加随机偏移javaint baseTtl 3600; int randomOffset new Random().nextInt(300); // 0~300秒随机 redisTemplate.opsForValue().set(key, value, baseTtl randomOffset, TimeUnit.SECONDS);Redis高可用使用Redis Cluster或Sentinel。限流降级在应用层对DB请求进行限流如Sentinel、Hystrix。4.3 强一致性场景方案权衡性能如果业务真的要求强一致性例如扣减库存、转账建议不使用缓存直接读写数据库。如果非要使用缓存可以采用读写锁JVM级别但仅适用于单机部署且会严重降低并发。javaService public class ConsistentInventoryService { private final ReentrantReadWriteLock lock new ReentrantReadWriteLock(); public void deductStock(Long productId, int quantity) { lock.writeLock().lock(); try { // 读数据库最新库存 int stock inventoryMapper.selectStock(productId); if (stock quantity) { inventoryMapper.updateStock(productId, stock - quantity); // 同步更新缓存 redisTemplate.opsForValue().set(stock: productId, String.valueOf(stock - quantity)); } else { throw new InsufficientStockException(); } } finally { lock.writeLock().unlock(); } } public Integer getStock(Long productId) { lock.readLock().lock(); try { String cached redisTemplate.opsForValue().get(stock: productId); if (cached ! null) { return Integer.parseInt(cached); } Integer stock inventoryMapper.selectStock(productId); redisTemplate.opsForValue().set(stock: productId, String.valueOf(stock)); return stock; } finally { lock.readLock().unlock(); } } }缺点写操作会阻塞所有读操作吞吐量急剧下降只适合极低并发场景。五、终极方案阿里巴巴Canal 消息队列原第五章深度细化为什么说是终极方案完全解耦业务代码不需要关心缓存删除只需正常更新数据库。可靠消息队列保证至少一次投递删除失败可重试。顺序性binlog天然有序可保证同一行的更新顺序正确。完整架构组件textMySQL主库 (binlog) → Canal Server (模拟从库) → Canal Client (可选) → RocketMQ/Kafka (topic: binlog_topic) → 消费者服务 → Redis删除关键配置细节Canal RocketMQCanal 配置conf/example/instance.propertiesproperties# 数据库连接 canal.instance.master.address127.0.0.1:3306 canal.instance.dbUsernamecanal canal.instance.dbPasswordcanal # 只订阅需要的表 canal.instance.filter.regexshop\\.user,shop\\.order # 开启MQ模式 canal.mq.topicbinlog_topic canal.mq.partitionHashshop\\.user:id,shop\\.order:user_id消费者实现RocketMQjavaComponent RocketMQMessageListener(topic binlog_topic, consumerGroup cache_consumer) public class BinlogConsumer implements RocketMQListenerMessageExt { Autowired private RedisTemplateString, String redisTemplate; Override public void onMessage(MessageExt message) { byte[] body message.getBody(); // 解析Canal的protobuf格式可使用Canal提供的FlatMessage CanalMessage canalMessage CanalMessage.parseFrom(body); String table canalMessage.getTable(); if (user.equals(table)) { for (CanalRow row : canalMessage.getRows()) { String userId row.getAfterColumns().get(id); String cacheKey user: userId; // 删除操作带重试 retryDelete(cacheKey, 3); } } } private void retryDelete(String key, int maxRetries) { for (int i 0; i maxRetries; i) { try { redisTemplate.delete(key); log.info(通过MQ删除缓存成功, key{}, key); return; } catch (Exception e) { log.error(删除失败重试 {}/{}, i1, maxRetries, e); try { Thread.sleep(100 * (i 1)); } catch (InterruptedException ignored) {} } } // 超过重试次数记录到死信队列或告警 log.error(删除缓存最终失败, key{}, key); } }注意事项Canal的高可用部署多个Canal Server使用ZooKeeper协调。消费幂等性消息可能重复投递删除操作本身幂等没问题。延迟监控从binlog产生到缓存删除的端到端延迟建议500ms。六、生产环境最佳实践总结大幅细化策略选择决策树text是否允许最多1秒的不一致 ├─ 是 → 读写分离 │ ├─ 是 → CanalMQ或延迟双删 │ └─ 否 → 先更新DB再删缓存 └─ 否 → 强一致性要求 ├─ 是 → 直接读数据库不用缓存 └─ 否 → 先更新DB再删缓存 短TTL关键监控指标必须落地指标计算方式告警阈值处理方式缓存命中率缓存命中次数 / 总请求次数 85%检查过期策略、是否存在穿透不一致时长定时任务对比最新DB和缓存的时间差 2秒检查主从延迟、Canal消费lag删除缓存失败率删除异常次数 / 总删除次数 0.1%检查Redis连接池、网络Canal消费延迟当前binlog时间戳 - 最后消费时间戳 3秒增加消费者线程或扩容降级方案当缓存出问题时javaComponent public class CacheDegradeService { Value(${cache.degrade.enabled:false}) private boolean degradeEnabled; public User getUser(Long id) { if (degradeEnabled) { // 降级直接查数据库 return userMapper.selectById(id); } // 正常缓存流程 return getUserWithCache(id); } }面试高频追问与回答新增Q1为什么删缓存比更新缓存好A更新缓存需要业务计算且可能覆盖其他并发写操作删除缓存是幂等的下次读时懒加载避免“写多读少”时浪费资源。Q2延迟双删的延迟时间怎么定A延迟 主从最大延迟P99 读请求平均耗时 200ms缓冲一般取500~1000ms。可通过监控动态调整。Q3如果删除缓存失败了怎么办A记录日志发送MQ异步重试同时可设置较短的缓存TTL如60秒作为兜底即使删除失败过期后也会自动刷新。Q4Canal方案会不会导致消息积压A会如果消费速度跟不上binlog产生速度。解决方案增加消费者并行度RocketMQ增加queue数或者对不重要表过滤掉。Q5缓存和数据库完全一致能做到吗A在分布式理论下做不到强一致性除非牺牲性能和可用性如使用分布式锁。一般做到最终一致性即可。七、写在最后一句话总结没有完美的方案只有适合的方案。大多数场景先更新数据库再删除缓存简单可靠覆盖99%需求。读写分离且对一致性要求稍高先更新数据库 延迟双删。追求极致性能和零侵入Canal MQ。强一致性直接读数据库或用读写锁性能极低。最后一条建议一定要给缓存设置合理的过期时间这是最后一道防线。即使所有删除操作都失败了缓存也会自动淘汰最终一致。希望这篇文章能帮你搞懂Redis与数据库一致性问题。如有疑问欢迎评论区交流