针对基于缓存雪崩事前、事后三个层面的完美解决方案，考虑的比较完美的解决方案分为事前、事件中、事后三个层面考虑如何应对缓存雪崩的场景
我要再次强调，关于解决方案，这需要上下文。 本课程的方案基本上是根据本课程的缓存体系结构方案进行描述的
在下面的体系结构图中，我们将分析具体方案的内容
#在预先解决方案发生缓存雪崩之前，在事情之前，如何避免redis完全挂起？
redis本身的高可用性、复制、主从体系结构、主节点操作、读/写、到从节点的数据同步、主节点挂起后从节点会跟上
双室配置，redis cluster套装，部分机器在一个机房，其他机器在机房
另一种部署方法是在两个redis群集和两个redis群集之间同步数据。 redis集群可以在树结构中构建
这个方式不知道如何进行数据同步吗？
说到一个机房故障，至少另一个机房说有几个redis实例可以提供服务
#事件解决方案redis cluster完全崩溃，已经开始大量访问，无法访问redis
#ehcache本地缓存运行的多级缓存体系结构的作用发挥作用，ehcache的缓存应对数据从零散的redis中被删除的现象，另一个主要是防止redis完全崩溃
部署在多台计算机上的缓存服务实例的内存还提供了一组ehcache缓存，可以支持一段时间
#redis访问资源隔离使用hystrix隔离redis访问，以防止访问redis大量阻止您的资源
#对资源服务的访问限制和资源隔离是一样的，在避免自己的资源被资源服务大量屏蔽的同时，hystrix在资源隔离时也设置了限制
#事后解决方案redis数据可以恢复。 虽然已经描述了各种备份机制，但是由于redis数据的备份和恢复以及redis的重新启动，redis数据可能完全丢失或太旧。 快速缓存预热，redis重新启动在事件期间进行了限制和隔离，因此缓存服务不会被破坏，熔断和半打开策略可以自动恢复到redis
在总结了基于hystrix的高可用性服务这一技术之后，我们将讨论缓存服务是如何设计成高可用性体系结构的
高并发缓存雪崩缓存体系结构解决方案，基于hystrix保护缓存服务
带着大家实现有什么？ 事前和事后不用吧。 在事件中，ehcache本身也做了
基于hystrix保护对redis的访问，保护对源服务器的访问，在解释hystrix时，也论述了对源服务器的访问如何进行这种高可用性保护
但是，立场不同。 如果源服务器自身不知道是什么原因导致的故障，我们怎么保护？ 调用商品服务的接口报告大量错误、超时
总的来说，在流限制、资源隔离、降级保证缓存服务不能死的同时，快速恢复redis cluster