缓存穿透、缓存击穿和缓存雪崩原因+解决方案

最新推荐文章于 2023-07-06 17:21:30 发布

MayMatrix

最新推荐文章于 2023-07-06 17:21:30 发布

阅读量406

点赞数

分类专栏：缓存技术架构设计高并发、多线程

原文链接：https://www.cnblogs.com/xichji/p/11286443.html

版权

高并发、多线程同时被 3 个专栏收录

62 篇文章 0 订阅

订阅专栏

缓存技术

30 篇文章 2 订阅

订阅专栏

架构设计

28 篇文章 3 订阅

订阅专栏

REDIS缓存穿透，缓存击穿，缓存雪崩原因+解决方案

一、前言

在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。

为了克服上述的问题，项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。

redis技术就是NoSQL技术中的一种，但是引入redis又有可能出现缓存穿透，缓存击穿，缓存雪崩等问题。本文就对这三种问题进行较深入剖析。

二、初认识

缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
缓存击穿：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

三、缓存穿透解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

粗暴方式伪代码：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";

    String cacheValue = CacheHelper.Get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    }

    cacheValue = CacheHelper.Get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    } else {
        //数据库查询不到，为空
        cacheValue = GetProductListFromDB();
        if (cacheValue == null) {
            //如果发现为空，设置个默认值，也缓存起来
            cacheValue = string.Empty;
        }
        CacheHelper.Add(cacheKey, cacheValue, cacheTime);
        return cacheValue;
    }
}

四、缓存击穿解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

使用互斥锁(mutex key)

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。

public String get(key) {
      String value = redis.get(key);
      if (value == null) { //代表缓存值过期
          //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
      if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
               value = db.get(key);
                      redis.set(key, value, expire_secs);
                      redis.del(key_mutex);
              } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
                      sleep(50);
                      get(key);  //重试
              }
          } else {
              return value;      
          }
 }

memcache代码：

if (memcache.get(key) == null) {  
    // 3 min timeout to avoid mutex holder crash  
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {  
        value = db.get(key);  
        memcache.set(key, value);  
        memcache.delete(key_mutex);  
    } else {  
        sleep(50);  
        retry();  
    }  
}

其它方案：待各位补充。

五、缓存雪崩解决方案

与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。

缓存正常从Redis中获取，示意图如下：
redis1.md

缓存失效瞬间示意图如下：
redis2.md

缓存失效时的雪崩效应对底层系统的冲击非常可怕！大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

加锁排队，伪代码如下：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";
    String lockKey = cacheKey;

    String cacheValue = CacheHelper.get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    } else {
        synchronized(lockKey) {
            cacheValue = CacheHelper.get(cacheKey);
            if (cacheValue != null) {
                return cacheValue;
            } else {
              //这里一般是sql查询数据
                cacheValue = GetProductListFromDB(); 
                CacheHelper.Add(cacheKey, cacheValue, cacheTime);
            }
        }
        return cacheValue;
    }
}

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法！

注意：加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！

随机值伪代码：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";
    //缓存标记
    String cacheSign = cacheKey + "_sign";

    String sign = CacheHelper.Get(cacheSign);
    //获取缓存值
    String cacheValue = CacheHelper.Get(cacheKey);
    if (sign != null) {
        return cacheValue; //未过期，直接返回
    } else {
        CacheHelper.Add(cacheSign, "1", cacheTime);
        ThreadPool.QueueUserWorkItem((arg) -> {
      //这里一般是 sql查询数据
            cacheValue = GetProductListFromDB(); 
          //日期设缓存时间的2倍，用于脏读
          CacheHelper.Add(cacheKey, cacheValue, cacheTime * 2);                 
        });
        return cacheValue;
    }
}

解释说明：

缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存；
缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。

关于缓存崩溃的解决方法，这里提出了三种方案：使用锁或队列、设置过期标志更新缓存、为key设置不同的缓存失效时间，还有一种被称为“二级缓存”的解决方法。

六、小结

针对业务系统，永远都是具体情况具体分析，没有最好，只有最合适。

于缓存其它问题，缓存满了和数据丢失等问题，大伙可自行学习。最后也提一下三个词LRU、RDB、AOF，通常我们采用LRU策略处理溢出，Redis的RDB和AOF持久化策略来保证一定情况下的数据安全。

快速了解缓存穿透与缓存雪崩

缓存穿透

DB承受了没有必要的查询流量.

缓存系统，一般流程都是按照key去查询缓存，如果不存在对应的value，就去后端系统（例如：持久层数据库）查找。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力，这就叫做缓存穿透。

缓存击穿

热点Key，大量并发读请求引起的小雪崩.

在高并发下，对一个特定的值进行查询，但是这个时候缓存正好过期了，缓存没有命中，导致大量请求直接落到数据库上，如活动系统里面查询活动信息，但是在活动进行过程中活动缓存突然过期了。

正常请求：

快速了解缓存穿透与缓存雪崩

正常请求

缓存击穿时：

快速了解缓存穿透与缓存雪崩

缓存击穿-如何避免

1. 缓存空结果

对查询结果为空的情况进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。

2. 布隆过滤器

采用布隆过滤器，guava有实现api，或者使用redis的bitmap。将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。布隆过滤器对于固定的数据可以起到很好的效果，但是对于频繁更新的数据，布隆过滤器的构建会面临很多问题。另外布隆过滤器是有判断误差的，网上有很多详细的介绍，请读者自行搜索即可。

快速了解缓存穿透与缓存雪崩

布隆过滤器

缓存雪崩

缓存设置同一过期时间，引起的DB洪峰.

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

如何避免

1. 互斥锁

在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

快速了解缓存穿透与缓存雪崩

互斥锁

如果是单机，可以用synchronized或者lock来处理，如果是分布式环境就需要使用分布式锁。

使用互斥锁，代码如下，仅适用redis2.6.1以后支持setnx的版本。在缓存失效的时候(判断拿出来的值为空)，不是立即去load db，而是先使用redis的setnx操作去set一个mutex key。当操作返回成功时，再进行load db的操作并回设缓存，否则，就重试整个get缓存的方法。

快速了解缓存穿透与缓存雪崩

互斥锁

public String get(key) {
 List<String> resultList = (List<String>)redisTemplate.opsForValue().get(key);
 if(CollectionUtils.isEmpty(resultList)){
 final String mutexKey = key + "_lock";
 boolean isLock = (Boolean) redisTemplate.execute(new RedisCallback() {
 @Override
 public Object doInRedis(RedisConnection connection) throws DataAccessException {
 //只在键key不存在的情况下，将键key的值设置为value,若键key已经存在，则 SETNX 命令不做任何动作
 //命令在设置成功时返回 1 ， 设置失败时返回 0
 return connection.setNX(mutexKey.getBytes(),"1".getBytes());
 }
 });
 if(isLock){
 //设置成1秒过期
 redisTemplate.expire(mutexKey, 1000, TimeUnit.MILLISECONDS);
 resultList = getValueBySql(key);
 redisTemplate.opsForValue().set(key, resultList, 1000, TimeUnit.SECONDS);
 redisTemplate.delete(mutexKey);
 }else{
 //线程休息50毫秒后重试
 Thread.sleep(50);
 retryCount--;
 System.out.println("=====进行重试，当前次数:" + retryCount);
 if(retryCount == 0){
 System.out.println("====这里发邮件或者记录下获取不到数据的日志，并为key设置一个空置防止重复获取");
 List<String> list = Lists.newArrayList("no find");
 redisTemplate.opsForValue().set(key, list, 1000, TimeUnit.SECONDS);
 return list;
 }
 return getCacheSave2(key,retryCount);
 }
 }
 return resultList;
}

2. 设置随机过期时间

不同的key，设置不同的过期时间，让缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低。

3. 设置二级缓存

做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期

4. “永远不过期”

“永远不过期”包含两层意思：

从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
从功能上看，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期。

快速了解缓存穿透与缓存雪崩

“永远不过期”

这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

缓存预热

有效应对缓存的击穿和雪崩的一种方式是缓存预热。

缓存预热就是系统上线前，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。

解决思路

直接写个缓存刷新页面，上线时手工操作下。
数据量不大，可以在项目启动的时候自动进行加载。
定时刷新缓存。

限流

有效应对缓存的击穿和雪崩的另一种方式是限流。

在缓存失效后，通过队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

常见的限流算法

固定时间窗口算法（计数器）
滑动时间窗口算法
令牌桶算法
漏桶算法

有关限流算法的详细介绍，请点击查看高并发系统的限流算法与实现

总结

缓存穿透、击穿和雪崩是以预防为主、补救为辅，而在应对缓存的问题其实也没有一个完全完美的方案，只有最适合自己业务系统的方案。

其他补充说明参考:

https://blog.csdn.net/zeb_perfect/article/details/54135506

MayMatrix

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
缓存穿透、缓存击穿和缓存雪崩原因+解决方案

REDIS缓存穿透，缓存击穿，缓存雪崩原因+解决方案一、前言在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫
复制链接

扫一扫