当前位置: 首页 > 图灵资讯 > 技术篇> 探讨生产环境下缓存雪崩的几种场景及解决方案

探讨生产环境下缓存雪崩的几种场景及解决方案

来源:图灵教育
时间:2023-05-29 13:55:46

本文首发自「慕课网」,想了解更多IT干货,程序员圈热闻,欢迎关注“慕课网”或慕课网微信官方账号!

作者:大能 | 慕课网讲师


我们经常使用缓存,但有时我们忽略了缓存中的一些问题。从生产环境应用的角度来看,我们将考虑一些需要注意的异常情况,特别是在高并发的情况下,如何保证数据的准确性和系统的稳定性,同时提供高性能的支持。

探讨生产环境下缓存雪崩的几种场景及解决方案_数据

首先,让我们来看看第一个问题。让我们看看这张图片。我们在这里引入缓存的目的是帮助数据库阻止大多数读取请求,从而提高读取请求的响应速度和并发性能力。然而,如果由于各种原因,缓存数据在一段时间内消失,此时,所有这些读取请求都直接落在数据库上,如果此时并发量很大,它很可能会压垮数据库,基本上整个应用程序都会被拖垮。更严重的是,它会引起一系列的连锁反应,影响上下游系统。

探讨生产环境下缓存雪崩的几种场景及解决方案_数据_02

缓存雪崩在生产过程中的几种情况

然后,让我们总结一下这个问题:由于缓存数据故障(或不存在),大量的读取请求直接访问数据库,拖累数据库甚至应用程序。这就是缓存雪崩的问题。然后我们可以看到,这里问题的关键是大量的缓存数据故障(或不存在)。一般来说,这些情况主要发生在生产过程中,可能导致缓存雪崩问题:

情况一:

第一种情况可能是我们没有提前预设缓存,也可能有缓存,但是写入redis Redis服务异常重启,数据尚未到来和持久,因此在这种情况下可能导致缓存数据丢失。虽然Redis提供了持久性机制,但RDB和RDB两种持久性模式AOF,没有办法100%保证数据不丢失。事实上,在实际的战斗项目中,为了减少对中间部件的依赖,降低运维成本,或者提高Redis的性能,许多系统不打开Redis的持久机制,所以当Redis重启时,所有缓存数据都清空了。

探讨生产环境下缓存雪崩的几种场景及解决方案_数据_03

情况二:

另一种情况是提前设置缓存,但缓存的过期时间设置过于集中,导致大量数据同时过期。因此,当我们使用redis时,我们不得不考虑这种情况。以一年一度的双十一购物节为例。如果马上就要到双十一零点了,很快就会出现抢购浪潮。假设缓存一小时,这一波商品时间集中在缓存中。所以到了凌晨一点,这批商品的缓存就过期了。这些商品的访问和查询都落在数据库上。对于数据库来说,会有周期性的压力峰值。如果没有好的处理方案,数据库可能无法承受缓存失效时的压力,导致其他相关系统被拖累,最终导致整个系统崩溃。这种情况就是我们常说的缓存雪崩。想象一下,如果这种情况发生在双十一,会有多严重。因此,我们必须提前考虑和设计这种情况。

探讨生产环境下缓存雪崩的几种场景及解决方案_缓存_04

情况三:

最后,我们都知道,为了确保更高的成本性能,缓存空间容量必须小于后端数据库的总数据量。随着缓存数据量的增加,缓存空间将不可避免地被填充。此时,redis将有一个缓存数据的淘汰机制。如果我们的缓存淘汰机制不是很合理,我们将大面积淘汰正在使用的缓存,这将导致上述问题。

探讨生产环境下缓存雪崩的几种场景及解决方案_数据库_05

Redis的缓存淘汰策略是指当Redis用于缓存内存不足时, 怎么处理

在这里,我们来看看redis的两个参数。我们可以通过设置maxmemory参数来设置内存的最大使用量(配置)和maxmemory-policy参数:选择相应的内存淘汰规则(配置)。 当内存不够时, 内存淘汰规则将设置

其中在Redis 淘汰规则如下

规则

规则说明

noeviction

当内存不足以容纳新写入的数据时, 新写入操作会报错

allkeys-lru

当内存不足以容纳新数据时, 在键空间, 移除最近最少使用的key

allkeys-random

当内存不足以容纳新数据时, 在键空间, 随机删除key

volatile-lru

当内存不足以容纳新数据时, 在设置过期时间的键空间中, 移除最近最少使用的key

allkeys-random

当内存不足以容纳新数据时, 在键空间, 随机删除key

volatile-ttl

当内存不足以容纳新数据时, 在设置过期时间的键空间中, 过期时间较早的key优先移除

鉴于这种情况,我们可以结合项目的实际情况,通过指定适当的消除规则,避免有效的缓存数据丢失,这只能稍微缓解,如果应用缓存数据非常大,这次可以扩大集群部署规模,增加整个缓存组件的容量。

缓存雪崩的几种解决方案

那么以上就是三种主要的缓存失效容易导致缓存雪崩的情况。

接下来,让我们来看看缓存雪崩的几个常见解决方案:

首先,结合业务的特点和场景,从业务的角度来看,我们来看看有哪些优化方法。 :

对于上述缓存集中失效的场景,我们可以用这个想法来缓解:

缓存失效时间分散
  1. 分散缓存故障时间。首先,我们可以采用不同的分类商品来缓存不同的周期。在同一类别中添加一个随机因素。这是尽可能多的过期时间分散缓存,而且,热门类商品缓存时间较长,冷门类商品缓存时间较短,还可以节省缓存服务资源。

在生产环境中探讨缓存雪崩的场景和解决方案_数据库_06'

不设置热门数据过期时间

2.流行数据不设置过期时间。我们可以设置一些流行商家和流行商品的数据,即系统中最流行的数据,这些数据永远不会过期。这可以确保这部分需求量大的数据总是可以从缓存中获取数据

探讨生产环境下缓存雪崩的几种场景及解决方案_缓存_07

提前预热缓存数据

3.另一种策略是提前预热缓存数据。什么是缓存预热?缓存预热是指在系统启动或系统运行期间定期将部分缓存数据直接加载到缓存系统中,以避免在用户要求时查询数据库,然后将数据重写到缓存中。因此,该策略不仅适用于上述系统中最热门的数据,也适用于在系统有营销活动时提前预热相关数据,以避免在活动开始时瞬间涌入的流量冲走系统。

探讨生产环境下缓存雪崩的几种场景及解决方案_缓存_08

所以缓存预热的想法一般是这样的:

当数据量不大时,我们可以在项目启动时加载缓存;如果数据量相对较大,可以在运行过程中通过定期任务脚本刷新缓存;重点是确保热数据能够提前加载到缓存。

好吧,这些策略是从业务角度结合业务场景优化的策略。然而,仅仅依靠这些策略只能起到缓解的作用,还不足以完全保证我们系统的稳定性。我们仍然需要通过技术手段来保证。除了上述扩大集群规模以解决容量不足的问题外,我们主要关注缓存故障以及如何通过技术手段防止系统雪崩问题

  1. 首先,我们可以处理数据库访问增加限流 ,保护我们的数据库和系统的核心资源。与缓存组件不同,数据库不善于处理高并发场景,其能承载的并发量远小于缓存中间件, 如果您将访问缓存的所有请求都连接到数据库,您将在几分钟内崩溃数据库,并通过流量限制慢慢响应系统,则最好直接拖动系统。
  2. 还有一种方法,我们可以进行缓存降级。因此,缓存降级是指缓存故障或缓存服务器挂断时,不访问数据库,直接返回默认数据,以避免数据库的巨大压力。当然,降级通常会损害用户体验,因此尽量减少降级对业务的影响。

通过上述方法,基本上可以避免雪崩问题的缓存。谢谢你。


欢迎关注「慕课网」在官方账号中,我们将始终坚持提供IT圈的优质内容,分享干货知识,共同成长!

本文原创发布于慕课网。 ,请注明转载来源,谢谢合作