面试高频：如何实现redis双写一致性

最新推荐文章于 2024-11-07 12:04:46 发布
最新推荐文章于 2024-11-07 12:04:46 发布
阅读量258 收藏
点赞数 3
文章标签： 面试 redis 职场和发展
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_29484773/article/details/137435823
版权

1.延时双删（简单方案，但第二次删除是延时的但可能存在网络抖动导致脏数据并不是强一致性的）

2.分布式锁（强一致性，但性能略低）

3.使用MQ（最终一致性）侵入性大，需写推送mq逻辑

4.基于canal的异步通知（最终一致性，侵入低，但需搭建canal环境）

面试版回答：

qq_29484773
关注
126、高频Redis面试题:如何保证Redis和数据库数据一致性
weixin_43860634的博客
08-11 579
高频Redis面试题:如何保证Redis和数据库数据一致性
Redis （高频）面试题
zhongjikongju的博客
08-19 772
基本特点：hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。1、使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，1、不带allkeys字样的淘汰策略是随机从Redis中选择指定的数量的key然后按照对应的淘汰策略进行删除，带allkeys是对所有的key按照对应的淘汰策略。
Redis面经——Redis的双写一致性，一篇文章带你彻底搞懂什么是Redis的双写一致，如何推演实现的？以及成熟的解决方案！黄金文档！
我热爱学习，也乐于分享。无论是科技前沿的洞见，还是生活中的小技巧，我都会在这里与你分享。我相信，知识就是力量，而分享则能让这份力量得到更好的传递。
01-25 3707
（2）接下来线程2在线程1未同步到缓存前，先更新数据库，并且删除了缓存（此时缓存中key已经过期，删不删除都是一样的），线程2成功将数据更新成了20，但是线程1开始执行，将一开始读取到的10写入到了缓存中，又总成了数据的不一致！此时线程1查询缓存，发现缓存未命中，直接去查询数据库，此时查询的数据是正确的，然后紧接着将数据库更新后的数据写到缓存中了。（2）此时，线程1开始执行，线程1完成了数据库的数据更新，数据库数据变成了20，但是此时的缓存中数据还是10，这就造成了脏数据的情况！保证写操作强一致性的方法！
高频Redis面试题:如何保证Redis和数据库数据一致性
Mr.Ding的博客
07-30 258
订阅mysql的binlong，在订阅者中，如果发现更新数据请求，则删除响应的缓存，比如使用canal中间件;缺点：高并发场景下，如果多个线程同时执行更新数据库再写缓存操作可能会出现数据库是新值，而缓存中是旧值。缺点：高并发场景下，如果多个线程同时执行更新数据库再写缓存操作可能会出现数据库是新值，而缓存中是旧值。在高可用的系统系统里面，我们追求数据最终一致性的话，我们可以考虑先更新数据库，再去删除缓存。问题：如果数据库中的某条数据放入缓存后，有马上被更新了，那我们应该如何更新缓存？
Redis高频面试基本问题整理
热门推荐
张彦峰的博客
04-07 170万+
对Redis一些重点内容进行整理总结用于查缺补漏
面试高频：redis分布式锁如何实现
qq_29484773的博客
04-06 221
CAP原理（CAP theorem）是分布式计算领域的一个重要理论，它指出在一个分布式系统中，无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求，最多只能满足其中的两项。4.无法解决分布式锁的主从切换导致的一致性问题，redis有红锁方案但不实用，redis是AP架构。3.redis的分布式锁不能重入但redisson的分布式锁是可重入的。需要强一致性可以使用zookeeper实现的分布式锁(CP)
【redis面试题】双写一致性
weixin_54533016的博客
11-02 124
跟着B站的黑马程序员学习面试题，目前是redis的第四个内容——双写一致性redis——双写一致性正常现象脏数据现象。
Redis 面试题 + Redis 高频面试题集锦
02-10
- **乐观锁**：Redis采用乐观锁策略，通过版本号或CAS(Check and Set)操作确保数据一致性，适用于冲突较少的情况。 **MyISAM与InnoDB的区别** - **MyISAM**：不支持事务，只缓存索引，适合读多写少的场景。 - **...
Redis高频面试宝典
05-26
原子性：所有操作都是原子性的，保证数据的一致性。 Redis与其他数据库的区别 Redis是内存数据库，读写速度更快；其他数据库如MySQL是磁盘数据库，读写速度相对较慢。 Redis支持多种数据结构，而其他数据库主要支持...
Redis面试题(含答案)大整合+Redis高频面试题
04-11
- Cluster集群：通过一致性哈希解决大规模数据存储和高可用性问题。 - 缓存策略：理解TTL（Time To Live），避免缓存雪崩和击穿问题。 6. **Redis持久化** - RDB持久化：定时保存数据快照，恢复时快速加载。 - ...
面试笔记——Redis（双写一致、持久化）
Z__XY_的博客
03-19 871
当有数据被写入数据库，会把数据库发生的变化记录到BINLOG（二进制日志）文件中（如DDL【数据定义语言】语句和DML【数据操纵语言】语句），但不包括数据查询语句（如，SELECT、SHOW）。因为是记录命令，AOF文件会比RDB文件大的多。：由于数据库一般采取的是主从模式，当主节点的数据发生改变时，需要一定的时间等待其他的从结点完成数据同步，因此需要延时删除缓存。在执行更新操作之前，先进行一次删除缓存操作（删除旧数据），等数据库修改之后，再进行一次删除缓存操作（确保删除旧数据），降低脏数据的出现。
Redis面试题分享十：Redis 与 MySQL如何保证双写一致性？
之乎者也·的博客
11-09 411
在这样一个架构中，会出现一个问题，就是一份数据，同时保存在数据库和Redis 里面，当数据发生变化的时候，需要同时更新 Redis 和 Mysql，由于更新是有先后顺序的，并且它不像 Mysql 中的多表事务操作，可以满足 ACID 特性。所以就会出现数据一致性问题。Redis与MySQL双写一致性是指。
如何保证Redis双写一致性？
m0_57408211的博客
04-29 1384
1.场景一：并发读写情况下产生的短暂不一致场景，业务场景要能接受。并发读写情况下，缓存正好失效且读操作耗时大于写操作而产生的数据不一致。可以通过延时删除，或者给redis设置较短的存活时间。
【面试篇】- Redis与MySQL双写一致性如何保证呢
Mind_programmonkey的博客
06-25 431
Redis与MySQL双写一致性如何保证呢 1 什么是一致性？ 一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。 强一致性： 这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验性好，但实现起来往往对系统的性能影响大； 弱一致性： 这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别(比如秒级别)后，数据能够达到一致状态； 最终一致性： 最终一致性是弱一致性的一个特例
[优雅的面试]MySQL与Redis双写一致性方案
nhb687096的博客
05-01 1077
还有问题呀，就是最终解决方案三可能 出现的极低概率的数据不一致的方案是采用方案二的延时双删策略，可是在方案二中也说了，如果出现缓存删除失败的情况咋办？那不是还会出现数据不一致的问题吗？这个问题到底如何解决呢？这里提供一个重试机制，删除失败就重试一次呗，这里提供一种重试的方案。①更新数据库②由于各种原因缓存删除失败③将删除失败的缓存放入消息队列中④业务代码从消息队列中获取需要删除的key⑤继续尝试删除操作，直到成功。
面试官： Redis 与 MySQL 双写一致性如何保证？
weixin_45476233的博客
01-17 214
谈谈一致性 一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以.
微服务架构面试内容整理-Sleuth
不务正业的猿
11-07 328
当请求在服务之间传播时，Sleuth 会将 Trace ID 和 Span ID 作为请求头的一部分传递，从而实现对整个请求路径的追踪。在微服务架构中，服务之间的请求链路往往很复杂，Sleuth 可以帮助开发者追踪请求在多个服务中的流转情况。当请求跨多个微服务传播时，每个服务的日志中都会包含相同的 Trace ID，帮助开发者跟踪整个请求的流转。Sleuth 能够对请求进行跟踪，为每个请求生成唯一的追踪 ID（Trace ID），并在服务之间传播。
【IC每日一题：IC验证面试常问-3】
最新发布
li_kin的博客
11-07 561
IC验证常问问题
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

qq_29484773

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值