举个例子，假设每天高峰期的时候系统每秒请求是5000次，缓存在高峰期可以分担每秒4000次请求，另外1000次请求落到数据库（假设数据库每秒可承担2000次请求）。如果此时过来5000请求，但是redis因为某些原因挂掉了，缓存整个就不能用了，那么这5000个请求就全部落到数据库。显然数据库扛不住，直接崩溃。此时，如果没用什么特别的方案来处理这个故障，只是很着急的重启数据库，结果因为缓存还没数据，立马数据库又被新的流量给打死了。这就是缓存雪崩。
对于缓存雪崩主要分为事前事中事后，
事前：如果缓存不可用是因为缓存中的大部分数据集中失效，我们可以对缓存的失效时间加上一个随机值，使失效时间分散一点，尽量避免集中失效。另外如果是因为别的原因redis宕机导致缓存不可用，这时候我们就需要提前做好Redis高可用的架构，如主从+哨兵或redis cluster，来避免Redis出现故障时整个缓存不可用，全盘崩溃。
事中：可以将一小部分数据同样缓存到本地ehcache（本地缓存组件）缓存，另外加上hystrix限流&降级组件，避免MySQL被打死。
事后：如果真的发生雪崩，我们还可以用redis的RDB或AOF重启redis快速从磁盘加载缓存数据。这就需要我们提前打开Redis持久化机制，在雪崩发生的事后快速恢复缓存数据，一旦重启从磁盘中恢复数据到内存。
另外一个问题，缓存穿透，一般是黑客恶意攻击，或是自己系统出bug。例如黑客恶意伪造请求，这些请求都是数据库根本查不到的，所以缓存中也没用，那这些大量的恶意请求都会落到数据库去查询，数据库不就挂了吗？
解决办法就是
1、只要从数据库没查到，就写入一个空值到缓存里去。
2、使用布隆过滤器对请求的key进行一层过滤，过滤掉系统认为不存在不合法的key。
可以参考之前的这篇文章，
谈谈缓存+数据库双写不一致问题可以参考之前的这篇文章，
《【面试突击】—Redis篇》就要结束了，暂时就整理这么多，如果你还有更多的可以告诉我来补充哦
本系列文章在于面试突击，不是教程，要是细挖能讲好多，而面试你只需要把这个原理说出来就行了，如果边讲边画图那就更好了。
该系列文章在于快速突击，快速拾遗，温习。