缓存雪崩、击穿、穿透

一般用户数据存储于磁盘，读写速度慢。

使用redis作为缓存，相当于数据缓存在内存，大大提高系统性能

redis作为缓存，就会有缓存异常的三个问题

1.缓存雪崩

缓存都设置了过期时间

造成缓存雪崩

• 大量缓存数据在同一时间过期

• redis故障宕机

  若此时有大量用户请求，无法在redis处理，都直接访问数据库 => 数据库压力骤增（严重造成数据库宕机） => 形成一系列连锁反应 => 整个系统崩溃

解决缓存雪崩

=> 大量缓存数据在同一时间过期时：

1. 均匀设置过期时间（对缓存数据的过期时间加上随机数，保证数据不会在同一时间过期）

2. 互斥锁（当业务线程在处理用户请求时，如果发现访问的数据不在redis里，加互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到redis），当缓存构建完成后，再释放锁。）
   注：互斥锁设置超时时间，否则若出现请求发生意外阻塞，导致其他请求也一直拿不到锁

3. 后台更新缓存（让缓存“永久有效”，将更新缓存的工作交由后台线程定时更新）
   当系统内存紧张时，有些缓存数据被“淘汰”，在“淘汰”和下次更新时间内，业务线程读取失败就以为是数据丢失，解决方法：

   1. 后台线程负责定时更新缓存，同时频繁地检测缓存是否失效，若失效，可进行构建缓存

      ​ 检测时间间隔不能太长，太长导致用户获取的数据是空值而不是真正的数据，检测时间间隔最好是毫秒级，用户体验一般

   2. 业务线程发现缓存数据失效后，通过消息队列发送一条消息通知后台线程更新缓存。后台线程收到消息后，更新前判断缓存是否存在，不存在则进行构建缓存。

      ​ 缓存更新及时，用户体验好

   **注：**后台更新缓存机制适合进行缓存预热（业务刚上线时，提前缓存数据，不是等待用户访问才来触发缓存构建）

=> Redis故障宕机时：

1. 服务熔断或请求限流机制

   ​ 服务熔断：暂停业务应用对缓存服务的访问，直接返回错误，不再继续访问数据库，直到redis恢复正常。

   ​ 请求限流机制：只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到Redis恢复正常 并把缓存预热完后。

2. 构建redis缓存高可靠集群

   ​ 通过主从节点的方式构建，若redis缓存的主节点宕机，从节点可以切换成为主节点，继续提供缓存服务

2. 缓存击穿

造成缓存击穿

被频繁访问的热点数据过期，此时大量的请求访问该热点数据，直接访问数据库，数据库很容易被高并发的请求冲垮

缓存击穿可以认为是缓存雪崩的一个子集（对应于大量缓存数据在同一时间过期）

解决缓存击穿

1. 互斥锁
2. 不给热点数据设置过期时间，由后台异步更新缓存 / 在热点数据准备过期前，提前通知后台线程更新缓存以及重新设置过期时间

3.缓存穿透

对于缓存雪崩、击穿，数据仍然在数据库，一旦缓存恢复相应的数据，就可以减轻数据库的压力

而对于缓存穿透：

​ 用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库，发现数据库也没有要访问的数据，没办法构建缓存来服务后续请求。当有大量的这样的请求时，数据库的压力骤增

造成缓存穿透

• 业务误操作，缓存中数据和数据库数据都被误删除
• 黑客恶意攻击，故意大量访问某些读取不存在数据的业务

解决缓存穿透

1. 非法请求的限制

   判断请求参数是否含有非法值？请求字段是否存在？

2. 缓存空值或默认值

   当线上业务发现缓存穿透时，针对查询的数据，在缓存中设置一个空值或默认值，后续请求可以从缓存中读取到数据，而不会继续查询数据库

3. 使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在。

   写入数据库数据时，使用布隆过滤器做标记，当业务线程确认缓存失效后，可以通过查询布隆过滤器判断数据是否存在。（大量请求只会查询布隆过滤器和redis，而不会查询数据库）

注：布隆过滤器的实现

设此时有3个哈希函数，位图数组长度为8，数据库写入数据x：

将该数据x得到的三个哈希值 % 位图数据长度得到三个数组下标，填入1。

当业务线程查询数据是否存在于数据库时，查询 1、4、6下标的值是否为1，若有一个为0，则说明不存在

（存在哈希冲突，故若查询布隆过滤器说数据存在于数据库，此时数据不一定在数据库；但是查询到数据不存在时，数据一定不存在）

小林coding图解Redis — 七