概述

只要使用 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 读取数据再写入缓存的时间。

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

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

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

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 作为只读缓存使用。针对只读缓存来说，我们既可以先删除缓存值再新增数据库，也可以先更新数据库再删除缓存。我的建议是，优先使用先更新数据库再删除缓存的方法，原因主要有两个：

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

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