面试噩梦之redis击穿、穿透、雪崩

前言

最近经历了一场面试，通过这场面试，让我深深的认识了自己的菜！

---

所以我决定先redis开始，慢慢的开始加强学习，同时我看到了一篇比较通俗易懂的文章，想通过文章，加上自己的见解，来学习一下redis击穿、穿透、雪崩。

一、redis击穿

解释：

击穿，顾名思义，就是穿了一个大洞，而redis的击穿指的并不是将redis击穿，而指的是，redis查询某个热点key，这个key突然失效的时候，所有的请求都会跳过redis这道屏障去查询DB，导致DB瘫痪的现象，就叫redis击穿。

场景：

某一秒，有5000个请求进来，要查询一条热点的信息，但是redis中的热点信息突然失效了，那么这一秒的时间内，5000信息就会直接穿过redis，直接去查询DB，导致DB不堪重负，宕机了，这就是redis击穿。

如何解决：

1：简单粗暴的方法：设置这个热点key，永不失效。（但是一般的系统，热点key都是会变得，所以这种方法简单粗暴，但是不是长久之际）。

2：比较复杂的方法：通过添加锁得方式，使第一个请求，去DB中查询，其他用户进行睡眠，等第一个请求将查询得结果加载到redis中（但是如果查询得这个线程挂掉，那就会导致死锁）。

3：比较复杂的方法：请求查询热点key的时候，发现不存在，则对setnx一个key，并且设置一个过期时间，这个key表示一把锁，然后只有一个请求可以设置成功，其他的请求，发现这把锁以后，要sleep一会，等第一个请求把key带回来后，其他请求再去访问（为什么要给key设置时间呢？其实是防止第一个请求设置锁以后，查询过程中挂掉了，所以为了防止形成死锁，所以要设置一个时间）

二、redis穿透

解释：

redis的穿透，就是指请求进来后去查询redis，但是redis查询不到，紧接着又去数据库查，结果数据库也查询不到，查询的太多，最终导致数据库被搞宕机。

场景：

对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。

黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。

举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

如何解决：

解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

三、redis雪崩

解释：

redis的雪崩，指的是因为redis突然出现的事故，导致请求直接打到了DB中，倒是DB不堪重负，挂掉。

场景：

对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。

缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。
此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。

如何解决：

1：redis高可用：这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

2：限流降级：这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

上面redis击穿、穿透、雪崩，如果有什么不对的地方，希望大家可以指出来，谢谢。

参考文章
什么是 redis 的雪崩、穿透和击穿？