redis 如何保证数据一致性

引言

日常开发中常会使用redis作为项目中的缓存,只要我们使用 Redis 缓存,就必然会面对缓存和数据库间的一致性保证问题。而且如果数据不一致,那么应用从缓存中读取的数据就不是最新数据,可能会导致严重的业务问题。

为什么会数据不一致

数据一致性:指的是redis缓存跟数据库的数据的一致。假如缓存中没有数据,那么数据库的值必须是最新的。如果缓存中有数据,那么缓存中的值需要跟数据库的值相同。

理解完上述数据一致性的前提,我们看下什么情况下会导致缓存跟数据库的数据不一致。

  • 并发更新问题:当多个客户端同时对同一个数据进行更新时,假设有两个客户端同时读取了数据库中的数据,然后对其进行了修改,并分别将修改后的数据存入缓存。因为两个客户端并不知道对方的修改,所以会导致缓存中存储的数据和数据库中的数据不一致。
  • 异常情况:在更新缓存的过程中,如果发生了错误或者异常,可能导致缓存更新失败,从而导致缓存和数据库数据不一致,大致分为如下两种场景。
场景 问题
先删除缓存,再更新数据库 先删除缓存值, 数据库更新失败,导致请求再次访问缓存时,发现缓存缺失,再读数据库时,从数据库中读到旧值
先更新数据库,再删除缓存 缓存删除失败,导致请求再次访问缓存时,发现缓存命中,并从缓存中读取到旧值

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

重试机制

无论是先操作缓存,还是先操作数据库,假如后者执行失败,我们可以发起重试,尽可能地去做「补偿」。我们可以把要更新/删除的值暂存到消息队列中,当应用没有能够成功地更新/删除数据库值时,可以从消息队列中重新读取这些值,然后再次进行删除或者更新。

这种做法引入消息队列,可能会增加更多的维护成本。如果重试超过的一定次数还是失败,需要向业务层发送报错信息。

注意:即使这两个操作执行时都没有失败,但是当有大量并发请求时,应用还是可能会读到不一致的数据。还是分以下两种情况讨论!

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

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

先删除缓存,再更新数据库(延迟双删)

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

这就是延迟双删,伪代码如下

redis.delKey(K)
db.update(K)
Thread.sleep(T)
redis.delKey(K)

有了sleep 的这段时间,即使有其他缓存从数据库读取到旧的值并重新放到缓存中,我们也能再次删除,保证缓存中会是新的值。至于sleep的这个时间如何确定?以实际业务执行时间为准。

总结

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

本文由 mdnice 多平台发布

你可能感兴趣的:(后端)