缓存常见问题

缓存常见问题

缓存穿透

情况：
在流量大时，如果有人利用不存在的key频繁去访问我们的应用，可能会导致数据库挂掉。
原因：
查询一个不存在的数据，由于缓存是不命中时被动写入，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
解决方案：
1、布隆过滤器:将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
2、如果一个查询的数据为空（不管是数据不存在还是系统故障），我们仍然把这个空的结果进行缓存，但它的过期时间会很短，最长不让他超过五分钟。

缓存击穿

情况：
如电商中的主打产品“热卖爆款”的关键字，被大量并发访问,这时这个key的缓存失效了的瞬间，大量请求通过这个key可以访问到数据库。
原因：
一个key可能在某些时间点被超高的并发访问，是一种非常“热点”的数据。当这个key在失效的瞬间，持续的高并发就会击穿缓存，直接请求到数据库（相当于把缓存屏障凿开了一个洞，大量请求直接访问数据库。）
解决方案：
1、简单分布式互斥锁（mutex key）
是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。
2、“提前”使用互斥锁
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。
3、不过期
Redis 不设置过期时间，或者把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建。
4、资源隔离组件hystrix
采用netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可。

缓存雪崩

情况：
缓存由于某些原因（比如 宕机、cache服务挂了或者不响应）整体crash掉了，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。
原因：
缓存在某一时刻同时失效，请求全部转发到数据库，数据库瞬时压力过重雪崩。
解决方案：
1、大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。
2、就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。