相对来说，考虑的比较完善的一套方案，分为事前，事中，事后三个层次去思考怎么来应对缓存雪崩的场景
1、事前解决方案
发生缓存雪崩之前，事情之前，怎么去避免redis彻底挂掉
redis本身的高可用性，复制，主从架构，操作主节点，读写，数据同步到从节点，一旦主节点挂掉，从节点跟上双机房部署，一套redis cluster，部分机器在一个机房，另一部分机器在另外一个机房还有一种部署方式，两套、redis cluster，两套redis cluster之间做一个数据的同步，
redis集群是可以搭建成树状的结构的。
一旦说单个机房出了故障，至少说另外一个机房还能有些redis实例提供服务。
2、事中解决方案
redis cluster已经彻底崩溃了，已经开始大量的访问无法访问到redis了
（1）ehcache本地缓存
所做的多级缓存架构的作用上了，ehcache、的缓存，应对零散的redis中数据被清除掉的现象，另外一个主要是预防redis彻底崩溃，多台机器上部署的缓存服务实例的内存中，还有一套
ehcache的缓存ehcache的缓存还能支撑一阵
（2）对redis访问的资源隔离
（3）对源服务访问的限流以及资源隔离
3、事后解决方案
（1）redis数据可以恢复，做了备份，redis数据备份和恢复，redis重新启动起来
（2）redis数据彻底丢失了，或者数据过旧，快速缓存预热，redis重新启动起来
redis对外提供服务
缓存服务里，熔断策略，自动可以恢复，half-open，发现redis可以访问了，自动恢复了，自动就继续去访问redis了。
基于hystrix的高可用服务这块技术之后，先讲解缓存服务如何设计成高可用的架构。
缓存架构应对高并发下的缓存雪崩的解决方案，基于hystrix去做缓存服务的保护。
事中，ehcache本身也做好了
基于hystrix对redis的访问进行保护，对源服务的访问进行保护，讲解hystrix的时候，也说过对源服务的访问怎么怎么进行这种高可用的保护
但是站的角度不同，源服务如果自己本身不知道什么原因出了故障，我们怎么去保护，调用商品服务的接口大量的报错、超时限流，资源隔离，降级
