阿里面试Redis最常问的三个问题：缓存雪崩、击穿、穿透（带答案）.docxVIP

阿里面试Redis最常问的三个问题：缓存雪崩、击穿、穿透（带答案） 2021-03-14 那提到Redis我信任各位在面试，或者实际开发过程中对缓存雪崩，穿透，击穿也不生疏吧，就算没遇到过但是你确定听过，那三者到底有什么区分，我们又应当怎样去防止这样的情况发生呢，我们有请下一位受害者。 面试开头 一个大腹便便，穿着格子衬衣的中年男子，拿着一个满是划痕的mac向你走来，看着快秃顶的头发，心想着确定是尼玛顶级架构师吧！但是我们腹有诗书气自华，虚都不虚。 小伙子我看你的简历上写到了Redis，那么我们直接开门见山，直接怼常见的几个大问题，Redis雪崩了解么？ 帅气诱人的面试官您好，我了解的，目前电商首页以及热点数据都会去做缓存 ，一般缓存都是定时任务去刷新，或者是查不到之后去更新的，定时任务刷新就有一个问题。 举个简约的例子：假如全部首页的Key失效时间都是12小时，半夜12点刷新的，我零点有个秒宰活动大量用户涌入，假设当时每秒 6000 个恳求，原来缓存在可以扛住每秒 5000 个恳求，但是缓存当时全部的Key都失效了。此时 1 秒 6000 个恳求全部落数据库，数据库必定扛不住，它会报一下警，真实情况可能DBA都没反应过来就直接挂了。此时，假如没用什么特殊的方案来处理这个毛病，DBA 很焦急，重启数据库，但是数据库立马又被新的流量给打死了。这就是我理解的缓存雪崩。 我刻意看了下我做过的项目感觉再吊的都不允许这么大的QPS直接打DB去，不过没慢SQL加上分库，大表分表可能还还算能顶，但是跟用了Redis的差距还是很大。 同一时间大面积失效，那一霎时Redis跟没有一样，那这个数量级别的恳求直接打到数据库几乎是灾难性的，你想想假如打挂的是一个用户服务的库，那其他依靠他的库全部的接口几乎都会报错，假如没做熔断等策略基本上就是霎时挂一片的节拍，你怎样重启用户都会把你打挂，等你能重启的时候，用户早就睡觉去了，并且对你的产品得到了决心，什么垃圾产品。 面试官摸了摸本人的头发，嗯还不错，那这种情况咋整？你都是怎样去应对的？ 处理缓存雪崩简约，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效，我信任，Redis这点流量还是顶得住的。 setRedis（Key，value，time + Math.random() * 10000）； 假如Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避开全部失效的问题，不过本渣我在生产环境中操作集群的时候，单个服务都是对应的单个Redis分片，是为了便利数据的管理，但是也同样有了可能会失效这样的弊端，失效时间随机是个好策略。 或者设置热点数据永久不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。 那你了解缓存穿透和击穿么，可以说说他们跟雪崩的区分么？ 嗯，了解，我先说一下缓存穿透吧，缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起恳求，我们数据库的 id 都是1开头自增上去的，如发起为id值为 -1 的数据或 id 为特殊大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严峻会击垮数据库。 小点的单机系统，基本上用postman就能搞死，比如我本人买的阿里云服务。 像这种你假如不对参数做校验，数据库id都是大于0的，我一直用小于0的参数去恳求你，每次都能绕开Redis直接打到数据库，数据库也查不到，每次都这样，并发高点就简约崩掉了。 至于缓存击穿嘛，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是由于大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key格外热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的霎时，持续的大并发就穿破缓存，直接恳求数据库，就像在一个完好无损的桶上凿开了一个洞。 面试官显露欣慰的眼光，那他们分别怎样处理 缓存穿透我会在接口层添加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id =0的直接拦截等。 这里我想提的一点就是，我们在开发程序的时候都要有一颗“不信任”的心，就是不要信任任何调用方，比如你供应了API接口出去，你有这几个参数，那我觉得作为被调用方，任何可能的参数情况都应当被考虑到，做校验，由于你不信任调用你的人，你不晓得他会传什么参数给你。 举个简约的例子，你这个接口是分页查询的，但是你没对分页参数的大小做限制，调用的人万逐一口气查 Integer.MAX_VALUE 一次恳求就要你几秒，多几个并发你不就挂了么？是公司同事调用还好大不了发觉了改掉，但是假如是黑客或者竞争对手呢