首页 > 代码库 > 缓存雪崩问题

缓存雪崩问题

一、什么是缓存雪崩

      从下图可以很清晰出什么是缓存雪崩:

      1. 由于Cache层承载着大量请求,有效的保护了Storage层(通常认为此层抗压能力稍弱),所以Storage的调用量实际很低,所以它很爽。技术分享

      2. 但是,如果Cache层由于某些原因(宕机、cache服务挂了或者不响应了)整体crash掉了,也就意味着所有的请求都会达到Storage层,所有Storage的调用量会暴增,所以它有点扛不住了,甚至也会挂掉 技术分享

 

雪崩问题在国外叫做:stampeding herd(奔逃的野牛),指的的cache crash后,流量会像奔逃的野牛一样,打向后端

 

      技术分享

    二、 缓存雪崩的危害

       

           雪崩的危害显而易见,通常来讲可能很久以前storage已经扛不住大量请求了,于是加了cache层,所以雪崩会使得storage压力山大,甚至是挂掉。   

 

    三、如何预防缓存雪崩

   

    1. 保证Cache服务高可用性:

        和飞机都有多个引擎一样,如果我们的cache也是高可用的,即使个别实例挂掉了,影响不会很大(主从切换或者可能会有部分流量到了后端),实现自动化运维。例如:下载

 

     memcache的一致性hash:

     技术分享

     redis的sentinel和cluster机制:

     技术分享技术分享

     

    

    


 

  2. 依赖隔离组件为后端限流:下载

      其实无论是cache或者是mysql, hbase, 甚至别人的API,都会出现问题,我们可以将这些视同为资源,作为并发量较大的系统,假如有一个资源不可访问了,即使设置了超时时间,依然会hang住所有线程,造成其他资源和接口也不可以访问。

      相信大家一定遇到过这样的页面:这些应该就是淘宝的降级策略。

       技术分享
       

       降级在高并发系统中是非常正常的:比如推荐服务中,很多都是个性化的需求,假如个性化需求不能提供服务了,可以降级补充热点数据,不至于造成前端页面是个大空白(开了天窗了)

       在实际项目中,我们对重要的资源都进行隔离,比如hbase, elasticsearch, zookeeper, redis,别人的api(可能是http, rpc),让每种资源都单独运行在自己的线程池中,即使资源出现了问题,对其他服务没有影响。

       但是线程池如何管理,比如如何关闭资源池,开启资源池,资源池阀值管理,这些做起来还是相当麻烦的,幸好netfilx公司提供了一个很牛逼的工具:hystrix,可以做各种资源的线程池隔离。下载


        hystrix附图:

       技术分享技术分享技术分享

3. 提前演练:

   在项目上线前,通过演练,观察cache crash后,整体系统和storage的负载, 提前做好预案。


缓存雪崩问题