在实际应用 Redis 缓存时，我们必然会面对缓存和数据库间的一致性保证问题。如果数据不一致，那么业务应用从缓存中读取的数据就不是最新数据，这就会导致严重的错误。

数据不一致产生原因？

首先，我们需要明确数据的一致性具体是啥意思。其实，这里的“一致性”包含了两种情况：

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

不符合这两种情况的，就属于缓存和数据库的数据不一致问题了。不过，当缓存的读写模式不同时，缓存数据不一致的发生情况不一样，我们的应对方法也会有所不同。所以，我们先按照缓存读写模式，来分别了解下不同模式下的缓存不一致情况。根据是否接收写请求，我们可以把缓存分成 读写缓存 和 只读缓存。

1. 读写缓存

对于读写缓存来说，应用层读写只需要操作缓存，不需要关心后端数据库。应用层在操作缓存时，缓存层会自动从数据库中加载或写回到数据库中。如果要对数据进行增删改，就需要在缓存中进行，同时还要根据采取的写回策略，决定是否要同步写回到数据库中。

• 同步直写策略：写缓存时，也同步写数据库，缓存和数据库中的数据一致；
• 异步写回策略：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库。使用这种策略，如果数据还没有写回数据库，缓存就发生了故障，那此时，数据库就没有最新的数据了。

所以，对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用 同步直写 策略。不过，需要注意的是，如果采用这种策略，就需要同时更新缓存和数据库。所以，我们要在业务应用中使用事务机制或分布式锁来保证缓存和数据库的更新具有原子性，也就是说，两者要不一起更新，要不都不更新。当然，在有些场景下，我们对数据一致性的要求可能不是那么高，那我们可以使用 异步写回 策略。

2. 只读缓存

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

这样做的优点是，数据库和缓存可以保证完全一致，并且缓存中永远保留的是经常访问的热点数据。缺点是每次修改操作都会把缓存中的数据删除，之后访问时都会先触发一次缓存缺失，然后从后端数据库加载数据到缓存中的这个过程访问延迟会变大。只读缓存是牺牲了一定的性能，优先保证数据库和缓存的一致性，它更适合对于一致性要求比较要高的业务场景。

从图中可以看到，Tomcat 上运行的应用，无论是新增、修改还是删除数据 X，都会直接在数据库中增改删。当然，如果应用执行的是修改或删除操作，还会删除缓存的数据 X。那么，这个过程中会不会出现数据不一致的情况呢？考虑到新增数据和删改数据的情况不一样，所以我们分开来看。

2.1 新增数据

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

2.2 删改数据

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

先删除缓存再更新数据库：

我们假设应用先删除缓存，再更新数据库，如果缓存删除成功，但是数据库更新失败，那么，应用再访问数据的时候，缓存中没有数据，就会发生缓存缺失。然后，应用再访问数据库，但是数据库中的值为旧值，应用就访问到旧值了。过程如下所示：

应用要把数据 X 的值从 10 更新为 3，先在 Redis 缓存中删除了 X 的缓存值，但是更新数据库却失败了。如果此时有其他并发的请求访问 X，会发现 Redis 中缓存缺失，然后请求就会访问数据库，读到的却是旧值 10。

先更新数据库再删除缓存：

如果应用先更新了数据库，但在删除缓存时失败了，那数据库中的值是新值，而缓存中的是旧值，这肯定是不一致的。这个时候，如果有其他的并发请求来访问数据，按照正常的缓存访问流程，就会先在缓存中查询，但此时，就会读到旧值了。过程如下所示：

应用要把数据 X 的值从 10 更新为 3，先成功更新了数据库，然后在 Redis 缓存中删除 X 的缓存，但是这个操作却失败了，此时，数据库中 X 的新值为 3，Redis 中的 X 的缓存值为 10，这肯定是不一致的。当客户端发送请求访问 X，会先在 Redis 中查询，该客户端会发现缓存命中，但是读到的却是旧值 10。

需要注意的是，更新数据库后删除缓存的操作可能失败，如果失败则考虑把任务加入延迟队列进行延迟重试，确保数据可以删除，缓存可以及时更新。因为删除操作是幂等的，所以即使重复删问题也不是太大，这又是删除比更新好的一个原因。

如何解决数据不一致？

刚刚说的是在更新数据库和删除缓存值的过程中，其中一个操作失败的情况。实际上，即使这两个操作第一次执行时都没有失败，当有大量并发请求时，应用还是有可能读到不一致的数据。同样，我们按照不同的删除和更新顺序，分成两种情况来看。在这两种情况下，我们的解决方法也有所不同。

1. 先删缓存再更新数据库

假设线程 A 删除缓存值后，还没有来得及更新数据库（比如说有网络延迟），线程 B 就开始读取数据了，那么这个时候，线程 B 会发现缓存缺失，就只能去数据库读取。此时，线程 B 读取到的是旧值，并且线程 B 是在缓存缺失的情况下读取的数据库，所以，它还会把旧值写入缓存，这可能会导致其他线程从缓存中读到旧值。

等到线程 B 从数据库读取完数据、更新了缓存后，线程 A 才开始更新数据库，此时，缓存中的数据是旧值，而数据库中的是最新值，两者就不一致了。我用一张表来汇总下这种情况。

要想解决这种情况，我们可以在线程 A 更新完数据库后让它先 sleep 一小段时间，再进行一次缓存删除操作。之所以要加上 sleep 的这段时间，就是为了让线程 B 能够先从数据库读取数据，再把缺失的数据写入缓存，然后线程 A 再进行删除。所以，线程 A sleep 的时间，就需要大于线程 B 读取数据再写入缓存的时间。

这样一来，其它线程读取数据时，会发现缓存缺失，所以会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后，延迟一段时间再次进行删除，所以我们也把它叫做 延迟双删方案。下面的这段伪代码就是延迟双删方案的示例：

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

2. 先更新数据库再删缓存

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

总结

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

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

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