面试常问:如何保证Redis缓存和数据库的数据一致性

时间:2021-11-24 02:20:44

首先,我们先来看看有哪几种一致性的情况呢?

一、一致性

1、强一致性

如果你的项目对缓存的要求是强一致性的,那么请不要使用缓存。这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大。

2、弱一致性

这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态。

3、最终一致性

最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型。一般情况下,高可用只确保最终一致性,不确保强一致性。

强一致性,读请求和写请求会串行化,串到一个内存队列里去,这样会大大增加系统的处理效率,吞吐量也会大大降低。

二、redis缓存和mysql数据库数据一致性解决

面试常问:如何保证Redis缓存和数据库的数据一致性

这张图,大多数人的很多业务操作都是根据这个图来做缓存的。但是一旦设计到双写或者
数据库和缓存更新等操作,就很容易出现数据一致性的问题。无论是先写数据库,在删除缓存,还是先删除缓存,在写入数据库,都会出现数据一致性的问题。列举两个小例子。

1、 先删除了redis缓存,但是因为其他什么原因还没来得及写入数据库,另外一个线程就来读取,发现缓存为空,则去数据库读取到之前的数据并写入缓存,此时缓存中为脏数据。

2、 如果先写入了数据库,但是在缓存被删除前,写入数据库的线程因为其他原因被中断了,没有删除掉缓存,就也会出现数据不一致的情况。

总的来说,写和读在多数情况下都是并发的,不能绝对保证先后顺序,就会很容易出现缓存和数据库数据不一致的情况,还怎么解决呢?

1、方案一:采用延时双删策略

基本思路: 在写库前后都进行删除缓存操作,并且设置合理的超时时间
基本步骤: 先删除缓存–再写数据库—休眠一段时间—再次删除缓存
注:休眠的时间是根据自己的项目的读数据业务逻辑的耗时来确定的。这样做主要是为了保证在写请求之前确保读请求结束,写请求可以删除读请求造成的缓存脏数据。

该方案的弊端: 集合双删策略+缓存超时策略设置,这样最差的结果就是在超时时间内数据存在不一致,又增加了写请求的耗时。

2、方案二:一步更新缓存(基于订阅binlog的同步机制)

基本思路: mysql binlog增强订阅消费+消息队列+增量数据更新到redis—读redis:热数据基本上都在redis—写mysql:增删改都是操作mysql—更新redis数据:mysql的数据操作binlog,来更新redis

我们再来看看详细的过程

1、redis更新

1)、数据操作主要分为两大块:
一个是全量,将全部数据写去redis;另一个就是增量(update、insert、delete),实时更新。

2)、读取binlog后分析 ,利用消息队列,推送更新各台的redis缓存数据。
这样一旦mysql中产生了新的写入、更新、删除等操作,就可以把binlog相关的消息推送至redis,redis再根据binlog中的记录,对redis进行更新。
其实这种机制,很类似mysql的主从备份机制,因为mysql的主备也是通过binlog来实现的数据一致性。

这里可以结合使用canal(阿里的一款开源框架),通过该框架可以对mysql的binlog进行订阅,而canal正是模仿了mysql的slave数据库的备份请求,使得redis的数据更新达到了相同的效果。

当然,这里的消息推送工具你也可以采用别的第三方:kafka、rabbitmq等来实现推送更新redis。

欢迎小伙伴们留言讨论!

以上就是面试官常问:如何保证redis缓存和数据库的数据一致性的详细内容,更多关于redis缓存和数据库数据一致的资料请关注服务器之家其它相关文章!

原文链接:https://blog.csdn.net/weixin_45827693/article/details/118852234