缓存穿透

介绍

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案

有很多种方法可以有效地解决缓存穿透问题，最常见的则是：

通过布隆过滤器拦截，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

对空结果进行缓存，但是过期时间很短，不超过5分钟。如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存雪崩

介绍

缓存雪崩是指在设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕，大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层储存系统上。

在缓存的失效时间基础上增加一个随机值，比如1-5分钟，将缓存失效时间分散开，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存击穿

介绍

一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。

一个热点key（例如一个重要的新闻，一个热门的八卦新闻等等），所以这种key访问量可能非常大。

缓存的构建是需要一定时间的（可能是一个复杂计算，例如复杂的sql、多次IO、多个依赖、各种接口等等）。

以上两个问题同时出现，可能会对系统造成一个致命问题：在缓存失效的瞬间，有大量线程来构建缓存，造成后端负载加大，甚至可能会让系统崩溃 。

解决方案

使用互斥锁(mutex key)：只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了，如果是单机，可以用synchronized或者lock来处理，如果是分布式环境可以用分布式锁就可以了（如：可以用memcache的add, redis的setnx, zookeeper的添加节点操作）。

提前使用互斥锁(mutex key)：在value内部设置1个超时值(timeout1), timeout1比实际的超时间时间timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。

将key设置成永远不过期，可以设置缓存没有过期时间或将过期时间存在key对象的value里，如果发现要过期了，通过一个后台的异步线程进行缓存构建，更新值及过期时间。

资源保护，如hystrix，可以做资源的隔离保护主线程池

四种方案对比

一个并发量较大的互联网应用，目标有3个:

加快用户访问速度，提高用户体验。

降低后端负载，保证系统平稳。

保证数据“尽可能”及时更新(要不要完全一致，取决于业务，而不是技术)。

解决方案

解决方案优点缺点

简单分布式锁思路简单、保证一致性代码复杂度增大、存在死锁的风险、存在线程池阻塞的风险

加另外一个过期时间保证一致性代码复杂度增大、存在死锁的风险、存在线程池阻塞的风险

永远不过期异步构建缓存，不会阻塞线程池不保证一致性、代码复杂度增大(每个value都要维护一个timekey)、占用一定的内存空间(每个value都要维护一个timekey)

资源隔离组件hystrixhystrix技术成熟，有效保证后端、hystrix监控强大部分访问存在降级策略