雪崩
比如电商系统首页等会放在redis中的数据
若过期时间设置为同一时间 那么 也会同一时间过期 所以会导致过期时间到的那一刻 假设有6000个请求到首页，那么DB必然扛不住，挂掉maybe ，重启数据库又被新的流量给打死了。
这就是一个雪崩场景。
比如崩的是一个用户系统，那么依赖于用户的模块也会报错，如果没有做熔断，那么需要重启服务，就丢失了使用人群。
解决办法：
1 给redis 设置随机失效时间
2 给redis 不加过期时间，更新数据时更新缓存
3 redis 集群部署，将热点数据均匀分布在不同的redis库中也可以避免全部失效的问题。--需要实践
击穿
一个高可用的key 过期时 扛不住高并发的请求 导致的DB死了
解决办法：
- 设置永不失效
- 互斥锁（可以用redission分布式锁）
穿透
指的是缓存中和DB中都没有的数据 一直被请求 比如自增主键的表 ，恶意发起id=-1的请求
存和数据库中都没有的数据，而用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。
解决办法：
- 接口层添加id <= -1的判断 直接return
- 数据都没有取到，可以给对应redis的key的value设置为null，过期时间设置为30s（时间过长会导致正常情况也无法使用）-- 这样可以防止攻击用户反复用同一个id暴力攻击，但是我们要知道正常用户是不会在单秒内发起这么多次请求的，那网关层Nginx本渣我也记得有配置项，可以让运维大大对单个IP每秒访问次数超出阈值的IP都拉黑。——需要实践
- redis 高级用法
布隆过滤器（Bloom Filter）利用算法快速判断DB中输否存在数据，存在则访问反之return
最后继续给你们做个小的技术总结：
一般避免以上情况发生我们从三个时间段去分析下：
事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL 被打死。
事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
上面的几点我会在吊打系列Redis篇全部讲一下这个月应该可以吧Redis更完，限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空白的值。
好处：
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。 只要数据库不死，就是说，对用户来说，3/5 的请求都是可以被处理的。 只要有 3/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。
这个在目前主流的互联网大厂里面是最常见的，你是不是好奇，某明星爆出什么事情，你发现你去微博怎么刷都空白界面，但是有的人又直接进了，你多刷几次也出来了，现在知道了吧，那是做了降级，牺牲部分用户的体验换来服务器的安全。
