日常开发中常会使用redis作为项目中的缓存,只要我们使用 Redis 缓存,就必然会面对缓存和数据库间的一致性保证问题。而且如果数据不一致,那么应用从缓存中读取的数据就不是最新数据,可能会导致严重的业务问题。
数据一致性:指的是redis缓存跟数据库的数据的一致。假如缓存中没有数据,那么数据库的值必须是最新的。如果缓存中有数据,那么缓存中的值需要跟数据库的值相同。
理解完上述数据一致性的前提,我们看下什么情况下会导致缓存跟数据库的数据不一致。
场景 | 问题 |
---|---|
先删除缓存,再更新数据库 | 先删除缓存值, 数据库更新失败,导致请求再次访问缓存时,发现缓存缺失,再读数据库时,从数据库中读到旧值 |
先更新数据库,再删除缓存 | 缓存删除失败,导致请求再次访问缓存时,发现缓存命中,并从缓存中读取到旧值 |
无论是先操作缓存,还是先操作数据库,假如后者执行失败,我们可以发起重试,尽可能地去做「补偿」。我们可以把要更新/删除的值暂存到消息队列中,当应用没有能够成功地更新/删除数据库值时,可以从消息队列中重新读取这些值,然后再次进行删除或者更新。
这种做法引入消息队列,可能会增加更多的维护成本。如果重试超过的一定次数还是失败,需要向业务层发送报错信息。
注意:即使这两个操作执行时都没有失败,但是当有大量并发请求时,应用还是可能会读到不一致的数据。还是分以下两种情况讨论!
假设线程 A 删除了数据库中的值,但还没来得及删除缓存,线程 B 就开始读取数据了,那么此时,线程 B 查询缓存时,就会直接从缓存中读取到旧值。不过这种情况下,如果其他线程并发读缓存的请求不多,那么就不会有很多请求读取到旧值。并且线程 A 一般也会很快删除缓存值,这样其他线程再次读取时,就会发生缓存缺失,然后去数据库中获取最新的值,因此这种情况对业务的影响较小。
我们先删除缓存,然后更新数据库的值,更新完数据库值以后,我们可以让线程先 sleep 一小段时间,再进行一次缓存删除操作。
这就是延迟双删,伪代码如下
redis.delKey(K)
db.update(K)
Thread.sleep(T)
redis.delKey(K)
有了sleep 的这段时间,即使有其他缓存从数据库读取到旧的值并重新放到缓存中,我们也能再次删除,保证缓存中会是新的值。至于sleep的这个时间如何确定?以实际业务执行时间为准。