缓存穿透
介绍
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能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) |
| 资源隔离组件hystrix | hystrix技术成熟，有效保证后端、hystrix监控强大 | 部分访问存在降级策略 |