缓存雪崩效应 - 《dev.note》

正常情况，Cache 层承载了大量请求，所以 Storage 的请求调用量很低。

如果 Cache 层 crash 掉了，如：宕机了、cache 服务挂了或不响应了。这意味着所有的请求都会到达 Storage 层。Storage 的调用量会暴增，极可能扛不住，可能会挂掉。

国外开发者，称之为 stampeding herd，指 cache crash 后，流量会像奔逃的野牛一样，打向后端。

Cache 为了，就是帮助 Storage 扛住大量请求，从而防止 Storage 出现挂掉。缓存雪崩，Storage 也会阴大量的请求而挂掉。

a. 保证 Cache 服务高可用性

和飞机有多个引擎一样，cache 也可以实现主从服务。主实例挂掉，切换到从实例。可能会有部分流量到了后端。

1）memcache 的一致性 hash
2）redis sentine 和 cluster 机制

b. 依赖隔离组件为后端限流

cache、mysql、hbase、第三方 API，都会出问题。这些都是资源。
作为并发量大的系统，有一个资源不可访问了，即使设置超时时间。也会堵塞住所有线程，造成其他资源和接口也不可访问。

降级处理

降级处理，在高并发系统中很常见。比如推荐服务，多是个性化的需求，假如个性化需求无法提供服务了，可以降级，补充热点数据。

重要资源互相隔离

让每种资源都单独运行在自己的线程池中。比如 hbase, elasticsearch, zookeeper, redis, 第三方 API，各自运行在自己的线程池中。~~即使资源出现问题，对其它服务没影响。（？？这里是有问题的，什么资源出问题。）~~

netflix 公司提供了一个工具 hystrix，可以做各种资源的线程池隔离。

c. 提前演练

项目上线前，先演练，Cache crash 后，观察整个系统和 Storage 的负载情况如何。提前做好预案。

缓存中的某条数据失效了，如何防止高并发访问量，进入到 DB 呢？