高并发高可用复杂系统中的缓存架构(二十四) 缓存雪崩及处理

什么是缓存雪崩？

简单说：由于缓存不可用，导致大量请求访问后端服务，可能 mysql 扛不住高并发而打死， 像滚雪球一样，影响越来越大，最后导致整个网站崩溃不可用

至于为什么会像滚雪球一样？整个与整个系统的架构有关；

1. redis 集群彻底崩溃：不可用

2. 缓存服务在请求 redis 时，会有大量的线程阻塞，占用资源

3. 超时请求失败之后，会去 mysql 查询原始数据，mysql 抗不住，被打死

4. 源头服务由于 mysql 被打死，对源服务的请求也被阻塞，占用资源

5. 缓存服务大量的资源全部耗费在访问 redis 和 源服务上；最后自己被拖死，无法提供服务

6. nginx 无法访问缓存服务，只能基于本地缓存提供服务，当缓存过期后，就耗费在访问缓存服务上

7. 最后整个网站崩溃，页面加载不出来任何数据

以下是这个流程的一个图解

如何解决呢？

相对来说，考虑的比较完善的一套方案，分为事前、事中、事后三个层次去思考再怎么来应对缓存雪崩的场景

对于解决方案，这个需要有上下文的，本次介绍的基于本课程的缓存架构方案来讲解的

通过下面的架构图，来分析具体的方案内容

 

事前解决方案

发生缓存雪崩之前，事情之前，怎么去避免 redis 彻底挂掉

1. redis本身的高可用性、复制、主从架构，操作主节点，读写，数据同步到从节点，一旦主节点挂掉，从节点跟上

2. 双机房部署，一套 redis cluster，部分机器在一个机房，另一部分机器在另外一个机房

3. 还有一种部署方式，两套 redis cluster，两套 redis cluster 之间做一个数据的同步，redis 集群是可以搭建成树状的结构的

    

   一旦说单个机房出了故障，至少说另外一个机房还能有些 redis 实例提供服务

事中解决方案

redis cluster 已经彻底崩溃了，已经开始大量的访问无法访问到 redis 了

ehcache 本地缓存

所做的多级缓存架构的作用上了 ，ehcache 的缓存应对零散的 redis 中数据被清除掉的现象，另外一个主要是预防 redis 彻底崩溃

多台机器上部署的缓存服务实例的内存中，还有一套 ehcache 的缓存，还能支撑一阵

对 redis 访问的资源隔离

对 redis 访问使用 hystrix 进行隔离，防止自己资源大量阻塞在访问 redis 上

对源服务访问的限流以及资源隔离

同上，防止自己资源大量阻塞在访问源服务上，同时 hystrix 在资源隔离时也做到了限流

事后解决方案

1. redis 数据可以恢复，之前讲解过各种备份机制，redis 数据备份和恢复，redis 重新启动起来

2. redis 数据彻底丢失了或者数据过旧，快速缓存预热，redis 重新启动起来

由于事中做了限流与隔离，缓存服务不会被打死，通过熔断策略 和 half-open 策略， 可以自动可以恢复对 redis 的访问，发现 redis 可以访问了，就自动恢复了

小结

基于 hystrix 的高可用服务这块技术之后，先讲解缓存服务如何设计成高可用的架构

缓存架构应对高并发下的缓存雪崩的解决方案，基于 hystrix 去做缓存服务的保护

要带着大家去实现的有什么东西？事前和事后不用了吧，事中 ehcache 本身也做好了

基于 hystrix 对 redis 的访问进行保护，对源服务的访问进行保护，讲解 hystrix 的时候， 也说过对源服务的访问怎么怎么进行这种高可用的保护

但是站的角度不同，源服务如果自己本身不知道什么原因出了故障，我们怎么去保护，调用商品服务的接口大量的报错、超时

总的来说就是：限流、资源隔离、降级 保证缓存服务不能死掉，同时快速恢复 redis cluster

 

缓存雪崩处理

1. 事前

   redis 高可用性，redis cluster、sentinal、复制、主从，从->主，双机房部署

2. 事中

   ehcache 可以抗一抗，redis 挂掉之后的资源隔离、超时控制、熔断，商品服务的访问限流、多级降级，缓存服务在雪崩场景下存活下来，基于 ehcache 和存活的商品服务提供数据

3. 事后

   快速恢复 Redis，备份+恢复，快速的缓存预热的方案