redis-缓存雪崩
数据未加载到缓存中，或者缓存同一时间大面积失效，从而导致所有请求都去查数据库，导致数据库cpu和内存负载过高，甚至宕机。
一个雪崩的简单过程
- redis集群大面积故障
- 缓存失效，但依然大量请求访问缓存服务redis
- redis大量失效后，大量请求转向到mysql数据库
- mysql的调用量暴增，很快就扛不住了，甚至直接宕机
- 由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各个服务器集群的雪崩，最后网站彻底崩溃
如何预防
缓存的高可用性
缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如redis sentinel和redis cluster都实现了高可用
缓存降级
可以利用ehcache等本地缓存（暂时支持），但主要还是对源服务访问进行限流、资源隔离（熔断）、降级等。
当访问量剧增，访问出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。
降级的最终目的是保证核心服务可用，即使是有损的。
敌人推荐服务中，很多都是个性化的需求，假如个性化需求不能提供服务了，可以降级补充热点数据，不至于前端页面是个空白。
在进行降级之前要对系统进行梳理，比如：哪些业务是核心（必须保证），哪些业务可以允许暂时不提供服务（利用静态页面替换）等，以及配合服务器核心指标，然后设置整体预案，比如：
- 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级
- 警告：有些服务在一段时间内成功率有波动，可以自动降级或人工降级，并发送警告
- 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阈值，此时可以根据情况自动或者人工降级
- 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级
备份和快速预热
- redis数据备份和回复
- 快速缓存预热
提前演练
建议在项目上线前，演练缓存宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题
