解决方案： 方案一：加锁更新 一个并发访问量比较大的Key在某个时间过期，导致所有的请求直接打在DB上。
方案二：异步更新 查询缓存，发现缓存中不存在，加锁让其他线程等待，只让一个线程去更新缓存。
缓存穿透(二) 触发条件： 缓存设置为永不过期。通过异步的方式去更新缓存。后台开启另外一个守护线程，让其定时去更新缓存，但是这种实现相对复杂，难以把握。
解决方案： 方案一：设置默认值 查询缓存和数据库中都不存在的数据，这样每次请求直接打到数据库，就像缓存不存在一样，失去了缓存保护的作用。
方案二：添加布隆过滤器 为该数据设置一个默认值(可以为空值),之后访问缓存的时候，获取到这个默认值就知道数据库中数据为空，间接的保护了数据库。
但是可能会产生部分影响，例如：1.在缓存层保存默认值，又增加了内存消耗。2. 需要给该默认值设置过期时间。3. 因为缓存层和存储层的时间窗口不一致，导致影响业务。(当存储层的数据已经修改之后，但是缓存层的状态还没及时更新，导致在这个时间差内，用户访问不到。)
详细介绍见：大数据之布隆过滤器学习
缓存雪崩(三) 触发条件：解决方案： 方案一：提高缓存可用性 某一时刻发生大规模的缓存失效的情况，例如缓存服务器宕机、大量key在同一时间过期，这样的后果就是大量的请求直接打到DB上，可能导致整个系统的崩溃，成为雪崩。
方案二：过期时间 总共有两个思路，第一种是集群部署，避免单一节点出问题，导致整体雪崩。第二个思路是多级部署，不同级别设置不同的过期时间。
方案三：熔断降级 两种处理方案：针对热点数据，设置永不过期。对于普通数据，打散过期时间，随机设置不同的key的过期时间。
两种思路：在服务器当即或者连接超时的情况下，为防止出现雪崩，可以暂时停止业务服务访问缓存系统。或者可以舍弃一些非核心的请求，返回准备好的错误提示。
