缓存雪崩、击穿、穿透及解决方案_保证缓存和数据库一致性

缓存雪崩、击穿、穿透

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

使用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，则说明不存在

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

更新数据时，如何保证数据库和缓存的一致性？

1. 先更新数据库？先更新缓存？

在数据更新时，先更新数据库还是先更新缓存，都会存在并发问题，当两个请求并发更新同一条数据时，可能会出现缓存和数据库中数据不一致的现象。

解决方案

• 更新缓存之前加分布式锁，保证同一时间只运行一个请求更新缓存，但对写入性能造成影响
• 更新完缓存后，给缓存加上较短的过期时间，即使不一致，但也会很快过期

2. Cache Aside策略

旁路缓存策略： 在更新数据时，不更新缓存，更新数据库，删除缓存， 当读取数据发现缓存中无该数据时，再从数据库中读取数据，并且写入缓存。

（删除缓存，不更新缓存是懒加载思想的应用）

分为读策略、写策略

• 写策略
  • 更新数据库中的数据
  • 删除缓存中的数据
• 读策略
  • 若读取的数据命中缓存，则直接返回数据
  • 若读取的数据没有命中缓存，则从数据库中读取数据，再将该数据写入缓存，并且返回给用户

例：请求A读取数据，请求B更新数据

此时数据库中为21，缓存中为20

该情况出现概率不高，因为缓存的写入通常远远快于数据库的写入

① 先更新数据库，再删除缓存

故 先更新数据库，再删除缓存 可以保证“数据一致性”，并且对缓存加上过期时间，可以保证最终一致性

问题：

• 先更新数据库，再删除缓存会导致缓存命中率降低。

  ​ 若对缓存命中率有要求，可以采用更新数据库+更新缓存，解决方案见1.

• 这种方法保证数据一致性的前提是 更新数据库和删除缓存都能正常执行成功。

  （删除缓存失败时，可能出现缓存中为旧数据，数据库中为新数据）

  保证更新数据库、删除缓存都执行成功

  采用异步缓存，保证第二个操作执行成功

  • 重试机制 => 引入消息队列，将删除缓存操作的数据加入消息队列，由消费者操作数据
    • 如果删除缓存失败，从消息队列重新读取需要删除的数据，再次删除缓存（若多次删除失败，需要向业务层发送报错信息）
    • 如果删除缓存成功，把数据从消息队列移除，避免重复操作
  • 订阅 MySQL binlog，再操作缓存
    • 先更新数据库，再删除缓存，当更新数据库成功，就会产生一条变更日志，记录在binlog里。于是可以订阅binlog日志，拿到具体要操作的数据，再执行缓存删除。
    • Canal模拟MySQL的主从复制的交互协议，把自己伪装成从节点，向MySQL主节点发送dump请求，MySQL收到请求后，推送binlog给Canal，Canal解析Binlog字节流后，转换为便于读取的结构化数据，供下游程序订阅使用
      • 

② 先删除缓存，再更新数据库

出现并发问题，造成缓存、数据库数据不一致

解决方案

延迟双删

1. 删除缓存
2. 更新数据库
3. 睡眠
4. 再删除缓存

请求A在睡眠时，B能够完成读取数据库数据，并把缺失数据写入缓存，A睡眠完后删除缓存。

请求A的睡眠时间 > 请求B的从数据库读取数据+写入缓存的时间

该方案尽可能保持一致性，建议采用先更新数据库，再删除缓存

互斥锁vs分布式锁

互斥锁：单机情况下，内存中的一个互斥锁就能控制一个程序的线程并发
分布式锁：适用于分布式场景，集群架构，需要“全局锁”实现控制多个程序/多个机器上的线程并发

小林coding图解Redis — 七