Redis核心技术与实战【学习笔记】 - 16.Redis 缓存异常：缓存和数据库不一致

概述

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

1.缓存和数据库的数据不一致是如何发生的？

"数据的一致性"包含了两种情况：

缓存中有数据，那么，缓存的数据值需要和数据库中的值相同；
缓存中没有数据，那么，数据库中的值必须是最新的。

不符合这两种情况的，就属于缓存和数据库的数据不一致问题了。不过，当缓存的读写模式不同时，缓存数据不一致的发生情况不一样，应对的方法也不同，所以先按照缓存的读写模式，来分别了解不同模式下的缓存不一致情况。

在《 14.Redis 旁路缓存的工作原理及如何选择应用系统的缓存类型》中讲过，可以把缓存分成读写缓存和只读缓存。

对于读写缓存来说，如果要对数据进行增删改，就需要在缓存中进行，同时还要根据采取的写回策略，决定是否同步写回到数据库中。

同步直接策略：写缓存时，也同步写数据库，缓存和数据库中的数据一致。
异步写回策略：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库。

使用异步写回策略时，如果数据还没有写回数据库，缓存就发生了故障，那么，数据库就没有最新的数据了。

所以，对于读写缓存来说，要想保证缓存和数据库中的数据一致 ，就要采用同步直写策略。

需要注意的是，如果采用这种策略，就要同时更新缓存和数据库。所以，我们要在业务中使用事务机制，来保证缓存和数据库的更新具有原子性，也就是说，两者要不一起更新，不要一起不更新，返回错误信息，进行重试。

当然，在有些场景下，我们对数据一致性的要求可能不是那么高 ，比如说缓存的是电商商品的非关键属性 或者短视频的创建或修改时间，那么我们可以使用异步写回策略。

再说说只读缓存。对于只读缓存来说，如果有数据新增，会直接写入数据库；而数据删改时，只需要把缓存中的数据标记为无效，这样一来，业务系统后续访问这些增删改的数据时，就会发生缓存缺失。此时，应用再从数据库中把数据读入缓存，这样后续再访问数据时，就能直接从缓存中读取了。

以 Tomcat 向 MySQL 中写入和删改数据为例，来几十下，数据增删改操作是如何进行的：

从图中可以看出，Tomcat 上运行的应用，物理是新增、修改、还是删除数据 X，都会直接在数据库中进行。当然，如果应用执行的是修改或删除操作，还是删除缓存的数据 X。

那么，这个过程中会不会出现数据不一致的情况呢？考虑到新增和删改数据的情况不一样，所以分开来进行讲解。

A.新增数据

如果是新增数据，数据会直接写道数据库中，不用对缓存做任何操作，此时，缓存中本身就没有新增数据，而数据库中有最新值，这种情况和服一致性的第 2 种情况，所以，缓存和数据此时是一致的。

B.删改数据

如果发生了删改操作，应用既要更新数据库，也要在缓存中删除数据。这两个操作如何无法保证原子性，就会出现数据不一致的问题了。

假设先删除缓存，再更新数据库，如果缓存删除成功，但是数据库更新失败，那么应用再访问数据时，缓冲中没有数据，然后再访问数据库，但是数据库中的值为旧值，应用就访问到旧值了。

应用要把数据 X 的值从 10 更新为 3，现在 Redis 缓存中删除了 X 的值。但是更新数据库确失败了。

如果此时有其他的并发请求访问 X，会发现 Redis 中缓存缺失。

紧接着，请求就会访问数据库，读到的却是旧值 10。

如果先更新数据库，再删除缓存中的值，是不是可以解决这个问题呢？

如果应用完成了数据库的更新，但是在删除缓存时失败了，那么数据库中的值是最新的，而缓存中是旧值，这肯定是不一致的。这个时候，如果有其他的请求来访问数据，就会在缓存中查询，读取到旧值了。

应用要把数据 X 的值从 10 更新为 3，先更新成功了数据库

然后在 Redis 缓存中删除 X 的缓存，但是这个操作失败了。此时，数据库中 X 的值为 3，Redis 中的 X 的缓存值为 10，出现了不一致的情况

如果刚刚此时有其他客户端也发送请求访问 X，会先在 Redis 中查询，该客户端会发现缓存命中，但是读到的却是旧值 10。

从上面的分析，可以得出结论：在更新数据库和删除缓存的过程中，无论两个操作的执行顺序谁先水后，只要有一个操作失败了，就会导致客户端读取到旧值。

不同情况	潜在问题
先删除缓存值，后更新数据库	数据库更新失败，缓存删除成功。导致请求再次访问缓存时，发现缓存缺失，再读数据库时，从数据库中读到旧值
先更新数据库，后删除缓存值	缓存删除失败，导致请求再次访问缓存时，发现缓存命中，从缓存中读取到旧值

问题发生的原因我们知道了，那该怎么解决？

2.如何解决数据不一致问题?

可以把要删除的缓存值或者要更新的数据库值暂存到消息队列中。当应用没有成功地删除缓存值或者是更新数据库值 时，可以从消息队列中取这些值，然后再次进行删除或更新操作。如果成功地删除或更新 ，就要把这些值从消息队列中去除，以免重复操作。此时，也就可以保证数据库和缓存的数据一致了。否则的话，还要进行重试。如果重试超过一定次数，还是没有成功，我们就需要向业务层发送报错信息。

下图显示了先更新数据库，再删除缓存值时，如果缓存删除失败，再次重试后删除成功的情况。

刚刚说的是在更新数据库和删除缓存值的过程中，其中一个操作失败的情况。

实际上，即使这两个操作第一次执行都成功，当有大量并发请求时，应该还是有可能读到不一致的数据的。

同样，按照不同的删除和更新顺序，我们的解决办法也有所不同：

情况一：先删除缓存，在更新数据库

假设线程 A 删除缓存值后，还没有来得及更新数据库（比如网络延迟），线程 B 就开始读取数据。

时间	线程A	线程B	问题
T1	删除缓存X的缓存值
T2		1.读取数据X，缓存缺失，从数据库中读取X，读到旧值； 2.把数据 X 写入缓存	1.线程 A 尚未更新数据库的值，导致线程B读取到旧值； 2.线程B把旧值写入缓存，导致其他线程可能读到旧值
T3	更新数据库中的X		缓存中是旧值，数据库中是新值，两者不一致

这该怎么办？

在线程 A 更新完数据库的值后，我们可以让他先 sleep 一小段时间，再进行一次缓存删除操作。

之所以要加上 sleep的这段时间，就是为了让线程 B 能够先从数据库读取数据，再把缺失的数据写入缓存，然后线程 A 再进行删除。所以，线程 A sleep 的时间，就需要大于线程 B 读取数据再写入缓存的时间。

这个时间该如何确定？建议你在业务程序运行的时候，统计下线程读数据和写数据的操作时间，以此为基础来进行估算。

这样一来，其他线程读取数据时，会发现缓存缺失，就会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后，延迟一段时间再次删除，所以我们也把它叫做"延迟双删"。

下面是一段延迟双删的伪代码示例：

java 复制代码

redisCache.delKey(X);
db.update(X);
Thread.sleep(N);
redisCache.delKey(X);

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

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

时间	线程A	线程B	问题
T1	删除数据库中的数据X
T2		读取数据 X，缓存命中从缓存读取 X，读取到旧值	线程A尚未删除缓存值，导致线程B读到缓存的旧值
T3	删除缓存的数据 X

缓存和数据库的数据不一致一般是由两个原因导致的，我给你提供了相应解决方案。

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

3.小结

我总结了一张表，便于你更加清晰的了解数据不一致的问题。

操作顺序	是否有并发请求	潜在问题	现象	应对方案
先删除缓存值，在更新数据库	无	缓存删除成功，但数据库更新失败	应用从数据库读到旧数据	重试数据库更新
先删除缓存值，在更新数据库	有	缓存删除成功，尚未更新数据库，有并发读请求	并发请求从数据库读到旧值，并且更新到缓存，导致后续请求都读取旧值	延迟双删
先更新数据库，在删除缓存	无	数据库更新成功，但缓存删除失败	应用从缓存读到旧值	重试缓存删除
先更新数据库，在删除缓存	有	数据库更新成功，尚未删除缓存，有并发读请求	并发请求从缓存中读到旧值	等待删除完成，期间会有不一致数据短暂存在

在大多数业务场景下，我们会把 Redis 作为只读缓存使用。针对只读缓存来说 ，我们既可以先删除缓存值再新增数据库，也可以先更新数据库再删除缓存。我的建议是，优先使用先更新数据库再删除缓存的方法，原因主要有两个：

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

不过，当使用先更新数据库再删缓存时，有个地方需要注意，如果业务层要求必须读取一致的数据，那么，我们就需要在更新数据库时，先在 Redis 缓存客户端暂存并发读请求，等数据更新完、缓存值删除后，再读取数据，从而保证数据一致性。