Redis-缓存穿透、缓存雪崩、缓存击穿等

最新推荐文章于 2024-10-21 19:03:54 发布

JH丶C

最新推荐文章于 2024-10-21 19:03:54 发布

阅读量174

点赞数 1

分类专栏： Redis 文章标签： redis

原文链接：https://www.cnblogs.com/wandoupeas/p/redis_problems.html

版权

Redis 专栏收录该内容

4 篇文章

订阅专栏

1、缓存流程

在这里插入图片描述程序在处理请求时，会先从缓存中进行查询，如果缓存中没有对应的key，则会从数据库中查询，如果查询到结果，并将查询结果添加到缓存中去，反之不缓存。流程就不多解释了，基于这个我们展开下面的问题。

2、缓存穿透

2.1 原因

当查询一个一定不存在的key时，由于不能命中缓存，所以要查询数据库，但是这个key又不存在，所以查询不到结果，不会缓存。于是就有了利用这种一定不存在的key作为查询条件，对系统进行攻击，增加数据库压力，这种现象称为缓存穿透。

解决方法

1、布隆过滤
首先要规范key的命名，对不规范的key直接过滤掉，并对所有可能的key以hash形式存储到一个足够大的bitmap中，不存在的数据会被此bitmap拦截，以避免查询数据库。
2、缓存空对象
意思很简单，就是对返回数据为空的情况也进行缓存，并设置一个很短的过期时间，这样也能起缓解作用。但是这也会产生下面两个问题：
缓存空对象意味着需要更多的存储空间，可再缩短缓存时间，过期自动剔除
导致缓存与数据库不一致，比如某个key:a查询时还没有数据，这时会缓存空值，但是其他某个流程已走完，数据已添加到了数据库中，这时访问依旧会返回空值，因为缓存还没过期，所以解决方法就是增删改时也进行缓存的刷新

3、缓存雪崩

3.1 产生原因

当大批量缓存集中在同一时间内失效（或者redis宕机），产生大量缓存穿透，此时又有请求并发袭来，查询压力瞬间都落在了数据库上，此时就产生了缓存雪崩。

1、redis集群大面积故障

2、缓存失效，但依然大量请求访问缓存服务redis

3、redis大量失效后，大量请求转向到mysql数据库

4、mysql的调用量暴增，很快就扛不住了，甚至直接宕机

5、由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各服务器集群的雪崩，最后网站彻底崩溃。`

3.2 解决方法

1、失效时间加随机值
给缓存失效时间加一个随机值，避免集体失效
2、实现redis高可用
通过对redis实现集群搭建来避免部分机器宕机导致redis不可用的情况
Redis Sentinel 和 Redis Cluster都实现了高可用
3、分布式锁或分布式队列
保证缓存单线程写，并在没有获取锁的线程中一直轮询缓存，直到超时
4、Redis备份和快速预热
1)Redis数据备份和恢复

2)快速缓存预热

3).提前演练

5、缓存降级
可以利用ehcache等本地缓存(暂时使用)，但主要还需要对源服务访问进行限流、资源隔离(熔断)、降级等。
当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。

降级的最终目的是保证核心服务可用，即使是有损的。

比如我的淘宝页面，由于是非核心页面，后端服务如果暂时不能提供使用的情况，可以考虑直接使用一个静态页面替换掉，这样对于用户也是永远提供服务的状态(再发报警信息提示急需解决)，也不至于出现空白或者异常错误的裸奔状态。

在进行降级之前要对系统进行梳理，比如：哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体预案，比如：

(1)一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级;

(2)警告：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警;

(3)错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级;

(4)严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

最后，建议还是在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题。