redis面试：如何保证缓存和数据库数据的一致性？_使用update更新数据,json缓存不更新

为什么要保证缓存和数据库的数据一致

如果数据不一致，那么业务应用从缓存中读取的数据就不是最新的数据，这会导致严重的错误

这里的“数据一致性”是什么意思？

首先，我们必须知道这里的“数据一致性”是什么意思。这里“一致性”包括两种情况：

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

不符合这两种情况的，就是缓存和数据库的数据不一致了。

为什么会发生缓存和数据库的数据不一致

当缓存的读写模式不同时，缓存数据不一致发生的情况不一样。

当redis作为读写缓存时

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

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

所以，对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用同步直写策略。不过，需要注意的是：如果采用这种策略，就需要保证同时更新缓存和数据库。所以，我们要在业务应用中使用事务机制，来保证缓存和数据库的更新具有原子性，也就是说，两者要不一起更新，要不都不更新，返回错误信息，进行重试。否则，我们就无法实现同步直接

当然，在有些场景下，我们对数据一致性的要求可能不是那么高，那么，我们可以使用异步写回策略。

当redis作为只读缓存时

对于只读缓存来说：

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

那么，这个过程中会不会出现数据不一致的情况呢？
（1）新增数据：

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

（2）删改数据

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

• 我们假设应用先删除缓存，再更新数据库，如果缓存删除成功，但是数据库更新失败，那么，应用再访问数据时，缓存中没有数据，就会发生缓存缺失。然后，应用再访问数据库，但是数据库中的值为旧值，应用就访问到旧值了。
  
• 如果应用先完成了数据库的更新，但是，在删除缓存时失败了，那么，数据库中的值是新值，而缓存中的是旧值，这肯定是不一致的。这个时候，如果有其他的并发请求来访问数据，按照正常的缓存访问流程，就会先在缓存中查询，但此时，就会读到旧值了。
  
  总结：在更新数据库和删除缓存值的过程中，无论这两个操作的执行顺序谁先谁后，只要有一个操作失败了，就会导致客户端读取到旧值
  

如何解决数据不一致问题？

第一种方法：重试机制

具体的说，就是：

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

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

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

同样，我们按照不同的删除和更新顺序，分成两种情况来看。在这两种情况下，我们的解决方法也有所不同。

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

假设线程 A 删除缓存值后，还没有来得及更新数据库（比如说有网络延迟），线程 B 就开始读取数据了，那么这个时候，线程 B 会发现缓存缺失，就只能去数据库读取。这会带来两个问题：

1. 线程 B 读取到了旧值；
2. 线程 B 是在缓存缺失的情况下读取的数据库，所以，它还会把旧值写入缓存，这可能会导致其他线程从缓存中读到旧值。

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

• 之所以要加上 sleep 的这段时间，就是为了让线程 B 能够先从数据库读取数据，再把缺失的数据写入缓存，然后，线程 A 再进行删除。所以，线程 A sleep 的时间，就需要大于线
  程 B 读取数据再写入缓存的时间。这个时间怎么确定呢？建议你在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进行估算。
• 这样一来，其它线程读取数据时，会发现缓存缺失，所以会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后，延迟一段时间再次进行删除，所以我们也把它叫做“延迟双删”。

redis.delKey(X) 
db.update(X) 
Thread.sleep(N) 
redis.delKey(X)
1
2
3
4

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

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

回答

（1）对于读写缓存来说，如果我们采用同写回策略，就可以保证缓存和数据库中的数据一致

（2）对于只读缓存

缓存和数据库的数据不一致一般是由两个原因导致的。其解决方案总结如下：

• 删除缓冲值和更新数据库失败而导致数据不一致，可以使用重试机制确保删除或者更新操作成功
• 在删除缓存值、更新数据库的这两步操作中，有其他线程的并发读操作，导致其他线程读取到旧值，应对方案是延迟双删
  
  另外，在大部分业务场景下，我们会把redis作为只读缓存使用。针对只读缓存来说，我们既可以先删除缓存值再更新数据库，也可以先更新数据库再删除缓存。建议是，优先使用先更新数据库再删除缓存的方法，原因主要有两个：
• 先删除缓存值在更新数据库，有可能导致请求因为缓存缺失而访问数据库，给数据库带来压力
• 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延时双删中的等待时间就不好设置

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