关于redis的雪崩、穿透、击穿问题

雪崩

1、我们先了解一下雪崩是什么？

但是假设我们现在有5000个请求，我们的缓存能抗住4000条请求，我们的数据库能抗住2000个请求，本来挺美好的，这个时候可恶的清洁阿姨突然踢掉了我们缓存机的电源线…我们的缓存宕机了，这个时候5000个请求全部打在我们的数据库，那我们的数据库肯定也要挂了…
正常的访问应该是这样：

然后我们的的缓存挂了

2、 我们如何应对？

道高一尺，魔高一丈，既然我们的雪崩是缓存宕机后发生的，这是一场意外，我们肯定要想法子解决

• 提前预防：我们的redis是高可用的，通过主从+哨兵，redis cluster，这样一来，我们的一个redis崩盘了，我们还有我们的redis集群。
• 意外抢救：如果还是宕机了，我们就赶紧使用本地ehcache缓存+hystrix限流&降级，避免我们的Mysql被打死。
• 事后：redis持久化，我们的redis一旦重启，会自动从磁盘上加载数据，恢复我们缓存的数据

当用户发送一个请求，系统A收到后会先 查询本地的ehcache，如果没有查到再去查我们的redis，如果都没有，才会去查我们的数据库，之后将查到的数据写入到ehcahe和redis中

限流组件
我们可以设置每秒的请求，有多少能够通过组件，剩余未通过的请求，我呢让它走降级，可以设置默认返回一些数据，或者返回一个友情提示。

好处总结：

• 数据库绝对不会挂掉，我们的限流确保了每秒最多能有多少请求能通过。
• 只要我们的数据库没有挂，针对这个例子来说，至少2/5的请求都可以被处理
• 那么我们的数据库没有挂，系统就没有崩盘，对用户来说，只需要多刷新几次，稍微等待即可。

穿透

1、什么是缓存穿透？

假设一个系统A，每秒5000个请求，但是有4000是黑客的恶意攻击，这个黑客发出的4000个请求，在我们的缓存中查不到，数据库也没有。比如我们的系统是一个电商，他发送的4000个数据都是去查飞机大炮，那么这样的话，我们的数据库根本没有，缓存中就根本不可能有，这4000条数据直接跳过我们的缓存，每次都是直接查询数据库，我们的数据库扛不住4000条请求，必然就崩了

2、如何应对？

我们作为开发人员，肯定不能眼巴巴看着人家这么攻击我们的系统，解决的方法也很简单，它查询数据库没有查到，那我们就放一个空值到缓存中，然后设置一个过期时间，那它接下来的操作，肯定就需要和缓存打交道了。

击穿

1、什么是击穿？

缓存击穿，就是说某个Key非常热门，比如我们微博的头条，访问他非常频繁，处于集中式高并发的访问情况，那么我们这个key如果突然过期，这个请求就立即击穿我们的缓存，打在数据库上。

2、解决方案

我们的解决方式也很简单，我们可以设置这个热点信息为永不过时，或者基于redis zookeeper实现互斥锁，等待我们之前的请求构建了缓存之后，就释放锁，其他的请求才能通过key访问数据。