缓存穿透
介绍
一般的缓存系统，都是按照key值去缓存查询，如果不存在对应的value，就应该去DB中查找 。这个时候，如果请求的并发量很大，就会对后端的DB系统造成很大的压力。这就叫做缓存穿透。关键词：缓存value为空；并发量很大去访问DB。
原因：
1.业务自身代码或数据出现问题；
2.一些恶意攻击、爬虫造成大量空的命中，此时会对数据库造成很大压力。
解决办法：
0，再web服务器启动时，提前将有可能被频繁并发访问的数据写入缓存。
1，设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉；或者 规范key的命名，并且统一缓存查询和写入的入口。这样，在入口处，对key的规范进行检查，一旦恶意的key将会被拦截，从避免了对底层存储系统的查询压力。
2，如果一个查询返回的数据为空，不管是数据不存在还是系统故障，我们仍然把这个结果进行缓存，但是它的过期时间会很短，最长不超过5分钟（即定期清理数据为空的键值对）。
3，synchronized双重检测机制，这时我们就需要使用同步（Synchronized）机制，在同步代码块前查询一下缓存是否存在对应的key（haskey()），然后同步代码块里面再次查询缓存里是否有要查询的key。 这样“双重检测”的目的，还是避免并发场景下导致的没有意义的数据库的访问（也是一种严格避免穿透的方案）。
雪崩
介绍
因为缓存层承载了大量的请求，有效的保护了存储 层，但是如果缓存由于某些原因，整体不能够提供服务，于是所有的请求，就会到达存储层，存储层的调用量就会暴增，造成存储层也会挂掉的情况。缓存雪崩的英文解释是奔逃的野牛，指的是缓存层当掉之后，并发流量会像奔腾的野牛一样，大量后端存储。
存在这种问题的一个场景是：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，大量数据会去直接访问DB，此时给DB很大的压力。
解决办法
（1），设置redis集群和DB集群的高可用，如果redis出现宕机情况，可以立即由别的机器顶替上来。这样可以防止一部分的风险。
（2）使用互斥锁
在缓存失效后，通过加锁或者队列来控制读和写数据库的线程数量。比如：对某个key只允许一个线程查询数据和写缓存，其他线程等待。单机的话，可以使用synchronized或者lock来解决，如果是分布式环境，可以是用redis的setnx命令来解决。
（3）不同的key,可以设置不同的过期时间，让缓存失效的时间点不一致，尽量达到平均分布。
（4）redis中设置永久不过期，这样就保证了，不会出现热点问题，也就是物理上不过期。
（5）使用netflix的hystrix，可以做各种资源的线程池隔离，从而保护主线程池。
代码案列：
https://github.com/hlchengzi/springboot/tree/master/spring-redis
