高并发系统缓存更新先删缓存还是先更新数据库

一、为什么会有一致性问题

先讲清楚一个场景。在高并发的系统架构里，数据库是那个兜底的数据源，Redis 则像一层快速检索的“翻跟斗”。正常情况下，读请求的路径很明确：先查缓存，缓存里有就直接返回；缓存里没命中，再去数据库里捞，捞出来之后再塞回缓存，方便下一次访问。

但真正让人头疼的，是写操作。数据库和缓存是两个各自独立的组件，更新操作没法天然地保证原子性。哪怕只是其中一步执行失败，或者读写请求在时间上交错一下，就会立刻蹦出数据不一致的问题。

二、两种更新策略

1.先删除缓存，再更新数据库

假设有一个线程 1，它先把缓存删了，结果转头去更新数据库的时候，卡住了——阻塞在那儿。这个时候线程 2 过来读数据，发现缓存里空空如也，那就只好去数据库读取，读到数据后顺手重建缓存。问题来了：线程 1 的数据库更新还没完成，线程 2 读到的还是旧数据，它重建出来的缓存，自然也是脏数据。

所以，先删缓存再更新数据库，这种方案一般不太推荐。后面会提到一种叫“延迟双删”的做法，算是它的补救方案。

2. 先更新数据库，再删除缓存

相比之下，先更新数据库，再去删缓存，就显得合理得多。但这个方案也会带来短暂的数据不一致：在更新完数据库、还没来得及删除缓存的这个极短时间窗口内，读请求可能还是读到旧的缓存数据。不过话说回来，这种短时间的不一致，大多数业务场景其实是能接受的，因为它至少保证了最终一致性。

三、延迟双删：解决先删缓存的问题

延迟双删的核心思路，其实就是为了缓解刚才所说的“先删缓存”带来的脏数据问题。

删除缓存 -> 更新数据库 -> 延迟一段时间 -> 再次删除缓存

第二次删除的目的很明确：就是为了干掉那个被线程 2 重建出来的、仍然装着旧数据的缓存。

为什么一定要等一会再删？

这个延迟主要是为了防止这种情况：线程 2 还没来得及把旧数据重建进缓存，你这边第二次删除就已经执行了，删了个空，结果线程 2 后面慢悠悠地又把旧数据写回去了。不过，这个延迟时间本身不太好精准把控，需要根据实际业务场景来调。

总的说来，延迟双删保证的是最终一致性，彻底解决了重建缓存时塞入旧数据、后续请求一直读到脏数据的问题。

四、MQ 补偿：解决删除缓存失败

不管是先删缓存还是先更新数据库，都避不开一个棘手的问题：删除缓存的操作可能会失败。为了应对这种情况，可以用 MQ 消息队列来做补偿。

更新数据库
删除缓存
如果删除失败，发送 MQ 消息
消费者异步重试删除缓存
多次失败后记录日志/告警

伪代码大概是这样的：

public void updateData(Data data) {
    updateDatabase(data);
    try {
        redis.delete(cacheKey);
    } catch (Exception e) {
        mq.send(new CacheDeleteMessage(cacheKey));
    }
}

消费者端：

public void consume(CacheDeleteMessage message) {
    redis.delete(message.getKey());
}

六、Canal：进一步解耦业务和缓存删除

MQ 补偿虽然能解决失败重试，但业务代码里终究还是要写删除缓存或者发送消息的逻辑。如果想进一步解耦，可以引入 Canal，让它去监听 MySQL 的 binlog。

业务只更新 MySQL
MySQL 产生 binlog
Canal 监听 binlog
解析变更表和主键
发送缓存删除消息
消费者删除 Redis

这么做的好处很明显：

• 业务代码完全不用关心缓存删除这件事
• 多个服务修改同一张表，也能被统一监听到
• 缓存失效的逻辑可以集中管理
• 在复杂系统中，这种解耦方式尤为合适

总结

缓存一致性的关键，其实不在于追求绝对的强一致，而是明确一个原则：数据库才是最终的事实来源，缓存只是可以随时丢弃的加速层。通过删除缓存、失败重试、设置 TTL、监听 binlog 这些手段，足以保证最终一致性。