首先,分为两种场景:

一. 针对读场景:

(1) A请求查询数据,如果命中缓存,那么直接取缓存数据返回即可。如果请求中不存在,数据库中存在,那么直接取数据库数据返回,然后将数据同步到Redis中。不会存在数据不一致的情况。
(2) 在高并发的情况下,A请求和B请求一起访问某条数据,如果缓存中数据存在,直接返回即可,如果不存在,直接取数据库数据返回即可。无论A请求B请求谁先谁后,本质上没有对数据进行修改,数据本身没变,只是从缓存中取还是从数据库中取的问题,因此不会存在数据不一致的情况。

因此,单独的读场景是不会造成Redis与数据库缓存不一致的情况,因此我们不用关心这种情况。

二. 针对写场景:

(1) 如果该数据在缓存中不存在,那么直接修改数据库中的数据即可,不会存在数据不一致的情况。

(2) 如果该数据在缓存中和数据库中都存在,那么就需要既修改缓存中的数据又修改数据库中的数据,而且在高并发的场景下,还存在修后关系,这就会导致数据不一致的问题。

针对(2)的情况有两个疑问:

(1)是删除缓存数据,等待下次查询该数据时,缓存中没有直接去数据库中查询,同时添加到缓存中,还是更新缓存呢?

(2)更新缓存中的数据,是先更新缓存还是先更新数据库呢?

关于疑问(1)有两个方案

方案1:删除缓存

优点:实现简单,不需要再更新数据库操作时在进行更新数据逻辑,直接删除对应缓存的key即可。
缺点:由于缓存被删除,下次查询无法命中缓存,需要在查询后将数据写入缓存,增加查询逻辑。同时在高并发的情况下,同一时间大量请求访问该条数据,第一条查询请求还未完成写入缓存操作时,这种情况,大量查询请求都会打到数据库,加大数据库压力。

方案2:更新缓存

优点:缓存命中率高,只要缓存进行了更新,后续的读请求就不会出现缓存未命中的情况。
缺点:在某些业务场景下,更新数据的成本较大,并不是单纯将数据的数据查询出来丢到缓存中即可,而是需要连接很多张表组装对应数据存入缓存中,并且可能存在更新后,该数据并不会被使用到的情况。

综合分析

在一般的业务中一般都采用缓存淘汰这种方案,而非缓存更新。因为:

  • 大多数情况下,redis缓存中的数据并不是完全复制数据库中的数据,而是将db中多张表的数据进行了重新计算,筛选后更新到redis。如果在db某一张表的数据发生了变化的情况下,需要同步重新计算redis中值的话,更新成本过高。
  • 缓存更新后的新值,无法保证一定会有读请求命中,如果一直没有请求命中该部分冷数据,其实是产生了一定的资源浪费(计算成本+存储成本)。
  • 相较于删除缓存方案来说,仅有一次读请求cache miss的结果来说,淘汰缓存策略的缺点完全可以容忍。

比如,A表中的字段,1分钟更改了100次,如果采用更新缓存策略,则需要计算100次,哪怕1分钟内只有1次读请求;如果采用淘汰缓存策略,如果1分钟内只有1次请求,则只需要计算1次即可,开销大幅度降低。

关于疑问(2)有两个方案

方案1:先更新缓存,后更新数据库

正常情况

(1)A请求进行写操作,先淘汰缓存,再更新数据库
(2)B请求进行读操作,由于A请求已将缓存淘汰,B请求没有在redis中发现所需数据,因此从数据库中读取数据,并更新缓存到redis中

异常情况1

(1)A请求进行写操作,先淘汰缓存
(2)B请求进行读操作,由于A请求已将缓存淘汰,B请求没有在redis中发现所需数据,因此从数据库中读取数据,并更新缓存到redis中。注意,此时redis中被更新的依然是老数据,A请求的数据库更新操作尚未完成
(3)A请求进行数据库更新操作。此时,数据库中是新数据,redis缓存中是老数据,产生了数据不一致的问题。且该不一致会一直持续到缓存自然失效或者下次的更新操作

对于该种异常情况,提供两种解决思路:

1.异步更新缓存

(1)A请求进行写操作,先淘汰缓存
(2)B请求进行读操作,由于A请求已将缓存淘汰,B请求没有在redis中发现所需数据,因此从数据库中读取数据。注意,此时不向redis写入新的缓存策略
(3)A请求通过订阅数据库binlog,对redis缓存数据进行异步更新

该方案虽然解决了数据不一致的问题,但是在数据库更新操作完成前,所有的读请求都会直接打到数据库上,具有比较大的风险。

2.延时双删

(1)A请求进行写操作,先淘汰缓存
(2)B请求进行读操作,由于A请求已将缓存淘汰,B请求没有在redis中发现所需数据,因此从数据库中读取数据,并更新缓存到redis中。注意,此时redis中被更新的依然是老数据,A请求的数据库更新操作尚未完成。假设该步骤耗时N秒
(3)A请求进行数据库更新操作。
(4)由于此时redis中写入了老数据,因此A请求在休眠M秒后(M略大于N),再次对redis进行淘汰缓存操作

该方案虽然解决了数据不一致的问题,但是由于请求A在更新完数据库之后,需要休眠M秒再次淘汰缓存,一定程度上影响了数据更新操作的吞吐量。可以尝试将等待M秒更新redis的操作放到另一个单独的线程(比如消息队列 + 重试机制)。可以有效缓解吞吐量降低的问题。

异常情况2

(1)A请求进行读操作,此时redis缓存中没有数据,因此直接从数据库中读取数据
(2)B请求进行写操作,先淘汰缓存,再更新数据库
(3)A请求进行将从数据库中读到的老数据,更新到redis。此时产生数据不一致问题。

该种异常情况发生概率极低,一般读操作比写操作要快。如有担心,可以采用上述的延时删除策略

方案2: 先更新数据库,后更新缓存

正常情况

(1)A请求进行写操作,先更新数据库,再淘汰缓存
(2)B请求进行读操作,由于A请求已将缓存淘汰,B请求没有在redis中发现所需数据,因此从数据库中读取数据,并更新缓存到redis中

异常情况1

(1)A请求进行写操作,先更新数据库
(2)B请求进行读操作,由于A请求尚未淘汰缓存,B请求在redis中发现所需数据,因此直接返回老数据,产生了数据不一致的问题
(3)A请求淘汰缓存。
(4)C请求进行读操作,发现redis中没有数据,因此从数据库中读取新数据,并更新至缓存。数据不一致的问题解决。

该场景下,数据最终一致,只是在高并发下产生了一小段时间的数据不一致。

异常情况2

(1)A请求进行读操作,此时redis缓存中没有数据,因此直接从数据库中读取数据
(2)B请求进行写操作,更新数据库,并将redis中缓存进行了淘汰(虽然此时redis中并没有任何的缓存)
(3)A请求将从数据库中读到的老数据,更新到redis。此时产生数据不一致问题。

该种异常情况发生概率极低,一般读操作比写操作要快。如有担心,可以采用上述的延时删除策略。

总结

方案1:先淘汰缓存,后更新数据库的策略,有可能导致长时间的数据不一致问题,可以通过延时双删 or 异步更新缓存策略进行解决。
方案2:先更新数据库,后更新缓存,有可能导致极短时间内的数据不一致,但是数据最终是一致的。

以上就是如何保证Redis与数据库的数据一致性的详细内容,更多关于Redis与数据库 数据一致性的资料请关注萤火虫技术其它相关文章!

点赞(82) 打赏

评论列表 共有 0 条评论

暂无评论

微信小程序

微信扫一扫体验

立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部