Cache-Aside缓存模式，为什么先操作数据库而不是先操作缓存？

最新推荐文章于 2025-09-25 03:43:14 发布
原创 最新推荐文章于 2025-09-25 03:43:14 发布 · 204 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#缓存

本文探讨了Cache-Aside缓存模式中写请求为何选择删除而非更新缓存的原因。通过模拟两个线程分别进行写和读操作的情景，揭示了在并发情况下可能导致的数据不一致问题，并提出了合理的解决思路。

首先不了解什么是Cache-Aside缓存模式，可以先跳转到之前写过的文章查看一下，再来阅读本文，传送门在下方。

Cache-Aside缓存模式写请求时，为何是删除缓存，而不是更新缓存

接下来言归正传，用两个线程分别做写操作和读操作，模拟异常情况时缓存和数据库的变化。

在这里插入图片描述

走完上述的流程，就会发现：

线程B在缓存保存的是老数据

线程A在数据库更新的是新数据

发生冲突，所以要先操作数据库，再操作缓存

【高并发基础】Cache Aside 缓存模式背后的思想
chenghan_yang的博客
10-27 2721
凤凰架构》一书中介绍了一种缓存实现方式 —— Cache Aside。大部分业务开发，不需要缓存与数据库的强一致性，Cache Aside 应该是首选方案。下文根据书中的内容进行整理及理解。文末会给出 Cache Aside 模式的应用。
数据库缓存一致性保障：Cache-Aside 模式实现、更新策略配置及延迟双删操作步骤
jingjing45678的博客
07-25 1280
本文系统探讨高并发系统中缓存一致性的核心技术。首先分析缓存脏读、双写失败等典型问题，提出最终一致性优先、失效而非更新等设计原则。然后深入讲解Cache-Aside模式的读写逻辑，包括键设计、过期时间设置和异常处理。针对不同业务场景，提出基于读写频率和一致性要求的精细化更新策略，并重点介绍延迟双删技术解决并发冲突。最后强调建立监控指标和优化闭环的重要性，建议根据业务容忍度平衡一致性与性能。文中提供电商库存、支付系统等具体案例，为构建可靠缓存架构提供实操指导。
【Redis进阶】缓存设计模式
2401_83045332的博客
08-11 2106
在Cache Aside中，应用层需要和缓存和数据库两个数据源打交道，这增加了应用层的复杂度，而Read/Write Through Pattern就是来解决这个问题的，在这两种模式下，应用层只需要将缓存作为主要数据源，不需要感知数据库，更新和读取的任务都交给缓存来处理。缓存设计模式在分布式系统中起着至关重要的作用，它们帮助开发者在不同的业务场景下有效管理缓存，提高系统的性能和响应速度。根据具体的需求和场景，开发者可以选择适合的缓存设计模式，以确保系统的高效和稳定。
【架构师之路】深入了解架构中常见的4种缓存模式及其实现
代码时光
12-09 3712
Cache-Aside（旁路缓存）模式，又叫（懒加载）模式，在这种模式下，缓存的读取和写入由应用程序直接管理。应用程序首先尝试从缓存中读取数据，若缓存未命中，则从数据库中加载数据并将其存储在缓存中；对于更新操作，应用程序直接更新数据库，并更新或删除缓存中的相关数据。Read-Through 模式下，缓存层自动管理数据的读取。当应用程序请求数据时，缓存层会先检查缓存，如果缓存命中则直接返回数据；如果缓存未命中，则缓存层自动从数据库加载数据，并将数据存入缓存。Cache-Aside模式中，
Jedis缓存更新策略：Cache-Aside模式应用
最新发布
gitblog_01114的博客
09-25 1038
Cache-Aside模式（也称为旁路缓存模式）是一种常用的缓存更新策略，它的核心思想是：应用程序直接与数据库交互，同时负责维护缓存的更新。当需要读取数据时，先从缓存中查找，如果存在则直接返回；如果不存在，则从数据库中读取数据，然后更新到缓存中再返回。当需要更新数据时，先更新数据库，然后删除缓存中的旧数据。 ## Cache-Aside模式的工作流程 Cache-Aside模式主要包含以下几个步...
旁路缓存（Cache-aside）
Asunakiritolove的博客
03-20 9902
1）什么是旁路缓存 旁路缓存策略以数据库（Hbase,redis）中的数据为准，缓存中的数据是按需加载的，它可以分为读策略和写策略。 读策略： 从缓存中读取数据；如果缓存命中，则直接返回数据；如果缓存不命中，则从数据库中查询数据；查询到数据后，将数据写入到缓存中，并且返回给用户。 写策略： 更新数据库中（HBASE，Redis）的记录；删除缓存记录。 2）缓存和数据库的数据一致性问题 错误一：先失效缓存，后更新数据库 1）请求A删除缓存数据 2）请求B查询缓存，未命中 3）请求B往数
基于AOP注解+Redisson实现Cache-Aside缓存模式实战
weixin_43076660的博客
03-21 832
在高并发系统中，缓存是提升性能的关键组件。而Cache-Aside模式作为最常用的缓存策略之一，要求开发者手动管理缓存与数据库的交互。本文将结合自定义注解与Redisson客户端，实现声明式的缓存管理方案。🔒 完整防护：解决缓存穿透/击穿/雪崩问题。🛠️ 逻辑删除：支持数据恢复与审计需求。⚡ 双删策略：保障数据库与缓存一致性。🚀 零侵入性：通过注解实现缓存逻辑。(2) 缓存更新注解一、场景需求。(1) 缓存查询注解。(2) 缓存更新注解。(3) 分布式锁注解。3. AOP切面实现。4. 业务层使用示例
简历_基于 Cache Aside 模式解决数据库与缓存一致性问题。
buyaotutou的博客
01-18 1087
缓存更新策略的最佳实践方案:1.低一致性需求:使用Redis自带的内存淘汰机制2.高一致性需求:主动更新，并以超时剔除作为兜底方案读操作:缓存命中则直接返回缓存未命中则查询数据库，并写入缓存，设定超时时间写操作:先写数据库，然后再删除缓存要确保数据库与缓存操作的原子性。
Cache-Aside + 延迟双删 + 异步重试 + Binlog监听
qq_42251944的博客
03-11 1123
若强一致性要求极高（如金融交易），需牺牲性能，采用同步写（如Write-Through）+ 分布式事务。例如：线程A更新DB后，线程B可能在更新期间读取旧数据并写入缓存，延迟双删可清除残留旧数据。：通过消息队列和Binlog监听，将缓存清理操作与主流程解耦，提升系统健壮性。将变更事件（如表名、主键ID、操作类型）发送至Kafka，保证事件不丢失。缓存数据携带版本号（或时间戳），写入时校验版本，防止旧数据覆盖新数据。：确保删除操作事件100%投递到MQ（如Kafka的ACK机制）。
Cache Aside Pattern（旁路缓存模式）在写数据的过程中，可以先删除 cache ，后更新 db 么？
qq_27037397的博客
09-07 466
不可以。以mysql 5.6为例，默认隔离级别为RR(可重复读)。线程1对数据进行更新，如果先删除缓存后更新DB，在两步中间若有线程2进行读数据操作，所读取的数据为更新前的数据，让后把此数据放入缓存。在此之后DB为新数据，缓存为旧数据，造成DB与缓存不一致
缓存的Cache Aside模式
weixin_34006965的博客
09-05 226
序 本文主要讲述下缓存的Cache Aside模式。 Cache Aside 有两个要点： 应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。 更新是先更新数据库，成功后，让缓存失效.为什么不是写完数据库后更新缓存？主要是怕两个并发的写操作导致脏数据。 public V read(K key) { V...
缓存读写策略 - Cache Aside
12-13 846
场景描述 比如一条数据同时存在数据库、缓存，现在你要更新此数据，你会怎么更新？ 先更新数据库？还是先更新缓存？ 其实这两种方式都有问题。 ###（1）先更新数据库，后更新缓存 这样会造成数据不一致。 A 先把数据库更新为 123，由于网络问题，更新缓存的动作慢了。 这时，B 去更新数据库了，改为了 456，紧接着把缓存也更新为 456。 现在 A 更新缓存的请求到了，把缓存更新为了 123。 ...
Cache Aside Pattern
热门推荐
架构师之路
07-11 1万+
在《究竟先操作缓存，还是数据库？》，有同学在评论提出，相关方案违背了“Cache Aside Pattern”的原则，故今天聊一聊Cache Aside Pattern。...
高并发下的分布式缓存 | Cache-Aside缓存模式
大厂小码农的博客
08-07 1981
在高并发的场景下，如果我们在更新数据时采用先使缓存失效，再更新数据库，如果某个时刻，同时有一个读请求和一个更新请求操作同一条数据，更新请求刚好让这条数据在缓存失效，然后读请求读取时缓存未命中（因为数据已被更新请求从缓存中删除），就会从数据库中获取旧数据并添加到缓存中。因此，代码需要实现重试机制。如果缓存中没有需要的数据，这叫做缓存未命中，这种情况下，应用程序需要从数据库中获取这个数据，从数据库中拿到数据后，应用程序还会将数据存入缓存，以便下次再需要这个数据时，可以直接从缓存里获取，而不需要再去查数据库。
使用缓存redis(cache-aside)保证数据的一致性
l8947943的博客
09-04 2185
项目中常常会涉及到缓存的使用，但是引入缓存会带来一致性问题，需要考虑数据一致性处理。首先看一下操作逻辑， 查询逻辑： 更新或者删除逻辑 在项目中，如果是cache-aside pattern模式，则会考虑使用先更新DB，再去删除cache的操作，原因分析如下： 同时写数据库以及缓存数据，任何一个更新失败都会造成数据不一致。另外事务都成功，无论是先更新缓存还是再更新数据库，还是先更新数据库再更新缓存，这两种情况在并发的情况下也很容易出现双写不成功，操作时序如下图 如果使用更新模式，先更新DB再更..
Cache-Aside Pattern
weixin_34452850的博客
05-15 2919
Cache-Aside Pattern 一. 背景和问题 缓存已经成为了几乎所有应用系统的必备要素。使用缓存可以有效提高系统的读性能，相比于直接读取数据库，吞吐量有了很大的提高。但是，在实际生产环境中，很难保证缓存与数据库中数据的完全一致。程序应采取某种策略，尽可能地保证缓存中的数据是最新的，并且可以检测到缓存中数据失效，并提供相应的解决方案。 简单来说，Cache-Aside Pattern的提...
缓存读写策略-Cache Aside（旁路缓存）策略
weixin_42002747的博客
10-11 7205
Cache Aside（旁路缓存）策略以数据库中的数据为准，缓存中的数据是按需加载的。它可以分为读策略和写策略。 读策略 从缓存中读取数据；如果缓存命中，则直接返回数据；如果缓存不命中，则从数据库中查询数据；查询到数据后，将数据写入到缓存中，并且返回给用户。 写策略 更新数据库中的记录；删除缓存记录。 答疑： 1、不能先删除缓存，后更新数据库 2、出现的问题。不过这种问题出现的几率并不高，原因是缓存的写入通常远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且清空了缓存，请求 A 才更
采用Cache Aside模式解决数据库与缓存的一致性问题 提出面试问题
04-03
例如，在写操作中，为什么是先更新数据库再删除缓存，而不是更新缓存？这是因为在高并发场景下，如果先更新缓存，可能导致其他线程读取到旧数据，特别是在数据库更新失败的情况下，缓存中的新数据就会与数据库不一致...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值