Redis和DB数据不一致解决方案

最新推荐文章于 2025-09-22 01:49:45 发布
原创 最新推荐文章于 2025-09-22 01:49:45 发布 · 4.4k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#JAVA #架构

当并发访问时，Redis和数据库数据不一致成为常见问题。本文探讨两种优化方案：1) 双删加超时策略，在写库前后删除缓存并设置超时时间；2) 通过读取MySQL binlog异步淘汰缓存，降低业务代码侵入性，减少不一致时间。

大多情况下，我们使用缓存都是这样的策略：先读缓存，读取不到就读数据库然后同步到缓存中。

问题出现场景

问题就是在并发访问中，不论是先写库，再删除缓存；还是先删缓存，再写库，都有可能出现数据不一致的情况

1、在并发中是无法保证读写的先后顺序的，如果删掉了缓存还没来得及写库，另一个线程就过来读取发现缓存为空就去数据库读取并写入缓存，此时缓存中为脏数据。
2、如果先写了库，再删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。
3、如果是redis集群，或者主从模式，写主读从，由于redis复制存在一定的时间延迟，也有可能导致数据不一致。

优化解决方案

双删 + 超时

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。这样最差的情况是在超时时间内存在不一致，当然这种情况极其少见，可能的原因就是服务宕机。此种情况可以满足绝大多数需求。
当然这种策略要考虑redis和数据库主从同步的耗时，所以在第二次删除前最好休眠一定时间，比如500毫秒，这样毫无疑问又增加了写请求的耗时

通过读取binlog的方式，异步淘汰缓存

这里写图片描述

好处：业务代码侵入性低，将缓存与数据库不一致的时间尽可能缩小。

binlog介绍：Mysql的binlog日志作用是用来记录mysql内部增删改查等对mysql数据库有更新的内容的记录（对数据库的改动），对数据库的查询select或

最低0.47元/天 解锁文章
如何关闭谷歌浏览器的弹出窗口拦截功能
nntxthml的博客
01-06 2196
关闭谷歌浏览器的弹出窗口拦截功能是一个简单但有用的操作，可以让你更好地访问某些网站并获取重要的信息。通过按照本文提供的步骤进行操作，你可以轻松地关闭谷歌浏览器的弹出窗口拦截功能，并根据需要进行自定义设置。同时，也需要注意安全性考虑，确保你访问的网站是可信的。希望本文能够帮助你更好地使用谷歌浏览器，并享受更流畅的网页浏览体验。
Redis缓存：淘汰机制、缓存雪崩、数据不一致，都一步说到位
QAQFyl的博客
01-19 409
在实际的工作项目中， 缓存成为高并发、高性能架构的关键组件 ，那么Redis为什么可以作为缓存使用呢？首先可以作为缓存的两个主要特征： 在分层系统中处于内存/CPU具有访问性能良好， 缓存数据饱和，有良好的数据淘汰机制 由于Redis 天然就具有这两个特征，Redis基于内存操作的，且其具有完善的数据淘汰机制，十分适合作为缓存组件。 其中，基于内存操作，容量可以为32-96GB，且操作时间平均为100ns，操作效率高。而且数据淘汰机制众多，在Redis 4.0 后就有8种了促使Redis作为缓存可以适
谷歌浏览器如何设置不阻止弹窗弹出
热门推荐
Jack魏
02-25 1万+
谷歌浏览器如何设置不阻止弹窗弹出1.进入设置![在这里插入图片描述](https://img-blog.csdnimg.cn/20190225084657460.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dlaUhhbzAyNDA=,...
谷歌浏览器关闭弹出窗口阻止
不定期更新笔记，不成条理不成方圆。
11-19 6568
有时候有些网站会遇到点击按钮，但没任何反应的情况，可能是需要弹出一个新窗口，在新窗口中进行操作，但浏览器弹出窗口阻止了，所以点了按钮没反应。
redis和数据库的关系
最新发布
eettttttt的博客
09-22 843
数据库是仓库：容量大、东西存放整齐安全（持久化），但存取速度慢。Redis是柜台/展示架：容量小，但摆放着最热门、最急需的商品（数据），存取速度极快。顾客（应用程序）来买东西时，会先到柜台看看有没有（读缓存），如果有就直接拿走。如果没有，才去仓库里取，同时拿一份放到柜台上以备下一个顾客需要。当仓库新到货或货物有变动时（写数据），会及时通知柜台更新展示品（缓存失效）。这种架构结合了内存的速度和硬盘的持久性，是现代应用设计的标准做法。
redis和mysql数据不一致_高并发下为什么 redis 和数据库不一致？怎么解决？
weixin_39832448的博客
02-11 554
现在的web架构一般都用redis作为缓存层来减轻数据库的压力，数据在此架构下的读取问题，一般都是先判断redis缓存是否有数据，如果有，直接返回，否则读取数据库的数据，写入redis，返回数据，这是大致的读取流程。那么为什么会出现redis和数据库不一致的问题呢?举个例子，如果你的缓存里现在缓存了用户的年龄的数据，每次用户访问的时候，如果缓存里有这个数据，直接返回，那么如果用户更新了自己的年龄，...
redis缓存+数据库双写不一致问题分析与解决方案
u012868901的博客
11-19 5976
在高并发场景下，肯定会发生这个问题，这里简单谈谈解决思路 1.常规简单的解决方案   先删除缓存，在更新数据库,如果删除缓存成功，修改数据库失败了，那么数据库中依然是旧数据，如果去读取数据的时候，发现缓存没有，则去读数据库，数据库会把旧数据加载到缓存里，这样缓存和数据库则保持了一致。 2.如果在高并发的情况下会发生了如下更复杂的操作 比如有数据发生了变更，先删除了缓存，然后准备要去修改数据...
使用云服务器搭建Redis集群主从数据不同步的坑
qq_42799562的博客
01-18 2239
在我使用本地六台集群搭建集群的时候，一路顺风顺水，无论是速度还是master-slave之间都毫无问题。但是在使用云服务器的时候，问题就来了，master-slave之间数据无法同步啊。愁死人了，害。查了一大堆，好多博主都是在本地局域网使用虚拟机搭建的集群，使用云的少之又少，毕竟需要六台云啊。我也是恰巧拥有试用资格才有幸申请了六台云。终于，在几经痛苦的挣扎后，找到啦症结所在。即：使用云搭建集群后，在每个node.conf配置文件中，默认都有一个本机内网IP，作为节点标识，所以这时候把6个配置文件的内网IP.
Redis与DB数据一致性 解决方案（图解+秒懂+史上最全）
架构师尼恩
09-28 7086
文章很长，而且持续更新，建议收藏起来，慢慢读！ Java 高并发 发烧友社群：疯狂创客圈（总入口） 奉上以下珍贵的学习资源： 免费赠送 经典图书 ： 极致经典 + 社群大片好评 《 Java 高并发 三部曲 》 面试必备 + 大厂必备 + 涨薪必备 免费赠送 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 大厂必备 +涨薪必备 （加尼恩领取） 免费赠送 经典图书 ： 《SpringCloud、Nginx高并发核心编程》 面试必备 + 大
Redis 与 DB 的数据一致 / 双写一致性问题
Java Punk
08-31 2498
缓存提升性能就会有数据更新的延迟，就无法使数据库和缓存数据保持强一致，所以上树的各种优化方案，都是以保证弱一致性，最终一致性为前提的。
Redis解决数据一致性方案
java那些事儿
09-15 2944
先更新数据库，再删除缓存；先删除缓存，再更新数据库；目标就是通过重试机制来解决后删除缓存失败的情况，直到删除成功。无论是重试还是异步删除，都是最终一致性的思想。我们在使用Redis缓存时，优先选择先更新数据库，再删除缓存并且同步设置key的过期时间。在一些对数据一致性要求比较强的业务中，适当的借助MQ或者Canel来做重试。
如何解决缓存（redis）和数据库（MySQL）数据不一致的问题？
jkzyx123的博客
09-08 2070
如何解决缓存（redis）和数据库（MySQL）数据不一致的问题？
13 Redis-- 数据一致性模型、MySQL 和 Redis 的数据一致性
m0_46671240的博客
06-27 704
13 Redis-- MySQL 和 Redis 的数据一致性
【数据一致性】redis缓存与DB保持一致_Redis02
Lei锋帽的博客
08-15 521
数据一致性
企业级Redis数据库高可用解决方案
神一样的存在
06-20 3407
企业级Redis数据库高可用解决方案   背景： 最近比较火的Redis非关系数据，可基于内存亦可持久化的日志型、Key-Value数据库。由于服务器的内存管理能力有限，使用过大内存的Redis又会使得服务器的性能急剧下降，一旦服务器发生故障将会影响更大范围业务，集群功能还不适合生产环境的使用集群中超过半数的节点检测失效导致整个集群异常。 在实际特定的应用场景通过Redis的特性提高效率，
Redis主从数据不一致及读取过期数据问题的解决方案
ggh0314的博客
06-10 2599
主从数据不一致问题 因为主从库间的命令复制是异步进行的，所以有可能客户端从从库中读取到的值和主库中的最新值并不一致。 具体来说，在主从库命令传播阶段，主库收到新的写命令后，会发送给从库。但是，主库并不会等到从库实际执行完命令后，再把结果返回给客户端，而是主库自己在本地执行完命令后，就会向客户端返回结果了。如果从库还没有执行主库同步过来的命令，主从库间的数据就不一致了。 从库滞后执行同步命令主要有两种情况： 一方面，主从库间的网络可能会有传输延迟，所以从库不能及时地收到主库发送的命令，从库上执行同步命令的
如何保证 redis 和 db 中数据一致
Cike___的博客
08-21 945
一般来说，只要我们用缓存，就可能会涉及到缓存与数据库双存储双写，只要是双写，就一定会有数据一致性的问题，那么如何我们如何解决一致性问题呢？
关于redis与db不一致问题的思考总结
l8947943的博客
05-22 1544
腾讯之前一直深挖这一部分，让我有幸深入思考了一部分，今天记起来这儿，做一点总结，感谢腾讯的压力让我深入理解 关于不一致的问题： 一般情况下，我们都是先同步数据库，然后再删除redis，当删除redis时出问题了，这样就会出现不一致问题 于是，我们可以先删除缓存，再同步到数据库。这样，保证下次访问时候，先访问redis，没有数据，则请求DB，保证了Redis与DB的一致。当出错了，至少不会出现超卖现象，但是用户体验感很差 这样做会出现问题，那就是下一次访问，DB还没更新完成，Redis请求到没有更新的DB.
spring boot集成redis，以及配置database不生效问题
loney_wolf的博客
01-18 4151
备注：记录一次spring-boot + redis 配置redis.database后，仍然使用db0默认库的情况。
Java面试 redis和数据库的不一致解决
05-11
<think>好的，用户现在的问题是解决Redis与数据库在Java面试场景中的数据不一致问题。我需要结合之前的引用内容来组织一个清晰的回答。首先，用户提到的是面试场景，所以回答需要结构分明，重点突出，便于记忆和理解。 首先，我应该回顾引用中的相关内容。引用1提到了保证数据一致性的方法，包括事务、定期同步、过期时间和持久化方式。引用5提到了双删延时策略，以及主从同步的问题。引用4讨论了删除缓存失败时的重试机制，比如同步重试、异步重试、MQ消息等。引用3中的Redis面试问题也提到了缓存击穿、穿透、雪崩以及双写问题，其中方法三和四提到了主动更新和canal组件同步。 接下来，我需要将这些信息整合成一个面试导向的回答。通常，面试中这类问题需要分点回答，每个点有具体的策略和原理，可能还要提到优缺点。用户可能需要知道常见的解决方案，比如缓存双删、延迟队列、异步通知、读写锁、版本号控制等。 然后，我需要考虑如何结构化这些内容。比如，可以分成几种不同的策略，每种策略详细说明，并引用相关引用中的内容。比如双删策略在引用5中提到过，需要详细解释步骤和可能的改进，比如延时双删。异步重试可以用引用4中的MQ消息中间件。canal组件在引用3的方法四中提到，可以展开说明。 另外，用户可能需要知道这些方案的应用场景和优缺点，以便在面试中能够对比分析。例如，延时双删可能影响性能，但实现简单；canal组件解耦但增加系统复杂度。需要提到这些点。 还要注意回答的格式，用户要求使用中文，行内公式用$...$，独立公式单独成段。不过这个问题可能涉及较少的数学公式，但如果有涉及，比如时间计算，可能需要使用。例如，延时时间设置为主从同步时间加几百ms，可以写成$T_{delay} = T_{replication} + 500ms$，不过可能不需要，视情况而定。 最后，生成相关问题，需要围绕数据一致性，可能的面试问题，比如缓存击穿、雪崩，或者更深入的双写问题、分布式锁等，参考引用中的内容，比如引用3中的问题列表。 总结步骤： 1. 分点列出解决方案，每个方案有步骤、原理、引用来源。 2. 提到优缺点或适用场景。 3. 结构化回答，便于面试中清晰表达。 4. 生成相关问题，覆盖其他可能的面试考点。</think>关于Java面试中Redis与数据库数据一致性问题的解决方案，我为您整理以下7种典型处理策略及实现要点： ### 一、双删延时策略（基础方案） 1. 先删除Redis缓存 2. 执行数据库更新操作 3. 延时后再次删除缓存（延时时间=主从同步时间+500ms）[^5] ```java public void updateData(Data newData) { redis.delete("data_key"); // 第一次删除 db.update(newData); // 数据库更新 Thread.sleep(1000); // 延时等待主从同步 redis.delete("data_key"); // 第二次删除 } ``` ### 二、异步重试机制（可靠性保障） 通过消息队列实现异步删除保障： ```mermaid graph LR A[业务服务] -->|1.删除缓存| B[数据库] A -->|2.发送消息| C[消息队列] D[消费者] -->|3.消费消息| C D -->|4.二次删除| E[Redis] ``` ### 三、读写锁控制（强一致性） ```java ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); // 写操作 lock.writeLock().lock(); try { redis.delete(key); db.update(data); } finally { lock.writeLock().unlock(); } // 读操作 lock.readLock().lock(); try { data = redis.get(key); if(data == null) { data = db.query(key); redis.set(key, data); } } finally { lock.readLock().unlock(); } ``` ### 四、版本号控制（最终一致性） $$ V_{new} = V_{current} + 1 $$ ```java // 数据对象增加版本号字段 class DataWithVersion { Object data; long version; } // 更新时校验版本号 if(redisVersion <= dbVersion) { redis.update(data, dbVersion); } ``` ### 五、Canal监听binlog（解耦方案） 通过阿里Canal实现数据库变更监听： ```mermaid sequenceDiagram participant MySQL participant Canal participant Redis MySQL->>Canal: 推送binlog Canal->>Redis: 解析后同步数据 ``` ### 六、设置合理过期时间（兜底策略） ```java // 设置随机过期时间避免雪崩 int expireTime = 3600 + new Random().nextInt(600); redis.setex(key, expireTime, value); ``` ### 七、多级缓存策略（高并发优化） ```java // 伪代码示例 public Data getData(String key) { Data data = localCache.get(key); // 一级缓存 if(data == null) { data = redis.get(key); // 二级缓存 if(data == null) { data = db.query(key); // 数据库 redis.setex(key, data, 60); } localCache.put(key, data, 10); // 短期本地缓存 } return data; } ``` **选择建议**： - 面试重点掌握双删策略（成功率85%+）和Canal方案 - 高并发场景优先考虑多级缓存+版本号控制 - 金融交易类系统建议采用读写锁方案
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值