前言

我们一般的系统，在达到一定QPS之后，都会启用缓存来抗压。而大部分缓存解决方案都是用的redis。
Redis具有简单，稳定，数据可持久化等特点。得到了很多公司的实际应用。
使用Redis 在达到一定的业务场景的时候，就会出现我们经常在面试中遇到的关于缓存的几个问题。
缓存预热，缓存穿透，缓存击穿，缓存雪崩

一、缓存预热

直面意思上来说，以APP作为例子。就是在用户还没打开我们APP之前。就已经把数据库里面的热点数据放入到缓存中了。这样用户在进入APP的时候，请求的是缓存的里面的记录。这样就极大的减少了对于数据库的压力。造成缓存击穿

实际场景: 我们有一款APP，每次准点会推送一些PUSH消息。这样很多用户在1分钟之内大量进入APP，导致并发量瞬间突增。如果所有的瞬时流量全部集中到数据库中，会导致系统整体压力非常大。所以这个时候在用户进去之前必须对首页的数据进行缓存预热。这样再大的压力也只会集中打到服务器和Redis上面。

总结:缓存预热就是提前给用户准备好饭菜。用户进系统不用等待(等待数据库查询)，直接就能开吃

二、缓存穿透

假如我们认为缓存是一堵墙，然后墙后面是我们的数据库。我们在业务场景中，对于热点数据应该要做到所有的请求都打在这堵墙上，对于数据库尽量减少请求。缓存穿透的意思就是绕过了这堵墙，访问了在缓存中一定查询不到的数据，这样就会把所有的请求打到数据库，从而造成了数据库的压力。

实际场景：我们对于用户ID，针对每个用户ID，每请求一次会对用户信息生成一个缓存，缓存key值就是用户的ID值。但是当我们把用户ID换成-1进行请求，因为我们的用户ID肯定是会大于0的，所以如果有这样的请求，我们在缓存里面铁定查不到这条数据。就会把所有的请求打到数据里面，造成一次查询，增加数据库压力。

解决方案:针对数据库查询为空的数据，也进行缓存。缓存时间设置小点。或者设置边界值。上述场景 针对ID小于0的请求，直接报错，不让请求。

三、缓存击穿

假如我们认为缓存是一堵墙，然后墙后面是我们的数据库。击穿直面意思就是把墙的某一点打穿了。那这个点肯定是热点数据。由于这个key一直被大量请求。突然这个缓存失效了，一下子就会把大量的压力给到了数据库。造成系统崩溃。

实际场景：微博热搜就是这样的一个真实场景，随时随地都会有大量的请求在微博热搜上面。如果这个时候微博热搜缓存突然失效。这个时候所有压力都在数据库上面，就会造成数据库压力突增，系统崩溃。

解决方案:针对热点数据永不过期。热点数据只能我们去替换。让其永不过期。

四、缓存雪崩

假如我们认为缓存是一堵墙，然后墙后面是我们的数据库。然后每块砖是一个缓存key。假定用户每进行一次请求。我们会生成一次缓存。添一块砖。这样下次请求的压力也是在砖上。但由于我们缓存是有过期时间的。如果突然所有的砖在同一时刻全部崩塌。那这个时候一瞬间所有的请求又都会在数据库上面。造成数据库压力过大崩溃。

实际场景:在商品抢购，一波商品时间比较集中的放入缓存中，假设缓存设置一个小时，当过期时间到达后，这批商品会统一失效，而对于这批商品的访问查询，会直接落到数据库上，对于数据库而言，就会产生周期性的压力波峰，甚至会造成数据库宕掉。

**解决方案:
1 针对key值设置随机过期时间，避免key值集中某一时间批量失效。
2 redis灾备。防止使用中redis主机崩溃导致系统崩溃
3 服务降级 优先提供核心服务**