如何保持数据库和缓存的一致性

最新推荐文章于 2025-07-25 13:56:34 发布
最新推荐文章于 2025-07-25 13:56:34 发布
阅读量1.9k 收藏 2
点赞数
分类专栏： redis
本文介绍了更新缓存的三种策略：失效、命中和更新。讨论了写操作中先使缓存失效后更新数据库、先更新数据库再更新缓存可能导致的数据不一致问题。还给出了更新数据库成功但失效缓存失败的解决办法，如重试、定期全量更新、设置失效期等。

更新缓存策略
失效：应用程序从cache取数据，没有得到，则从数据库取数据，然后将数据放入cache 
命中：应用从cache取数据，若取到则返回 
更新：把数据更新到数据库，然后使cache失效 
借用网上两张图 
è¿éåå¾çæè¿°

è¿éåå¾çæè¿°
有没有其他策略？
读操作容易理解，现在讨论一下写的操作

如果先使cache失效，后更新数据库，是否可行
这么做引发的问题是，如果A,B两个线程同时要更新数据，并且A,B已经都做完了删除缓存这一步，接下来，A先更新了数据库，C线程读取数据，由于缓存没有，则查数据库，并把A更新的数据，写入了缓存，最后B更新数据库。那么缓存和数据库的值就不一致了。

如果先把数据库更新，然后把cache更新（不是失效），是否可行
这么做引发的问题是，如果A,B两个线程同时做数据更新，A先更新了数据库，B后更新数据库，则此时数据库里存的是B的数据。而更新缓存的时候，是B先更新了缓存，而A后更新了缓存，则缓存里是A的数据。这样缓存和数据库的数据也不一致。

如果更新数据时，更新数据库成功，而失效cache时失败怎么解决？
1、对删除缓存进行重试，数据的一致性要求越高，我越是重试得快。 
2、定期全量更新，简单地说，就是我定期把缓存全部清掉，然后再全量加载。 
3、给所有的缓存一个失效期。（绝招，任何不一致，都可以靠失效期解决，失效期越短，数据一致性越高。但是失效期越短，查数据库就会越频繁。因此失效期应该根据业务来定）

不要缓存那些对数据一致性要求很高的数据
--------------------- 

原文：https://blog.youkuaiyun.com/sinat_16712671/article/details/76130829 
 

【数据库与缓存保持一致性】
小呆鸟blog
12-28 1573
数据库和缓存一致性
简历_基于 Cache Aside 模式解决数据库与缓存一致性问题。
buyaotutou的博客
01-18 1017
缓存更新策略的最佳实践方案:1.低一致性需求:使用Redis自带的内存淘汰机制2.高一致性需求:主动更新，并以超时剔除作为兜底方案读操作:缓存命中则直接返回缓存未命中则查询数据库，并写入缓存，设定超时时间写操作:先写数据库，然后再删除缓存要确保数据库与缓存操作的原子性。
趣说 ｜ 数据库和缓存如何保证一致性？
小林coding
03-31 3886
数据库和缓存如何保证一致性？ 一天，老板说「最近公司的用户越来越多了，但是服务器的访问速度越来越差的，阿旺帮我优化下，做好了给你画个饼！」。 程序员阿旺听到老板口中的「画饼」后就非常期待，没有任何犹豫就接下了老板给的这个任务。 阿旺登陆到了服务器，经过一番排查后，确认服务器的性能瓶颈是在数据库。 这好办，给服务器加上 Redis，让其作为数据库的缓存。 这样，在客户端请求数据时，如果能在缓存中命中数据，那就查询缓存，不用在去查询数据库，从而减轻数据库的压力，提高服务器的性能。 先更新数据库，还是先更新缓存
数据库缓存一致性保障：Cache-Aside 模式实现、更新策略配置及延迟双删操作步骤
最新发布
jingjing45678的博客
07-25 1119
本文系统探讨高并发系统中缓存一致性的核心技术。首先分析缓存脏读、双写失败等典型问题，提出最终一致性优先、失效而非更新等设计原则。然后深入讲解Cache-Aside模式的读写逻辑，包括键设计、过期时间设置和异常处理。针对不同业务场景，提出基于读写频率和一致性要求的精细化更新策略，并重点介绍延迟双删技术解决并发冲突。最后强调建立监控指标和优化闭环的重要性，建议根据业务容忍度平衡一致性与性能。文中提供电商库存、支付系统等具体案例，为构建可靠缓存架构提供实操指导。
缓存与数据库一致性保证
lsy90的博客
08-16 471
因为感觉写的太好了  原文地址：http://www.36dsj.com/archives/43950 本文主要讨论这么几个问题： (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一、需求缘起 上一篇《》(点击查看)引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库
谈谈如何确保数据的一致性
qq_42984761的博客
12-10 8949
谈谈如何确保数据的一致性数据库必须具备的四个特性背景什么是接口的幂等性？幂等性在哪里会用到？技术方案总结 数据库必须具备的四个特性 1：原子性：事务包含的所有操作要么全部成功，要么全部失败回滚;成功必须要完全应用到数据库，失败则不能对数据库产生影响； 2：一致性：事务执行前和执行后必须处于一致性状态， 例：用户A和用户B的前加起来一共是5000; 无论AB用户之间是如何相互转换的，事务结束后两个用...
如何保证数据库和缓存数据一致
m0_57015193的博客
05-13 199
部分场景下，对于数据库中需要频繁访问的热点数据，会保存一份拷贝在 redis 缓存，提高查询效率，具体流程如下： 对于查询操作，首先从缓存中查询，查到直接返回，否则从数据库查询，将查询结果保存在缓存中，然后返回 对于更新操作，先修改数据库，再删除缓存 上述流程的执行就需要保证数据库和缓存数据一致。这里每次更新操作后删除缓存的原因在于： 部分场景下缓存中的数据是数据库数据加工后的结果，可能需要联合其它数据一起计算，因此暂时删除掉 使用缓存的主要原因在于提高查询效率，数据库中的数据不一定都会查到，因此先删
分布式之数据库和缓存双写一致性方案解析
01-27
本文由以下三个部分组成1、讲解缓存更新策略2、对每种策略进行缺点分析3、针对缺点给出改进方案先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的...
数据库和缓存如何保证一致性？
m0_67698950的博客
06-28 1259
有了这个想法后，就准备开始着手优化服务器，但是挡在在他前面的是这样的一个问题。 由于引入了缓存，那么在数据更新时，不仅要更新数据库，而且要更新缓存，这两个更新操作存在前后的问题：没想到太多，他觉得最新的数据肯定要先更新数据库，这样才可以确保数据库里的数据是最新的，于是他就采用了「先更新数据库，再更新缓存」的方案。经过几个夜晚的折腾，终于「优化好了服务器」，然后就直接上线了，自信心满满跑去跟老板汇报。老板不懂技术，自然也没多虑，就让后续阿旺观察下服务器的情况，如果效果不错，就谈画饼的事情。观察了好几天，发现
redis保持数据的一致性
weixin_45080272的博客
07-13 1318
目录redis是如何保持数据的一致性在读取缓存数据时更新缓存方面将不一致分三种情况说明 redis是如何保持数据的一致性 保持数据一致性，就是保持缓存和数据库数据的一致性问题 一般来说，只要你用到了缓存，不管是Redis还是memcache，就可能会涉及到数据库缓存与数据的一致性问题。 在读取缓存数据时 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。 更新缓存方面 三种更新策略 1、先更新数据库，再更新缓存 2、先删除缓存，再更新数据库 3、先更新数据库，再删除缓存（
Redis 与数据库数据一致性保证详解
lssffy的博客
09-11 2685
缓存穿透是指用户频繁请求一个数据库中不存在的数据，因为缓存中没有命中，而数据库查询返回的结果为空，缓存也没有存储该空值，导致每次请求都会打到数据库，给数据库带来巨大的压力。在 Read-Through 模式下，缓存层与数据库之间紧密耦合，所有数据的读取操作都通过缓存进行，当缓存中没有数据时，由缓存层自动加载数据库中的数据并返回给客户端。：缓存击穿是指某个热点数据由于设置了过期时间，当缓存失效的瞬间，多个请求同时请求该数据，导致这些请求直接访问数据库，并且可能导致数据库压力过大。
8种方案，保证缓存和数据库的最终一致性
mnhpo_Q的博客
03-18 5060
我们通常使用缓存机制来提升系统的性能，缓存系统下的读写操作，一般都需要操作数据库与缓存。对于读操作，一般是先查询缓存，查询不到再查询数据库，最后回写进缓存。而对于写操作，究竟是先删除(更新)缓存，再更新数据库，还是先更新数据库，再删除(更新)缓存呢？由于对数据库以及缓存的整体操作，并不是原子性的，再加上读写并发，究竟什么样的方案可以保证数据库与缓存的一致性呢？下面介绍8种方案，配合读写时序图，希望你能从其中了解到保证一致性的设计要点。简单直接，适用于对数据一致性要求较低或者写请求很少的业务。
06 | 数据同步：主从库如何实现数据一致？
weixin_56666956的博客
04-18 542
b3、随着主库不断接收新的写操作，它在缓冲区中的写位置会逐步偏离起始位置，我们通常用偏移量来衡量这个偏移距离的大小，对主库来说，对应的偏移量就是。所以，通过调大这个参数，可以减。，然后加载 RDB 文件。b4、同样，从库在复制完写操作命令后，它在缓冲区中的读位置也开始逐步偏移刚才的起始位置，此时，从库已复制的偏移量。a1、在部署主从集群的时，手动选择一个从库（比如选择内存资源配置较高的从库），用于级联其他的从库。a2、然后，我们再选择一些从库（例如三分之一的从库），让它们和刚才所选的从库，建立起主从关系。
一文搞懂缓存和数据库的一致性问题（全面总结）
lans_g的博客
05-08 8608
缓存是我们经常用到的，而如何解决缓存和数据库的一致性也是一个挺让人头疼的问题。
面试题：数据库和缓存如何保证一致性？
秉持长期主义，保持长期生命力和竞争力
02-28 530
mysql
如何保证缓存与数据库的数据一致性
weixin_44390164的博客
08-30 5127
1. 四种可能得方案 先更新数据库，再更新缓存 先更新缓存，再更新数据库 先删除缓存，再更新数据库 先更新数据库，后删除缓存 1.1 第一种的问题 并发更新数据库场景下，会将脏数据刷新到缓存，不使用 1.2 第二种的问题 如果先更新缓存成功，但是数据库更新失败，会造成数据不一致，不使用 2. 先删除缓存，后更新数据库 2.1 可能出现的问题 请求A进行写操作，删除缓存 请求B查询发现缓存不存在 请求B去数据库查询得到旧值 请求B将旧值写入缓存 请求A将新值写入数据库 如果没有给缓存设
怎么保持数据库和缓存的一致性‘’
03-28
<think>好的，用户现在问的是如何保持数据库和缓存的一致性。之前他们问过Spring Boot的启动过程，现在转向数据库和缓存一致性，可能是在开发后端应用时遇到的实际问题。需要先理解他们的使用场景，可能是在高并发或者需要快速读写的系统中使用缓存，比如Redis，来提升性能，但随之而来的数据一致性问题需要解决。 用户可能是开发人员，可能对缓存策略有一定了解，但想深入理解如何确保一致性。需要分析常见的缓存更新策略，比如Cache-Aside、Read/Write Through、Write Behind等，以及它们的优缺点。同时要考虑异常情况，比如更新数据库后更新缓存失败，或者并发写导致的数据不一致。 需要分步骤讲解，可能用户需要具体的解决方案，比如延迟双删、使用消息队列确保最终一致性，或者通过分布式锁来避免并发问题。还要考虑实际应用中的权衡，比如一致性和性能之间的平衡，是否需要强一致性还是最终一致性即可。 用户可能没有提到具体场景，但需要覆盖常见的情况，比如先更新数据库还是先更新缓存，如何失效缓存，处理缓存穿透、雪崩等问题。需要结构清晰，给出多种方案，并说明适用场景，帮助用户根据实际情况选择合适的方法。 最后，要确保语言通俗易懂，避免过于技术化的术语，但也要准确。可能需要用示例或流程图来辅助说明，比如双写策略的步骤，或者使用版本号解决并发问题的方法。总结时强调没有银弹，需要根据业务需求选择合适的策略，并做好监控和异常处理。</think>--- ### 数据库与缓存一致性保障方案 数据库与缓存的一致性问题主要出现在 **缓存更新策略** 和 **并发操作** 场景中，需结合业务需求选择策略。以下是核心解决思路： --- #### 一、**常见问题场景** 1. **缓存失效后，数据库更新导致缓存与数据库不一致** 2. **并发读写时，缓存与数据库更新顺序冲突** 3. **缓存更新失败，残留旧数据** --- #### 二、**核心解决方案** ##### 1. **缓存更新策略** - **(1) Cache-Aside（旁路缓存）** - **读操作**：先读缓存，未命中则读数据库并回填缓存。 - **写操作**：直接更新数据库，然后 **删除缓存**（非更新缓存）。 - **优点**：简单，减少脏数据风险。 - **风险**： - **并发读写不一致**：A 写数据库后删除缓存前，B 读旧数据回填缓存。 - **解决方案**：延迟双删（先删缓存→更新数据库→延迟再删缓存）。 ```java // 伪代码示例：延迟双删 public void updateData(Data data) { cache.delete(data.id); // 先删除缓存 db.update(data); // 更新数据库 Thread.sleep(500); // 延迟（根据业务设置时间） cache.delete(data.id); // 再次删除可能残留的旧缓存 } ``` - **(2) Write-Through（直写）** - **写操作**：先更新缓存，再同步更新数据库。 - **优点**：保证缓存与数据库强一致。 - **缺点**：写性能较低，需依赖缓存和数据库的原子性。 - **(3) Write-Behind（异步写）** - **写操作**：先更新缓存，异步批量更新数据库。 - **优点**：高吞吐，适合写多读少场景。 - **缺点**：存在数据丢失风险（缓存宕机）。 --- ##### 2. **并发场景优化** - **分布式锁** - 对同一数据的读写操作加锁，避免并发冲突。 - **示例**：使用 Redis 的 `SETNX` 或 RedLock 实现互斥锁。 - **版本号/时间戳** - 数据更新时携带版本号，缓存中只接受更高版本的数据。 --- ##### 3. **最终一致性保障** - **消息队列（MQ）异步补偿** - 数据库更新后，发送 MQ 消息触发缓存删除。 - **容错机制**：重试 + 死信队列监控。 - **监听数据库 Binlog** - 通过 Canal 或 Debezium 监听数据库变更日志，触发缓存更新/删除。 - **优点**：解耦业务代码，适用于复杂系统。 --- #### 三、**方案选择与权衡** | **策略** | **一致性强度** | **性能** | **复杂度** | **适用场景** | |------------------|----------------|----------|------------|---------------------------| | Cache-Aside | 最终一致 | 高 | 低 | 读多写少 | | Write-Through | 强一致 | 中 | 中 | 写操作较少，强一致性要求 | | Write-Behind | 弱一致 | 极高 | 高 | 写密集，允许短暂不一致 | | Binlog 监听 | 最终一致 | 中 | 高 | 高可用分布式系统 | --- #### 四、**关键注意事项** 1. **避免同时更新缓存和数据库**：优先保证数据库正确性，缓存可重建。 2. **设置缓存过期时间**：即使出现不一致，也能通过过期自动恢复。 3. **降级与监控**：缓存故障时，需有降级策略（如直接读库）。 --- ### 总结 $$ \text{目标} = \text{业务容忍度} \cap \text{性能} \cap \text{复杂度} $$ - **弱一致性场景**：优先选择 Cache-Aside + 延迟双删。 - **强一致性场景**：需引入分布式锁或同步写策略。 - **最终一致性场景**：结合 Binlog 监听或 MQ 异步补偿。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值