首先，这三种情况的最终结果都是数据库性能受影响甚至是崩掉。具体详细原因看下面介绍：
一、数据雪崩
Redis缓存中大面积key失效，从而导致大量请求直接访问了数据库，大面积的缓存失效，打崩了 DB。
举例：
大量key同时过期，大面积失效，请求直接打到数据库。如果挂的是一个用户服务的库，那其他依赖他的库所有接口几乎都会报错。如果没做熔断等策略基本上就是瞬间挂一片的节奏。
解决：
对症下药，避免缓存中出现大量key同时失效的情况。
- 设置失效时间。批量往 Redis 存数据的时候，把每个 Key 的失效时间都加个随机值就好了，这样可以保证数据不会再同一时间大面积失效；setRedis（key, value, time+Math.random()*10000）;
- 热点数据均匀分布。如果 Redis 是集群部署，将热点数据均匀分布在不同的 Redis 库中也能避免全部失效。
- 取消设置热点数据有一个失效时间，用更新缓存代替。或者设置热点数据永不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就好了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。
二、数据穿透
缓存穿透：缓存和数据库中都没有的数据，而用户（黑客）不断发起请求。
例子
我们数据库的 id 都是从 1 自增的，如果发起 id=-1 的数据或者 id 特别大不存在的数据，这样的不断攻击导致数据库压力很大，严重会击垮数据库。
解决
- 增加校验。比如用户鉴权，参数做校验，不合法的校验直接 return，比如 id 做基础校验，id<=0 直接拦截；
- 布隆过滤器，判断出一个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。
三、数据击穿
缓存击穿是指一个 Key 非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个 Key 在失效的瞬间，持续的大并发直接落到了数据库上，就在这个 Key 的点上击穿了缓存。
- 设置热点数据永不过期；
- 或者加上互斥锁就搞定了
