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

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

在高并发系统中，数据库通常作为最终数据源，Redis 作为缓存层提升查询性能。典型读流程是：先查缓存，缓存未命中再查数据库，并把结果写入缓存。

问题出现在写请求上。数据库和缓存是两个独立组件，更新操作无法天然保证原子性。只要其中一步失败，或者并发读写交错，就可能出现缓存和数据库数据不一致。

二、两种更新策略

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

当线程 1 先删除缓存后，如果在更新数据库的时候阻塞住了，这个时候线程 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 监听等方式保证最终一致。

到此这篇关于高并发系统中缓存更新到底是先删缓存还是先更新数据库的文章就介绍到这了,更多相关高并发系统缓存更新内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论