查询数据的流程

要了解下面的内容,我们首先需要了解我们完整的查询操作是一个什么样点的流程.

我们通过下面的图来让大家更加清晰的了解:

了解完这个基本的数据流程之后,我们就可以继续来了解下面的内容了.

1.Redis的常见问题:

我们首先先来了解一下这三者分别代表了什么意思.

1.1-缓存穿透

缓存穿透指的是用户持续访问了一个数据库中根本就没有的数据,使得大量这样的访问直接怼到了数据库上,使得数据库最后直接崩掉.

这时候可能有朋友要问了,既然没有没有那为啥要查数据库呢?

别笑,可能还真有朋友会问,至少刚接触计算机时候的我可能还真会问.

我们是怎么知道数据库没有这条数据的呢,很明显是我们已经查询数据库之后才知道的,并且一般我们的查询都是对数据库中的数据进行全表查询之后再返回结果的,这种查询是特别消耗时间和性能的.

那么有人又要问了,既然都知道数据库里面没有这条数据了,那之后的请求为什么还要去查询数据库呢?

这里主要是因为第一次查询的时候,数据库里面没有这条数据,所以我们无法将数据填充到缓存中,缓存中没有,那么就只能再去数据库里面找了,主要问题就是出在下面红框内的步骤:

想想我们之前的操作,很明显都是数据库里面查出相应的数据之后,我们才把相应的数据存储到缓存中,那样我们之后才能直接读取缓存,然后返回我们的结果,但是数据库中都没有的数据显然缓存中肯定也没有,所以之后的请求就全部都怼到数据库上导致数据库的崩溃.

我们也可以通过下面的图来理解:

缓存穿透一般是黑客或不法分子利用Redis与数据库的数据漏洞进行 集中一点,连续攻击 ,从而使得我们的数据库服务直接崩溃的异常.

1.2-缓存击穿

缓存击穿指的是,由于各种原因导致Redis中的一个热点Key ( 目前访问人数较多的数据可以理解成 微博热搜 ) 失效了,这样突然大量的访问就直接又怼到了数据库上,导致数据库也是直接就崩掉了.

我们也可以通过下面的图来理解:

这种情况发生的原因有很多种,有可能是网络的原因,有可能是服务器本身的原因,也有可能是Redis本身服务的原因,反正原因多种多样.

其实这种问题可能是离我们生活最近的,就比方说 微博又炸了:

这种情况一般就是由于各种各样的原因,缓存中关于热搜的数据没了,没了没事, 只要现在访问该热搜的请求数量一般或者当前分批次的将这些请求分发过来也就没事了 ,但是想一想微博热搜的访问一般都是直接百万级别的,关键是这种请求又基本是 同一时间点怼到数据库上.

百万级别的请求直接怼到数据库上,这就好比马保国跟普通群众比赛一样,很明显就只有一个结果:

那肯定就是当场就歇逼了呗.

1.3-缓存雪崩

缓存雪崩指的是缓存中的 大量数据在同一个时间段内失效 ,导致大量对于这部分数据的访问直接怼到了数据库上,导致数据库直接就崩掉了.

我们也可以通过下面的图来理解:

这种情况一般都是因为设置的Redis中的缓存数据的过期时间是一样的,导致同一时间点大部分的缓存数据直接过期,这样对于这部分的数据访问肯定又是直接怼到数据库上了.数据库又崩了.

数据库只能说我好难,为什么都欺负我,嘤嘤嘤.

了解完三者的概念之后,我们可以横向对比一下三者: