17.亿级流量电商详情页系统实战---缓存雪崩问题以及解决方案

缓存雪崩

雪崩的原因和现象

缓存雪崩，不是单指redis集群崩溃，宕机，而是说整个缓存服务体系（包括缓存服务，redis集群、缓存服务中的本地缓存、数据源）

1、redis集群彻底崩溃
2、缓存服务大量对redis的请求hang住，占用资源
3、缓存服务大量的请求打到源头服务去查询mysql，直接打死mysql
4、源头服务因为mysql被打死也崩溃，对源服务的请求也hang住，占用资源
5、缓存服务大量的资源全部耗费在访问redis和源服务无果，最后自己被拖死，无法提供服务
6、nginx无法访问缓存服务，redis和源服务，只能基于本地缓存提供服务，但是缓存过期后，没有数据提供

行业里真实的缓存雪崩的经验和教训

某电商，之前就是出现过，整个缓存的集群彻底崩溃了，因为主要是集群本身的bug，导致自己把自己给弄死了，虽然当时也是部署了双机房的，但是还是死了

电商大量的，几乎所有的应用都是基于那个缓存集群去开发的

导致各种服务的线程资源全部被耗尽，然后用在了访问那个缓存集群时的等待、超时和报错上了

然后导致各种服务就没有资源对外提供服务咯

然后各种降级措施也没做好，直接就是整体系统的全盘崩溃

导致网站就没法对外出售商品咯，导致了很大数额的经济的损失

缓存的几大问题

1.缓存一致性
2.缓存失效规则
3.缓存穿透
4.缓存崩溃
5.热点缓存
6.缓存预热，预热的时候，并发冲突问题，例如之前学的多个storm实例计算出不同的热点商品集合，如何让多节点部署的缓存服务，并发预热
7.缓存数据恢复和备份
8.缓存高可用

解决方案

1、事前解决方案

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

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重新启动起来
(2.1)快速预热时的并发问题

redis对外提供服务

缓存服务里，熔断策略，自动可以恢复，half-open，发现redis可以访问了，自动恢复了，自动就继续去访问redis了

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

基于Hystrix 对缓存数据和源数据访问，做资源隔离