• 欢迎访问开心洋葱网站,在线教程,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入开心洋葱 QQ群
  • 为方便开心洋葱网用户,开心洋葱官网已经开启复制功能!
  • 欢迎访问开心洋葱网站,手机也能访问哦~欢迎加入开心洋葱多维思维学习平台 QQ群
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏开心洋葱吧~~~~~~~~~~~~~!
  • 由于近期流量激增,小站的ECS没能经的起亲们的访问,本站依然没有盈利,如果各位看如果觉着文字不错,还请看官给小站打个赏~~~~~~~~~~~~~!

Redis缓存篇(四)缓存异常

Cache 大杂草 1240次浏览 0个评论

这一节,我们来学习一下缓存异常。缓存异常有四种类型,分别是缓存和数据库的数据不一致、缓存雪崩、缓存击穿和缓存穿透。

下面通过了解这四种缓存异常的原理和应对方法。

缓存和数据库的数据不一致

缓存和数据库的数据一致性包含两种情况:

  • 缓存中有数据,缓存的数据值需要和数据库中的值相同;
  • 缓存中没有数据,数据库中的值必须是最新值。

数据不一致是如何发生的?

在第1讲中关于缓存的类型那节,介绍了缓存有两种不同类型,分别是只读缓存和读写缓存。不同类型的缓存数据不一致的发生情况不一样,应对方法也不一样。

读写缓存:有两种写回策略,同步直写和异步写回。如果要保证数据一致,就要采用同步直写策略。但需要保证缓存和数据库的更新具有原子性,即要么都成功,要么都失败。

只读缓存:分新增数据和删改数据两种情况说明。

新增数据

数据直接写到数据库中,不对缓存做任何操作,符合一致性的第2种情况。

删改数据

发生删改操作时,既要更新数据库,也要在缓存里删除数据。因为缓存和数据库是不同的系统,这里分两种情况:

  • 先删除缓存,再更新数据库:数据库更新失败,导致请求再次访问缓存时,发现缓存失败,再读数据库时,从数据库中读取旧值。
  • 先更新数据库,再删除缓存:缓存删除失败,导致请求再次访问缓存时,发现缓存命中,并从缓存中读取到旧值。

如何解决数据不一致?

使用重试机制,指把删除的缓存值或者是要更新的数据库值暂存到消息队列中(例如使用Kafka消息队列)。

当应用没有能够成功地删除缓存值或者是更新数据库值时,从消息队列中重新读取这些值,然后再次进行删除或更新。

如果成功删除,就从消息队列中删除,以免重复操作。否则就要进行重试,如果重试超过一定次数,就要向业务层发送报错信息。

具体情况如下图所示:

Redis缓存篇(四)缓存异常

总结一下,对于只读缓存来说,建议优先使用先更新数据库,再删除缓存

缓存雪崩

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

导致缓存雪崩的两个原因:

1. 缓存中有大量数据同时过期,导致大量请求无法得到处理。

解决方案有两个,一是避免给大量的数据设置相同的过期时间,增加一个较小的随机数(例如,随机增加1~3分钟)。

另一个是服务降级,服务降级指发生缓存雪崩时,针对不同的数据采取不同的处理方式:

  • 非核心数据,暂时停止从缓存中查询,直接返回预定义信息、空值或者错误信息;
  • 核心数据,允许查询缓存,如果缓存缺失,继续通过数据库读取。

2. Redis缓存实例发生故障宕机了,无法处理请求。

有两个建议,一是在业务系统中实现服务熔断或请求限流机制

服务熔断是指在发生缓存雪崩时,为了防止引发连锁的数据库雪崩,暂停业务应用对缓存系统的接口访问。

具体点,就是业务应用调用缓存接口时,缓存客户端并不把请求发给Redis缓存实例,而是直接返回,等Redis缓存实例重新恢复服务后,再允许发送。

服务熔断会暂停了整个缓存系统的访问,对业务应用的影响范围大。而请求限流相比服务熔断造成的影响没那么大。

请求限流是指业务系统的请求入口前端控制每秒进入系统的请求数,避免过多的请求被发送到数据库。

二是事前预防,通过主从节点构建Redis缓存高可靠集群。

缓存击穿

缓存击穿,指针对某个访问非常频繁的热点数据的请求,无法在缓存中进行处理,大量请求发送到后端数据库,导致数据库压力激增,影响数据库处理其他请求。

解决方案是,对于访问特别频繁的热点数据,不设置过期时间

缓存穿透

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

如果有大量请求访问数据,就会同时给缓存和数据库带来巨大压力。

发生缓存穿透有两种情况:

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

为了避免缓存穿透,有三种应对方案。

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

一旦发生缓存穿透,就针对查询的数据,在Redis中缓存一个空值或是和业务层协商确定的缺省值。

第二种方案是,使用布隆过滤器快速判断数据是否存在,避免从数据库中查询数据是否存在,减轻数据库压力

布隆过滤器由一个初值都为0的bit数组和N个哈希函数组成,可以用来快速判断某个数据是否存在。

通过三个操作完成标记:

  • 使用N个哈希函数,分别计算这个数据的哈希值,得到N个哈希值
  • 把这N个哈希值对bit数组的长度取模,得到每个哈希值的位置
  • 把对应的位置的bit位设置为1

这样一来,即使发生缓存穿透,大量请求只会查询Redis和布隆过滤器。

第三种方案是,在请求入口的前端进行请求检测

例如对请求进行合法性检测,把恶意的请求(例如请求参数不合理、请求参数是非法值、请求字段不存在)直接过滤掉

总结

Redis缓存篇(四)缓存异常

另外还有三个建议:

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

参考资料

  • 25 | 缓存异常(上):如何解决缓存和数据库的数据不一致问题?
  • 26 | 缓存异常(下):如何解决缓存雪崩、击穿、穿透难题?


开心洋葱 , 版权所有丨如未注明 , 均为原创丨未经授权请勿修改 , 转载请注明Redis缓存篇(四)缓存异常
喜欢 (0)

您必须 登录 才能发表评论!

加载中……