9.缓存穿透、缓存雪崩、缓存并发

一、缓存穿透

缓存穿透：是指查询一个一定不存在的数据，由于缓存不命中，接着查询数据库也无法查询出结果，因此也不会写入到缓存中，这将会导致每个查询都会去请求数据库，造成缓存穿透。

解决方案：

1.布隆过滤
对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

2.缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

两种解决方案的比较：

---

二、缓存雪崩

缓存雪崩是指，由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

解决方案：

1.保证缓存层服务高可用性：
即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，比如 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2.依赖隔离组件为后端限流并降级：
在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
3.数据预热：
可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

---

三、缓存并发

在缓存更新或者过期的情况下，先获取锁，在进行更新或者从数据库中获取数据后，再释放锁，需要一定的时间等待，就可以从缓存中继续获取数据。

解决方法：

• 1、在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。
• 2、对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：
  事发前：实现Redis的高可用(主从架构+Sentinel（哨兵） 或者Redis Cluster（集群）)，尽量避免Redis挂掉这种情况发生。
  事发中：万一Redis真的挂了，我们可以设置本地缓存+限流，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
  事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。