Redis 笔记七

Posted by MatthewHan on 2021-07-15

Q:缓存异常(上):解决缓存和数据库的数据不一致问题

缓存和数据库的数据不一致是如何发生的?

首先,我们得清楚“数据的一致性”具体是啥意思。其实,这里的“一致性”包含了两种情况:

  • 缓存中有数据,那么,缓存的数据值需要和数据库中的值相同;

  • 缓存中本身没有数据,那么,数据库中的值必须是最新值。

不符合这两种情况的,就属于缓存和数据库的数据不一致问题了。

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

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

新增数据

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

删改数据

情况一:

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

img

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

情况二:

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

img

总结:

在更新数据库和删除缓存值的过程中,无论这两个操作的执行顺序谁先谁后,只要有一个操作失败了,就会导致客户端读取到旧值。

img

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

首先,没有银弹,没有完美的解决方案和手段,无法做到 100% 解决一致性问题。只能是根据业务的实际情况去选择相对最优的方案。

重试机制

具体来说,可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中(例如使用 Kafka 消息队列)。当应用没有能够成功地删除缓存值或者是更新数据库值时,可以从消息队列中重新读取这些值,然后再次进行删除或更新。

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

img

说白了就是把需要更新的数据的消息存在 MQ 中,只有成功操作了(更新 Redis、数据库),才在 MQ 中消费弹出。

当然引进了 MQ 是为了解决一致性的问题,但是还是会引来新的问题,就是 MQ 的消费与执行的一致性。。。

高并发下的问题

在高并发的场景下,无论先更新 Redis 还是先更新 database 都会有一点的时间差,这段时间差,如果有其他线程进行读写数据,依然存在数据不一致的问题。

因为 Redis 的 database 两者的操作就不符合原子性,所以直接躺平吧。

Q:缓存异常(下):解决缓存雪崩、击穿、穿透难题

沾点老八股了

缓存雪崩

缓存雪崩是指大量的应用请求无法在 Redis 缓存中进行处理,紧接着,应用将大量请求发送到数据库层,导致数据库层的压力激增。

说白了就是大量 kv 在同一时刻过期,而该时刻正是业务高峰期。

当然 Redis 的突然宕机也会造成缓存雪崩。

img

事前应对

  • 避免给大量的数据设置相同的过期时间。如果业务层的确要求有些数据同时失效。
  • 可以在用 EXPIRE 命令给每个数据设置过期时间时,给这些数据的过期时间增加一个较小的随机数(例如,随机增加 1~3 分钟),这样一来,不同数据的过期时间有所差别,但差别又不会太大,既避免了大量数据同时过期,同时也保证了这些数据基本在相近的时间失效,仍然能满足业务需求。

事后应对

通过服务降级,来应对缓存雪崩。

所谓的服务降级,是指发生缓存雪崩时,针对不同的数据采取不同的处理方式。

  • 当业务应用访问的是非核心数据(例如电商商品属性)时,暂时停止从缓存中查询这些数据,而是直接返回预定义信息、空值或是错误信息;
  • 当业务应用访问的是核心数据(例如电商商品库存)时,仍然允许查询缓存,如果缓存缺失,也可以继续通过数据库读取。

当 Redis 出现突然宕机的情况

  • 在业务系统中实现服务熔断或请求限流机制。
  • 主从节点切换恢复 Redis 服务

缓存击穿

缓存击穿是指,针对某个访问非常频繁的热点数据的请求,无法在缓存中进行处理,紧接着,访问该数据的大量请求,一下子都发送到了后端数据库,导致了数据库压力激增,会影响数据库处理其他请求。缓存击穿的情况,经常发生在热点数据过期失效时。

说白了就是热点 key,本身的流量就大,但是 Redis 里却没有数据

img

如何对敌?

为了避免缓存击穿给数据库带来的激增压力,我们的解决方法也比较直接,**对于访问特别频繁的热点数据,我们就不设置过期时间了。**这样一来,对热点数据的访问请求,都可以在缓存中进行处理,而 Redis 数万级别的高吞吐量可以很好地应对大量的并发请求访问。

缓存穿透

缓存穿透是指要访问的数据既不在 Redis 缓存中,也不在数据库中,导致请求在访问缓存时,发生缓存缺失,再去访问数据库时,发现数据库中也没有要访问的数据。

跟缓存雪崩、缓存击穿这两类问题相比,缓存穿透的影响更大一些。

img

那么,缓存穿透会发生在什么时候呢?一般来说,有两种情况。

  • 业务层误操作:缓存中的数据和数据库中的数据被误删除了,所以缓存和数据库中都没有数据;
  • 恶意攻击:专门访问数据库中没有的数据。

如何对敌?

第一种方案是,缓存空值或缺省值。

一旦发生缓存穿透,我们就可以针对查询的数据,在 Redis 中缓存一个空值或是和业务层协商确定的缺省值(例如,库存的缺省值可以设为 0)。紧接着,应用发送的后续请求再进行查询时,就可以直接从 Redis 中读取空值或缺省值,返回给业务应用了,避免了把大量请求发送给数据库处理,保持了数据库的正常运行。

使用布隆过滤器快速判断数据是否存在

img

我们可以在把数据写入数据库时,使用布隆过滤器做个标记。当缓存缺失后,应用查询数据库时,可以通过查询布隆过滤器快速判断数据是否存在。如果不存在,就不用再去数据库中查询了。

在请求入口的前端进行请求检测

前端拦截恶意的请求

总结

img
  • 针对缓存雪崩,合理地设置数据过期时间,以及搭建高可靠缓存集群;
  • 针对缓存击穿,在缓存访问非常频繁的热点数据时,不要设置过期时间;
  • 针对缓存穿透,提前在入口前端实现恶意请求检测,或者规范数据库的数据删除操作,避免误删除。