Redis的缓存击穿，穿透，雪崩总结

一·缓存击穿

       1·出现分析

        日常生产中，我们知道数据的请求路径是从客户端出发，先查询缓存中是否存在，如果有直接返回，若没有则会把请求打入DB，进而查询出所需要的数据，如下图

但是此时便会出现一种情况，如果我们请求量非常的多，高并发时，缓存的存在就是为了提高数据的查询速度，减轻DB的很多负担，当大量请求涌入，并且缓存中没有的时候，所有的请求全部进入到了DB，此时便会出现直接击穿缓存的情形，数据库便会直接崩溃。

        2·解决方案：

       在缓存失效后，通过加锁或者队列来控制读和写数据库的线程数量。比如：对某个key只允许一个线程查询数据和写缓存，其他线程等待，如果加设一个互斥锁，可以保证线程之间不会互相影响，不会因为某一个线程获取了锁，其它线程就处于等待时间，也就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据。

二·缓存穿透

        1·出现分析：

       在使用redis缓存的时候，我们通常会通过一个key去获取对应的value，如果这个这个key一定不存在value的话，便会去DB中查询，当访问量大量请求，缓存便会被穿透，直接访问到DB，此时便会让服务器宕机，尤其是在原本知道缓存必定不存在对应的数据，强行发送大量请求的时候，便会出现缓存穿透！

        2·解决方案：

       1> 其实首先我们可以考虑使用布隆过滤器，将所有可能存在的数据通过哈希算法存放进一个足够大的set中，当数据不存在的时候便会被拦截掉，从避免了对底层存储系统的查询压力。这个方法的缺点时没有办法删除掉存入的比特值。
        2> 如果一个查询返回的数据为空，不管是数据不存在还是系统故障，我们仍然把这个结果进行缓存，但是此时对他进行加设时间，这样定时删除，便会不会穿透缓存了。

三·缓存雪崩

         1·出现分析：

        因为缓存层承载了大量的请求，有效的保护了存储 层，但是如果缓存由于某些原因，整体不能够提供服务，于是所有的请求，就会到达存储层，存储层的调用量就会暴增，造成存储层也会挂掉的情况，在开发中的场景可能是：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，大量数据会去直接访问DB，此时给DB很大的压力。
        2·解决方案：

（1）设置redis集群和DB集群的高可用，如果redis出现宕机情况，可以立即由别的机器顶替上来。这样可以防止一部分的风险。

（2）使用互斥锁，在缓存失效后，通过加锁或者队列来控制读和写数据库的线程数量。比如：对某个key只允许一个线程查询数据和写缓存，其他线程等待。

（3）不同的key,可以设置不同的过期时间，让缓存失效的时间点不一致，尽量达到平均分布。

（4）redis中设置永久不过期，这样就保证了，不会出现热点问题，也就是物理上不过期。