大厂面试Redis：缓存雪崩、缓存穿透、缓存击穿

最新推荐文章于 2024-04-02 19:58:02 发布

左耳君

最新推荐文章于 2024-04-02 19:58:02 发布

阅读量199

点赞数

分类专栏： Java基础 Redis 文章标签：缓存面试 redis

本文链接：https://blog.csdn.net/chengxukong/article/details/124544454

版权

Java基础同时被 2 个专栏收录

76 篇文章 3 订阅

订阅专栏

Redis

15 篇文章 0 订阅

订阅专栏

在这里插入图片描述

眼光不错，小伙子，看到这篇文章了就血赚，这篇文章绝对让你学到开心，这是面试的杀器，其实Redis这个东西吧，我个人认为，真的真的很强大，但是呢，又感觉被吹得有点过头了

不过人家也确实有这个资本，人家性能强大，使用操作也很简单，有提供了各种持久化手段来解决断电丢失的问题，而且人家读写速度都是大几万每秒，甚至十几万的速度，性能强大而且使用简单，所以绝大多数的公司都会使用Redis

于是乎，Redis的面试的优先级也是被大大的提高了，而Redis中的经典的缓存的各种问题，也是成为了程序员的必备技能之一

缓存雪崩、缓存穿透和缓存击穿都是属于比较典型的问题，当然这篇文章就是为了给大家解释清楚这三者到底是怎么回事，还有一般情况下如何来解决相应的问题，当然这篇也没有什么很特殊的厉害的法子，相应的法子估计百度也是一大堆

在这里插入图片描述

不过呢，相见既缘分，你看到这篇文章了，我当然要给亲爱的大家准备一篇最齐全的解决法子咯，帮助大家真正的了解并学会解决这些问题

缓存雪崩

雪崩，这个词听着就很糟糕，可能很多人已经猜到了个大概了，这指的就是大面积的缓存集体失效

举个典型的例子，在写入本文的时候，比如马上到618的时候，就会很快迎来了一波大促销，大抢购，就是因为访问量特别的高，所以要把这些商品都放在缓存中提高效率，假设这一个页面的数据都缓存了一个小时，那么到了凌晨一点钟的时候，这些商品的缓存就都会过期了，而对这批商品的访问，就都落在了DB上，这样DB就会很容易崩溃

当一点的时候每秒八千个请求，本来缓存可以挺住五千每秒的请求，但是当缓存突然失效的时候，这每秒八千的请求直接全都打在DB上，数据库直接就扛不住了，没准直接就挂了，此时如果没用什么特别的方案来处理这个故障，DBA也容易崩溃，重启数据库，但是会立即被下面的流量打崩

这就是我个人理解的缓存雪崩

同一时间的缓存大面试失效，对于线上的情况来说，应该会是一个灾难，如果你这么做了，恭喜你，埋下了一个大雷，你想想啊，如果DB直接崩了，那意味着用户可能要开始***了，这个时候用户都是熬夜熬了很久等着购买自己心爱的产品呢，结果你软件崩了，啥也买不了了

什么，连我辛苦好几天抢的券都不能用了，什么破软件，卸载，再也不用了，如果真出现这样的场景，收拾东西吧

说的不错，这是个大问题，那一般这种情况该如何处理呢，你都是如何应对的

其实处理这个也很简单了，在批量的往Redis中放置数据的时候，把每个key的失效时间都加个相应的随机值即可

在这里插入图片描述

这样就可以避免大面积的缓存数据在同一时间失效这个问题，公司一般使用Redis都是集群部署的，这样将热点数据均匀分布在不同的Redis库中也可以避免全部失效的问题，失效时间设为随机有时候也是一种不错的策略

或者设置热点数据永远不过期，有更新操作就直接更新缓存就好了，看到数据A的缓存过期了，再重新缓存下，数据B的缓存过期了，再重新缓存下B，这样也可以刷下缓存就好了

缓存穿透和缓存击穿

我们先来说下缓存穿透，缓存穿透指的是缓存和数据库都没有的数据，然而用户却不断的发起请求，这样的很可能是就是属于恶意请求

举个例子，我们数据库的ID都是自增上去的，如果发起者的ID为-1的情况，或者ID不存在的特别大的情况，这时候的用户很可能是攻击者，造成数据库的攻击压力会变得很大，严重的可能会导致直接打崩DB

其实这种情况，程序员一般会对这种恶意情况进行过滤，但是万一有漏洞呢，万一有程序员忘记了对参数进行校验，这种情况如果一直用小于0的参数去请求你，每次都能绕开Redis直接打到DB，数据库查不到，每次都这样，并发高点可能就会容易搞崩，一些小的单机系统，基本上用postman可能就能打崩

至于缓存击穿吗，这个和缓存雪崩有点像，但是肯定也是有不一样的地方，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿指的是一个Key非常热点，比如之前的某爽这种事情，占用公共资源的眼球，人们都去喷，此时这个Key就是一个大热点，在不停的扛着大并发，大并发集中的对这一个点进行访问

当这个key在失效的那一瞬间，也就是某爽的这个key突然失效了，持续的大并发就会直接穿破缓存，直接将请求打到DB，就像是在一个完好无损的桶上凿开了一个洞

那该如何解决呢，缓存穿透和击穿这两种情况

缓存穿透吗，这个是程序员必须要做的防备之一，接口层的校验，比如参数的校验、用户的鉴权行为这种，对于那些不合法的请求直接return或者报错就好了

我们在开发的时候，不仅要把用户的行为各种猜测，我们还要做的是提防各种恶意请求，我们要对程序的各个接口有一颗不信任的心，这个不信任指的是对于参数的各种情况、对于用户行为的多方面考虑，因为你不能确定来的请求一定是正常的，不能保证调用方一定是正常的调用方，所以一定要对那些非正常的调用方进行一定的校验和处理

在这里插入图片描述

缓存穿透这种需要在代码中根据业务的实际情况来做出相应的控制，对不符合条件的请求做出相应的过滤，这应该属于做基本的要求之一，如果这种情况真出现在生产上，那肯定属于T1级别的重大Bug了

我们常用的法子就是先从缓存中取数据，如果缓存中取不到就直接通过数据库来取数据，如果取不到，我们可以将key和value都是null写入到缓存中，设置一定的时间，可以有效的防止恶意用户反复用同一个ID来暴力攻击，其实我们也可以在网关层做出相应的控制，因为用户不可能在短时间内做出大量的多次请求的，当出现非正常频率的请求的IP或者机器的时候，可以对这些IP和机器进行限制

缓存击穿这种问题，其实最简单的办法就是设置缓存永不过期就好了，这应该是最简单粗暴的方法了，或者通过互斥锁也是可以解决这种