Redis双写一致性

所有的情况都是再并发情况下存在温蒂

一、先更新数据库,再更新缓存场景-不推荐

当有两个线程A、B,同时对一条数据进行操作,一开始数据库和redis的数据都为1,当线程A去修改数据库,将1改为2,然后线程A在修改缓存中的数据,可能因为网络原因出现延迟,这个时候线程B,将数据修改成了3、然后将数据库中的1也改成了3,然后线程A恢复正常,将redis中的缓存改成了2,此时就出现了缓存数据和数据库数据不一致情况。

Redis双写一致性_第1张图片

二、先更新缓存,再更新数据库场景-不推荐

当有两个线程A、B,同时对一条数据进行操作,线程A先将redis中的数据修改为了2,然后CPU切换到了线程B,将redis中的数据修改为了3,然后将数据库中的信息也修改了3,然后线程A获得CPU执行,将数据库中的信息改为了2,此时出现缓存和数据库数据不一致情况。不推荐

Redis双写一致性_第2张图片

三、先删除缓存,再更新数据库的场景-不推荐

当有两个线程A、B,同时对一条数据进行操作,当线程A进行修改缓存操作时,先删除掉缓存中的数据,然后去修改数据库,因为网络问题出现延迟,这时线程B查新redis没有值,因此去数据库中查询数据为1,然后将数据1更新到缓存中,线程A网络恢复,又将数据库数据修改为了2,此时出现数据不一致。不推荐,当然可以给键设置过期时间,自然过期后悔再查数据库

Redis双写一致性_第3张图片

四、先更新数据库,在删除缓存场景-可以接受

一改一查场景

当有两个线程A、B,线程A先去将数据库的值修改为2,然后需要去删除redis中的缓存,当线程B去读取缓存时,线程A已经完成delete操作时,缓存不命中,需要去查询数据库,然后在更新缓存,数据一致性;

如果线程A没有完成delete操作(图中案例),线程B直接命中,返回的数据与数据库中的数据不一致,可能会短暂出现数据不一致情况,但最终都会一致。

Redis双写一致性_第4张图片

存在的问题

当数据过期或者初始化时,会出现数据不一致情况

Redis双写一致性_第5张图片

解决方案

对于不过期的数据我们要在上线的时候做好数据的预热,保证缓存命中。对于存在过期的数据,因为有过期时间,只会在特定的时间段内数据不一致,下次数据过期后,可以恢复,对于实时性要求不高时,可以接受。

两次修改场景

当有两个线程A、B,线程A去修改数据库中的值改为2,然后出现网络波动,线程B将数库中的值修改为了3,然后两个线程都会删除缓存,保证数据一致性。无非是线程A多删了一次。

Redis双写一致性_第6张图片

但是问题来了,按照以下时序操作,可能会存在一个问题,就是最后redis和数据库中的数据不一致

Redis双写一致性_第7张图片

上面的单删策略情况如下:
修改请求的实现中需要修改数据库后,级联删除redis中的数据。
请求一:1.1修改数据库数据      1.2 删除redis数据
请求二:2.1修改数据库数据      2.2 删除redis数据
​
假设现在并发存在一个查询请求
请求三:3.1查询redis中数据   3.2查询数据库数据    3.3 新查到的数据写入redis
(一定要理解带redis的查询请求实现逻辑,先查redis,数据不存在查数据库,
            查到的数据写入redis以便以后的查询不去直接查数据库)
            
此时并发情况下就会存在1.1 ---> 1.2 ---> 3.1 ---> 3.2 ---> 2.1 ---> 2.2 ---> 3.3的情况 
​
此时存在的问题就是:
    此时数据库中的数据保存的是2.1修改后的数据,而redis中保存的数据是3.2中在1.1修改数据后的结果,
    此时出现了redis中数据和数据库数据不一致的情况,在后面的查询过程中就会长时间去先查redis,
    从而出现查询到的数据并不是数据库中的真实数据的严重问题。

那怎么解决,就需要用到经典的演示双删策略

上面的单删策略存在问题的情况如下:
请求一:1.1修改数据库数据      1.2 删除redis数据
请求二:2.1修改数据库数据      2.2 删除redis数据
请求三:3.1查询redis中数据   3.2查询数据库数据    3.3 新查到的数据写入redis
添加延时双删策略后的情况
请求一:1.1修改数据库数据      1.2 删除redis数据    1.3 延时3--5s再去删除redis中数据
请求二:2.1修改数据库数据      2.2 删除redis数据    2.3 延时3--5s再去删除redis中数据
请求三:3.1查询redis中数据     3.2 查询数据库数据    3.3 新查到的数据写入redis
双删策略为什么能解决问题:
因为存在了延时时间,故1.3或2.3 一定是最后执行的一步操作(并发中的延时一定要理解)
延时的根本目的就是为了让程序先把3.3执行完,再去删除redis

如何实现演示双删

比较好的:   项目整合quartz等定时任务框架,去实现延时3--5s再去执行最后一步任务,mq的延迟队列

如果延时双删的第二步删除失败了怎么办,则要进行重试

删除缓存重试机制

因为延时双删可能会存在第二步的删除缓存失败导致的数据不一致问题

可以使用这个方案优化:删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制

Redis双写一致性_第8张图片

删除缓存重试流程

  1. 写请求更新数据库

  2. 缓存因为某些原因,删除失败

  3. 把删除失败的key放到消息队列

  4. 消费消息队列的消息,获取要删除的key

  5. 重试删除缓存操作

读取binlog异步删除缓存

重试删除缓存机制还可以吧,就是会造成好多业务代码入侵。其实,

优化:通过数据库的binlog来异步淘汰key。

Redis双写一致性_第9张图片

以mysql为例吧

  • 可以使用阿里的canal将binlog日志采集发送到MQ队列里面

  • 然后通过ACK机制确认处理这条更新消息,删除缓存,保证数据缓存一致性

你可能感兴趣的:(redis,数据库,缓存)