25 Redis的缓存中的数据和数据库中的不一致问题

25 Redis的缓存中的数据和数据库中的不一致问题

  • 前言
  • 一、缓存和数据库的数据不一致是如何发生的?
  • 二、解决Redis 和数据库数据不一致的方法
  • 总结


前言

Redis 缓存经常会遇到有 4 个方面:

  1. 缓存中的数据和数据库中的不一致;
  2. 缓存雪崩;
  3. 缓存击穿;
  4. 缓存穿透。

只要我们使用 Redis 缓存,就会面对缓存和数据库间的一致性保证问题。如果数据不一致,业务应用从缓存中读取的数据就不是最新数据。比如,把电商商品的库存信息缓存在 Redis 中,如果库存信息不对,那么业务层下单操作就可能出错。

一、缓存和数据库的数据不一致是如何发生的?

数据一致性包含两种情况:

  1. 缓存中有数据,缓存的数据值需要和数据库中的值相同;
  2. 缓存中本身没有数据,数据库中的值必须是最新值。

不符合这两种情况的就属于缓存和数据库的数据不一致问题了。当缓存的读写模式不同时,缓存数据不一致的发生情况不一样,应对方法也会有所不同,根据是否接收写请求,把缓存分成读写缓存只读缓存

读写缓存:

如果要对数据进行增删改,就需要在缓存中进行,根据采取的写回策略,决定是否同步写回到数据库中:

  • 同步直写策略:写缓存时也同步写数据库,缓存和数据库中的数据一致;要想保证缓存和数据库中的数据一致,就要采用同步直写策略。需要同时更新缓存和数据库。所以要在业务应用中使用事务机制,来保证缓存和数据库的更新具有原子性,两者要不一起更新,要不都不更新返回错误信息,进行重试。否则就无法实现同步直写。
  • 异步写回策略:写缓存时不同步写数据库,等到数据从缓存中淘汰时再写回数据库。 如果数据还没有写回数据库,缓存就发生了故障,数据库就没有最新的数据了。 对数据一致性的要求可能不是那么高,比如,缓存的是电商商品的非关键属性或者短视频的创建或修改时间等,可以使用异步写回策略。

只读缓存:

如果有数据新增,会直接写入数据库; 而有数据删改时,把只读缓存中的数据标记为无效。应用后续再访问这些增删改的数据时,因为缓存中没有相应的数据,就会发生缓存缺失。应用再从数据库中把数据读入缓存,这样后续再访问数据时,就能够直接从缓存中读取了。

Tomcat 向 MySQL 中写入和删改数据,如下图:
25 Redis的缓存中的数据和数据库中的不一致问题_第1张图片
Tomcat 上运行的应用,无论是新增(Insert 操作)、修改(Update 操 作)、还是删除(Delete 操作)数据 X,都会直接在数据库中增改删。如果应用执行的是修改或删除操作,还会删除缓存的数据 X。

新增数据和删改数据的数据不一致的情况:

  1. 新增数据 :数据会直接写到数据库中,不用对缓存做任何操作,缓存中本身就没有新增数据,而数据库中是最新值,符合一致性的第 2 种情况,缓存和数据库的数据是一致的。
  2. 删改数据 :应用既要更新数据库,也要在缓存中删除数据。这两个操作如果无法保证原子性,就会出现数据不一致问题了。
    应用先删除缓存,再更新数据库: 如果缓存删除成功,但是数据库更新失败,应用再访问数据时,缓存中没有数据,就会发生缓存缺失。应用再访问数据库,但是数据库中的值为旧值,应用就访问到旧值了。
    25 Redis的缓存中的数据和数据库中的不一致问题_第2张图片
    应用把数据 X 的值从 10 更新为 3,先在 Redis 缓存中删除了 X 的缓存值,但是更新数据库却失败了。如果有其他并发的请求访问 X,会发现 Redis 中缓存缺失, 请求就会访问数据库,读到的却是旧值 10。
    如果先更新数据库,再删除缓存中的值: 如果应用先完成了数据库的更新,但是在删除缓存时失败了,数据库中的值是新值,而缓存中的是旧值。如果有其他的并发请求来访问数据,按照正常的缓存访问流程,就会先在缓存中查询读到旧值了。
    25 Redis的缓存中的数据和数据库中的不一致问题_第3张图片
    应用要把数据 X 的值从 10 更新为 3,先成功更新了数据库,然后在 Redis 缓存中删除 X 的缓存,但是这个操作却失败了,数据库中 X 的新值为 3,Redis 中的 X 的缓存值为 10。如果有其他客户端也发送请求访问 X,会先在 Redis 中查询,发现缓存读到的却是旧值 10。
    在更新数据库和删除缓存值的过程中,无论这两个操作的执行顺序谁先谁后,只要有一个操作失败了,导致客户端读取到旧值。
    25 Redis的缓存中的数据和数据库中的不一致问题_第4张图片

二、解决Redis 和数据库数据不一致的方法

重试机制:

把要删除的缓存值或者是要更新的数据库值暂存到消息队列中。

  • 如果没有能够成功地删除缓存值或者是更新数据库值时,可以从消息队列中重新读取这些值,然后再次进行删除或更新。
  • 如果能够成功地删除或更新,要把这些值从消息队列中去除,以免重复操作,保证数据库和缓存的数据一致了。否则的话还需要再次进行重试。 如果重试超过的一定次数,还是没有成功,就需要向业务层发送报错信息了。先更新数据库,再删除缓存值时,如果缓存删除失败,再次重试后删除成功的情况:
    25 Redis的缓存中的数据和数据库中的不一致问题_第5张图片

刚刚说的是在更新数据库和删除缓存值的过程中,其中一个操作失败的情况,实际上即使这两个操作第一次执行时都没有失败,当有大量并发请求时,应用还是有可能读到不一致的数据。

情况一:先删除缓存,再更新数据库。

假设线程 A 删除缓存值后,还没有来得及更新数据库(比如说有网络延迟),线程 B 就开始读取数据了,线程 B 会发现缓存缺失,去数据库读取。这会带来两个问题:

  1. 线程 B 读取到了旧值;
  2. 线程 B 是在缓存缺失的情况下读取的数据库,还会把旧值写入缓存,会导致其他线程从缓存中读到旧值。

等到线程 B 从数据库读取完数据、更新了缓存后,线程 A 才开始更新数据库,此时缓存中的数据是旧值,而数据库中的是最新值,两者就不一致了。
25 Redis的缓存中的数据和数据库中的不一致问题_第6张图片

延迟双删: 在线程 A 更新完数据库值以后,让它先 sleep 一小段时间,再进行一次缓存删除操作。为了让线程 B 能够先从数据库读取数据,再把缺失的数据写入缓存,然后线程 A 再进行删除。所以线程 A sleep 的时间,就需要大于线程 B 读取数据再写入缓存的时间。在业务程序运行的时候, 统计下线程读数据和写缓存的操作时间,以此为基础来进行估算sleep时间。 其它线程读取数据时,会发现缓存缺失,会从数据库中读取最新值。

延迟双删方案的伪代码示例:

redis.delKey(X) 
db.update(X) 
Thread.sleep(N) 
redis.delKey(X) 

情况二:先更新数据库值,再删除缓存值。

如果线程 A 删除了数据库中的值,但还没来得及删除缓存值,线程 B 就开始读取数据了,线程 B 查询缓存时,发现缓存命中,会直接从缓存中读取旧值。如果其他线程并发读缓存的请求不多,就不会有很多请求读取到旧值。而且线程 A 一般也会很快删除缓存值,其他线程再次读取时,会发生缓存缺失,进而从数据库中读取最新值。所以这种情况对业务的影响较小。

25 Redis的缓存中的数据和数据库中的不一致问题_第7张图片
缓存和数据库的数据不一致一般是由两个原因导致:

  1. 删除缓存值或更新数据库失败而导致数据不一致,可以使用重试机制确保删除或更新操作成功。
  2. 在删除缓存值、更新数据库的这两步操作中,有其他线程的并发读操作,导致其他线程读取到旧值,应对方案是延迟双删。

总结

Redis 缓存和数据库 不一致的问题,可以分成读写缓存和只读缓存两种情况进行分析:

  1. 读写缓存:如果我们采用同步写回策略,可以保证缓存和数据库中的数据一 致。
  2. 只读缓存:

    在大多数业务场景下,会把 Redis 作为只读缓存使用。既可以先删除缓存值再更新数据库,也可以先更新数据库再删除缓存。

建议优先使用先更新数据库再删除缓存的方法,原因有两个:

  1. 先删除缓存值再更新数据库,有可能导致请求因缓存缺失而访问数据库,给数据库带来压力;
  2. 如果业务应用中读取数据库和写缓存的时间不好估算,那么延迟双删中的等待时间就不好设置。

先更新数据库再删除缓存需要注意:如果业务层要求必须读取一致的数据,就需要在更新数据库时,先在 Redis 缓存客户端暂存并发读请 求,等数据库更新完、缓存值删除后,再读取数据从而保证数据一致性。

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