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

最新推荐文章于 2025-05-22 22:34:12 发布
最新推荐文章于 2025-05-22 22:34:12 发布
阅读量179 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/oldboy1999/article/details/126181345
本文探讨了Cache-Aside缓存模式中写请求为何选择删除而非更新缓存的原因。通过模拟两个线程分别进行写和读操作的情景，揭示了在并发情况下可能导致的数据不一致问题，并提出了合理的解决思路。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

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

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

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

在这里插入图片描述

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

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

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

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

数据库缓存模式：Cache-Aside、Read-Through、Write-Through，Redis如何应用？
码觉客的博客
05-28 60
在构建高性能Web应用时，数据库性能瓶颈是常见问题，而缓存技术是提升数据访问速度的有效手段。Redis作为内存存储工具，凭借其快速读写和丰富的数据结构，成为缓存的理想选择。缓存设计的核心挑战是确保缓存与数据库数据的一致性，为此业界提出了三种经典的缓存模式：Cache-Aside、Read-Through和Write-Through。 Cache-Aside：由应用程序主动管理缓存与数据库的一致性，适用于读多写少的场景，灵活性强但一致性管理复杂。 Read-Through：缓存系统作为数据库的代理，自动从数据
高并发下的分布式缓存 | Cache-Aside缓存模式
大厂小码农的博客
08-07 1821
在高并发的场景下，如果我们在更新数据时采用先使缓存失效，再更新数据库，如果某个时刻，同时有一个读请求和一个更新请求操作同一条数据，更新请求刚好让这条数据在缓存失效，然后读请求读取时缓存未命中（因为数据已被更新请求从缓存中删除），就会从数据库中获取旧数据并添加到缓存中。因此，代码需要实现重试机制。如果缓存中没有需要的数据，这叫做缓存未命中，这种情况下，应用程序需要从数据库中获取这个数据，从数据库中拿到数据后，应用程序还会将数据存入缓存，以便下次再需要这个数据时，可以直接从缓存里获取，而不需要再去查数据库。
先更新数据库，再删除缓存的cache aside策略
最新发布
lzf的博客
05-22 825
比如，线程 A 更新数据库，还没来得及删除缓存时，线程 B 发起读请求，发现缓存存在，就读取了旧的缓存数据，然后线程 A 删除了缓存，后续线程 B 又更新了缓存，导致缓存中是旧数据。后续查询该数据时，由于缓存中没有对应数据（已被删除），就会去数据库中查询最新的数据，然后再将查询到的数据更新到缓存中，以供后续查询使用。这段延迟时间是为了确保在数据库更新完成后，可能存在的并发读请求已经从数据库读取到新数据并更新了缓存，此时再次删除缓存可以防止旧数据再次被写入缓存。- 先删除缓存，然后更新数据库。
旁路缓存（Cache-aside）
Asunakiritolove的博客
03-20 9610
1）什么是旁路缓存 旁路缓存策略以数据库（Hbase,redis）中的数据为准，缓存中的数据是按需加载的，它可以分为读策略和写策略。 读策略： 从缓存中读取数据；如果缓存命中，则直接返回数据；如果缓存不命中，则从数据库中查询数据；查询到数据后，将数据写入到缓存中，并且返回给用户。 写策略： 更新数据库中（HBASE，Redis）的记录；删除缓存记录。 2）缓存和数据库的数据一致性问题 错误一：先失效缓存，后更新数据库 1）请求A删除缓存数据 2）请求B查询缓存，未命中 3）请求B往数
Cache Aside Pattern（旁路缓存模式）在写数据的过程中，可以先删除 cache ，后更新 db 么？
qq_27037397的博客
09-07 417
不可以。以mysql 5.6为例，默认隔离级别为RR(可重复读)。线程1对数据进行更新，如果先删除缓存后更新DB，在两步中间若有线程2进行读数据操作，所读取的数据为更新前的数据，让后把此数据放入缓存。在此之后DB为新数据，缓存为旧数据，造成DB与缓存不一致
缓存的Cache Aside模式
weixin_34006965的博客
09-05 194
序 本文主要讲述下缓存的Cache Aside模式。 Cache Aside 有两个要点： 应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。 更新是先更新数据库，成功后，让缓存失效.为什么不是写完数据库后更新缓存？主要是怕两个并发的写操作导致脏数据。 public V read(K key) { V...
简历_基于 Cache Aside 模式解决数据库与缓存一致性问题。
buyaotutou的博客
01-18 969
缓存更新策略的最佳实践方案:1.低一致性需求:使用Redis自带的内存淘汰机制2.高一致性需求:主动更新，并以超时剔除作为兜底方案读操作:缓存命中则直接返回缓存未命中则查询数据库，并写入缓存，设定超时时间写操作:先写数据库，然后再删除缓存要确保数据库与缓存操作的原子性。
分布式技术原理与实战45讲--40 第35讲：经典问题：先更新数据库，还是先更新缓存？
g_z_q_的博客
02-25 940
这一课时我们探讨了缓存和数据库一致性的问题，包括业务开发中如何通过控制更新缓存和数据库的时序，来尽量避免最终一致性问题。在专栏的第 1 课时就讨论过分布式系统的 CAP 理论，经过这么长时间的学习，你是否对 CAP 理论中的不可能三角有了更深的理解呢？在你负责的项目中，是如何应用缓存，又如何保证缓存和数据库数据一致性的呢，欢迎留言进行分享。
Cache-Aside
02-14
上述例子展示了典型的基于Cache-Aside模式的操作流程：`get_data()`函数用于处理读路径上的场景，先检查是否有可用的缓存版本；一旦发现缺失就会触发一次完整的回溯过程直至最终成功填充好临时性的快照供下次快速...
缓存读写策略 - Cache Aside
12-13 811
场景描述 比如一条数据同时存在数据库、缓存，现在你要更新此数据，你会怎么更新？ 先更新数据库？还是先更新缓存？ 其实这两种方式都有问题。 ###（1）先更新数据库，后更新缓存 这样会造成数据不一致。 A 先把数据库更新为 123，由于网络问题，更新缓存的动作慢了。 这时，B 去更新数据库了，改为了 456，紧接着把缓存也更新为 456。 现在 A 更新缓存的请求到了，把缓存更新为了 123。 ...
Cache Aside Pattern
热门推荐
架构师之路
07-11 1万+
在《究竟先操作缓存，还是数据库？》，有同学在评论提出，相关方案违背了“Cache Aside Pattern”的原则，故今天聊一聊Cache Aside Pattern。...
使用缓存redis(cache-aside)保证数据的一致性
l8947943的博客
09-04 2044
项目中常常会涉及到缓存的使用，但是引入缓存会带来一致性问题，需要考虑数据一致性处理。首先看一下操作逻辑， 查询逻辑： 更新或者删除逻辑 在项目中，如果是cache-aside pattern模式，则会考虑使用先更新DB，再去删除cache的操作，原因分析如下： 同时写数据库以及缓存数据，任何一个更新失败都会造成数据不一致。另外事务都成功，无论是先更新缓存还是再更新数据库，还是先更新数据库再更新缓存，这两种情况在并发的情况下也很容易出现双写不成功，操作时序如下图 如果使用更新模式，先更新DB再更..
Cache-Aside Pattern
weixin_34452850的博客
05-15 2880
Cache-Aside Pattern 一. 背景和问题 缓存已经成为了几乎所有应用系统的必备要素。使用缓存可以有效提高系统的读性能，相比于直接读取数据库，吞吐量有了很大的提高。但是，在实际生产环境中，很难保证缓存与数据库中数据的完全一致。程序应采取某种策略，尽可能地保证缓存中的数据是最新的，并且可以检测到缓存中数据失效，并提供相应的解决方案。 简单来说，Cache-Aside Pattern的提...
缓存读写策略-Cache Aside（旁路缓存）策略
weixin_42002747的博客
10-11 6797
Cache Aside（旁路缓存）策略以数据库中的数据为准，缓存中的数据是按需加载的。它可以分为读策略和写策略。 读策略 从缓存中读取数据；如果缓存命中，则直接返回数据；如果缓存不命中，则从数据库中查询数据；查询到数据后，将数据写入到缓存中，并且返回给用户。 写策略 更新数据库中的记录；删除缓存记录。 答疑： 1、不能先删除缓存，后更新数据库 2、出现的问题。不过这种问题出现的几率并不高，原因是缓存的写入通常远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且清空了缓存，请求 A 才更
云计算设计模式（一）Cache Aside模式
qq_38093601的博客
03-28 729
云计算设计模式（一）Cache Aside模式
Cache Aside pattern
weixin_46028606的博客
09-14 374
Cache Aside pattern
【缓存策略】你知道 Cache Aside（缓存旁路）这个缓存策略吗
激流丶的博客
11-12 526
博主从事应用安全和大数据领域，有8年研发经验，5年面试官经验，Java技术专家，WEB架构师，阿里云专家博主，华为云云享专家，51CTO 专家博主。
缓存常用的三种读写策略==》Cache Aside Pattern（旁路缓存模式）
xiyuanda的博客
03-08 4640
Cache Aside Pattern（旁路缓存模式） Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 DB 的结果为准。 下面我们来看一下这个策略模式下的缓存读写步骤。 写 ： 先更新 DB 然后直接删除 cache 。 简单画了一张图帮助大家理解写的步骤。 读 : 从 cache 中读取数据，读取到就直接返回 cache中读取不到的话，就从 DB 中读取数据返回 再把数据放到 cache 中。 .
采用Cache Aside模式解决数据库与缓存的一致性问题 提出面试问题
04-03
<think>好的，我现在需要回答用户关于使用Cache Aside模式解决数据库与缓存一致性问题的请求，并且要提出相关的面试问题。首先，我需要回顾Cache Aside的基本概念和工作流程，确保自己对这一模式的理解正确。 Cache Aside模式，也叫旁路缓存策略，是处理数据库和缓存一致性的常用方法。它的核心思想是在读取数据时先查缓存，命中则返回，未命中则查数据库并更新缓存。写入数据时，先更新数据库，再使缓存失效。这样可以减少缓存与数据库不一致的情况。 接下来，我需要详细分解这个模式的各个步骤，确保用户能够清晰理解。比如，读流程和写流程的具体操作，以及为什么要这样设计。例如，在写操作中，为什么是先更新数据库再删除缓存，而不是更新缓存？这是因为在高并发场景下，如果先更新缓存，可能导致其他线程读取到旧数据，特别是在数据库更新失败的情况下，缓存中的新数据就会与数据库不一致。 然后，我需要考虑用户可能关心的异常情况，比如并发读写时的问题。例如，当两个线程同时更新同一个数据时，可能会出现缓存不一致的情况。这时候需要分析具体的时序，比如经典的“先写数据库再删除缓存”过程中，如果删除缓存失败，该怎么处理。可能需要引入重试机制或者消息队列来确保缓存最终被删除。 另外，用户可能想知道如何在实际项目中实现Cache Aside模式，是否需要配合其他机制，比如延迟双删或者设置缓存过期时间。这些细节都需要在回答中提及，以展示全面的理解。 接下来是面试问题的准备。我需要列举常见的面试问题，覆盖基本原理、异常处理、优缺点、与其他模式的对比等。例如，为什么选择先更新数据库再删除缓存？如何处理缓存删除失败的情况？Cache Aside和Read/Write Through模式有什么区别？这些问题能够帮助面试官评估候选人对缓存一致性问题的理解深度。 同时，还要考虑实际应用中的问题，比如在分布式系统中如何保证原子性操作，或者在高并发场景下如何优化性能。例如，使用异步队列来处理缓存删除失败的情况，或者使用分布式锁来避免并发写入导致的数据混乱。 最后，我需要验证自己的思路是否正确，是否有遗漏的关键点。例如，Cache Aside模式是否适用于所有场景？比如对于写多读少的场景，频繁删除缓存可能导致缓存命中率下降，这时候可能需要其他策略，如Write Behind等。这也是面试中可能被问到的问题，需要在回答中提及。 总结来说，我需要构建一个结构清晰、覆盖全面的回答，分步骤解释Cache Aside模式，并列举相关的面试问题，确保用户不仅理解基本概念，还能应对实际面试中的深入提问。</think>以下是关于Cache Aside模式的详细解析及常见面试问题： --- ### 一、Cache Aside模式核心原理 #### 1. 基本流程（两步操作） **读操作流程**： ```mermaid graph TD A[客户端请求数据] --> B{缓存是否存在?} B -- 存在 --> C[直接返回缓存数据] B -- 不存在 --> D[查询数据库] D --> E[将数据写入缓存] E --> F[返回数据] ``` **写操作流程**： ```mermaid graph TD A[更新数据库] --> B[删除缓存] B --> C{是否需要重试?} C -- 删除失败 --> D[异步队列重试删除] C -- 成功 --> E[结束] ``` #### 2. 关键设计原则 - **写策略**：先更新数据库，再删除缓存（*非更新缓存*） $$操作序列 = Write\ DB \rightarrow Delete\ Cache$$ - **读策略**：缓存未命中时，从数据库加载后回填缓存 $$操作序列 = Read\ Cache \xrightarrow{Miss} Read\ DB \rightarrow Set\ Cache$$ --- ### 二、解决一致性问题的核心机制 #### 1. 应对并发写入问题 - **场景**：两个并发写操作可能导致缓存与数据库不一致 **解决**：通过时序控制确保最终一致性 ```text 时序示例： 1. 线程A更新数据库为X=1 2. 线程B更新数据库为X=2 3. 线程B删除缓存 4. 线程A删除缓存（覆盖了B的删除） → 最终缓存会被后续读请求正确回填 ``` #### 2. 缓存删除失败处理 - **重试机制**：通过消息队列（如Kafka）异步重试删除 ```java // 伪代码示例 try { cache.delete(key); } catch (Exception e) { mq.send(new DeleteCacheMessage(key)); // 发送到重试队列 } ``` - **过期时间兜底**：设置缓存过期时间（如30分钟），防止长期不一致 --- ### 三、典型面试问题及参考答案 #### 1. 为什么选择先更新数据库再删除缓存？ - **参考答案**： 1. 若先删除缓存，在数据库更新完成前可能有请求穿透到数据库，导致旧数据回填缓存 2. 先更新数据库能保证最终一致性，即使删除缓存失败，后续读请求也会回填正确数据 #### 2. 如何处理高并发下的“先删缓存再更新数据库”问题？ - **参考答案**： 可能产生脏读（其他线程在数据库更新前读取旧值回填缓存） **解决方案**： 1. 使用“延迟双删”（更新数据库后延时二次删除缓存） 2. 通过数据库binlog监听（如Canal）异步更新缓存 #### 3. Cache Aside与Read/Write Through模式的区别？ - **参考答案**： - **Cache Aside**：应用层直接管理缓存和数据库 - **Read/Write Through**：缓存作为数据库代理，应用只与缓存交互 - **Write Behind**：异步批量更新数据库，风险是可能丢失数据 #### 4. 如何避免缓存击穿导致数据库压力？ - **参考答案**： 1. 使用互斥锁（如Redis SETNX）控制单线程回填缓存 2. 布隆过滤器拦截无效Key 3. 缓存空值（如`SET key null EX 60`） #### 5. 什么场景下Cache Aside不适用？ - **参考答案**： 1. 写多读少场景：频繁删除缓存降低命中率 2. 强一致性需求：需结合分布式锁或2PC协议 3. 多级缓存架构：需额外协调各级缓存 --- ### 四、优化实践方案 #### 1. 最终一致性增强 ```java // 使用数据库事务日志监听（如MySQL Binlog + Canal） canalClient.subscribe(binlogEvent -> { if (event.isUpdate()) { redis.delete(event.getKey()); // 异步删除缓存 } }); ``` #### 2. 热点数据预加载 ```text 监控系统识别热点Key → 提前加载到缓存 → 设置永不过期+版本号控制 ``` #### 3. 降级策略 - **缓存不可用**：直接访问数据库，记录日志告警 - **数据库压力过大**：限流熔断（如Sentinel） --- ### 五、常见陷阱 1. **双写不一致** - **错误**：并行更新数据库和缓存 - **正确**：严格遵循“先DB后缓存删除” 2. **缓存雪崩** - **错误**：大量缓存同时过期 - **正确**：随机化过期时间（如基础300秒±60秒随机） 3. **脑裂问题** - **场景**：主从同步延迟期间读取到旧数据 - **解决**：写后主库读、缓存设置版本号 --- 该方案在电商秒杀系统中得到验证，需结合监控（如缓存命中率、DB QPS）动态调整策略。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值