在分布式的环境下如何解决缓存穿透，雪崩，击穿问题以及使用redisson解决缓存击穿问题

小魏苦练算法

已于 2024-01-15 20:59:17 修改

阅读量1.1k

点赞数 21

分类专栏： java 文章标签：缓存分布式 redis

于 2024-01-15 20:49:04 首次发布

本文链接：https://blog.csdn.net/qq_63763951/article/details/135609929

版权

java 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

目录

reids的穿透雪崩击穿

穿透

击穿

雪崩

redisson

redisson的简单使用

可重入锁

公平锁

读写锁

redisson解决击缓存击穿问题

reids的穿透雪崩击穿

穿透

概念： 缓存和数据库中都没有的数据，可用户还是源源不断的发起请求，导致每次请求都会到数据库，从而压垮数据库。

解决方案：

业务层校验：用户发过来的请求，根据请求参数进行校验，对于明显错误的参数，直接拦截返回。

比如，请求参数为主键自增id，那么对于请求小于0的id参数，明显不符合，可以直接返回错误请求。
不存在数据设置短过期时间：对于某个查询为空的数据，可以将这个空结果进行Redis缓存，但是设置很短的过期时间，比如30s，可以根据实际业务设定。注意一定不要影响正常业务。
布隆过滤器：关于布隆过滤器，后面会详细介绍。布隆过滤器是一种数据结构，利用极小的内存，可以判断大量的数据“一定不存在或者可能存在”。

对于缓存击穿，我们可以将查询的数据条件都哈希到一个足够大的布隆过滤器中，用户发送的请求会先被布隆过滤器拦截，一定不存在的数据就直接拦截返回了，从而避免下一步对数据库的压力。

击穿

概念：Redis中一个热点key在失效的同时，大量的请求过来，从而会全部到达数据库，压垮数据库。

解决方案：

设置热点数据永不过期：对于某个需要频繁获取的信息，缓存在Redis中，并设置其永不过期。当然这种方式比较粗暴，对于某些业务场景是不适合的。
定时更新：比如这个热点数据的过期时间是1h，那么每到59minutes时，通过定时任务去更新这个热点key，并重新设置其过期时间。
互斥锁：这是解决缓存穿透比较常用的方法。单体架构和微服务解决方式有所不同，单体架构可以直接使用synchronized关键字。可以直接将查询数据库的那一段代码加上锁。这里要注意，加锁的时候一定要把释放锁放在将数据加入到缓存区之前。下面的图结构存在问题：

错误原因：在释放锁与数据保存到缓存区是需要消耗时间的，这个时候如果再有人竞争锁，还是会出现多次查询数据库的情况。

下面是正确的结构图：

在分布式应用下，我们就需要使用到reids的set ex nx参数作为锁，因为set nx保证多人同时保存的情况下只有一个人会保存成功。set ex 是设置过期时间，加锁要使用这两个参数，并且需要同时使用。如果将set nx与set ex分开使用，在运行到set nx时程序突然出现问题，那么这个锁就不会再销毁，set nx的数据一直存在则相当于锁一直被占用无法得到释放，这时候就出现了问题。所以set nx与set ex要同时使用。结构图如下：

互斥锁简单来说就是在Redis中根据key获得的value值为空时，先锁上，然后从数据库加载，加载完毕，释放锁。若其他线程也在请求该key时，发现获取锁失败，则睡眠一段时间（比如100ms）后重试。

雪崩

概念：Redis中缓存的数据大面积同时失效，或者Redis宕机，从而会导致大量请求直接到数据库，压垮数据库。

解决方案：

设置有效期均匀分布：

避免缓存设置相近的有效期，我们可以在设置有效期时增加随机值；或者统一规划有效期，使得过期时间均匀分布。
数据预热：对于即将来临的大量请求，我们可以提前走一遍系统，将数据提前缓存在Redis中，并设置不同的过期时间
保证Redis服务高可用：前面我们介绍过Redis的哨兵模式和集群模式，为防止Redis集群单节点故障，可以通过这两种模式实现高可用。

redisson

redisson的简单使用

可重入锁

如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。

// 加锁以后10秒钟自动解锁
// 无需调用unlock方法手动解锁
lock.lock(10, TimeUnit.SECONDS);

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
   try {
     ...
   } finally {
       lock.unlock();
   }
}

Redisson同时还为分布式锁提供了异步执行的相关方法：

RLock lock = redisson.getLock("anyLock");
lock.lockAsync();
lock.lockAsync(10, TimeUnit.SECONDS);
Future<Boolean> res = lock.tryLockAsync(100, 10, TimeUnit.SECONDS);

实例

@ResponseBody
@GetMapping(value = "/hello")
public String hello() {

    //1、获取一把锁，只要锁的名字一样，就是同一把锁
    RLock myLock = redisson.getLock("my-lock");

    //2、加锁
    myLock.lock();      //阻塞式等待。默认加的锁都是30s

    //1）、锁的自动续期，如果业务超长，运行期间自动锁上新的30s。不用担心业务时间长，锁自动过期被删掉
    //2）、加锁的业务只要运行完成，就不会给当前锁续期，即使不手动解锁，锁默认会在30s内自动过期，不会产生死锁问题

    // myLock.lock(10,TimeUnit.SECONDS);   //10秒钟自动解锁,自动解锁时间一定要大于业务执行时间
    //问题：在锁时间到了以后，不会自动续期(不会启动看门狗机制)
    //1、如果我们传递了锁的超时时间，就发送给redis执行脚本，进行占锁，默认超时就是 我们指定的时间
    //2、如果我们未指定锁的超时时间，就使用 lockWatchdogTimeout = 30 * 1000 【看门狗默认时间】
    //只要占锁成功，就会启动一个定时任务【重新给锁设置过期时间，新的过期时间就是看门狗的默认时间】,每隔10秒都会自动的再次续期，续成30秒
    // internalLockLeaseTime 【看门狗时间】 / 3， 10s
    try {
        System.out.println("加锁成功，执行业务..." + Thread.currentThread().getId());
        try { TimeUnit.SECONDS.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); }
    } catch (Exception ex) {
        ex.printStackTrace();
    } finally {
        //3、解锁  假设解锁代码没有运行，Redisson会不会出现死锁
        System.out.println("释放锁..." + Thread.currentThread().getId());
        myLock.unlock();
    }

    return "hello";
}

公平锁

基于Redis的Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。它保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。所有请求线程会在一个队列中排队，当某个线程出现宕机时，Redisson会等待5秒后继续下一个线程，也就是说如果前面有5个线程都处于等待状态，那么后面的线程会等待至少25秒。

实例：

RLock fairLock = redisson.getFairLock("anyLock");
// 10秒钟以后自动解锁
// 无需调用unlock方法手动解锁
fairLock.lock(10, TimeUnit.SECONDS);

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = fairLock.tryLock(100, 10, TimeUnit.SECONDS);
...
fairLock.unlock();

读写锁

基于Redis的Redisson分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。其中读锁和写锁都继承了RLock接口。
分布式可重入读写锁允许同时有多个读锁和一个写锁处于加锁状态。

实例：

RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
 //最常见的使用方法
rwlock.readLock().lock();
// 或
rwlock.writeLock().lock();

//大家都知道，如果负责储存这个分布式锁的Redis节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。
//另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。
/**
 * 保证一定能读到最新数据，修改期间，写锁是一个排它锁（互斥锁、独享锁），读锁是一个共享锁
 * 写锁没释放读锁必须等待
 * 读 + 读 ：相当于无锁，并发读，只会在Redis中记录好，所有当前的读锁。他们都会同时加锁成功
 * 写 + 读 ：必须等待写锁释放
 * 写 + 写 ：阻塞方式
 * 读 + 写 ：有读锁。写也需要等待
 * 只要有读或者写的存都必须等待
 * @return
 */
@GetMapping(value = "/write")
@ResponseBody
public String writeValue() {
        String s = "";
        RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");
        RLock rLock = readWriteLock.writeLock();
        try {
            //1、改数据加写锁，读数据加读锁
            rLock.lock();
            s = UUID.randomUUID().toString();
            ValueOperations<String, String> ops = stringRedisTemplate.opsForValue();
            ops.set("writeValue",s);
            TimeUnit.SECONDS.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            rLock.unlock();
        }


        return s;
        }

@GetMapping(value = "/read")
@ResponseBody
public String readValue() {
        String s = "";
        RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");
        //加读锁
        RLock rLock = readWriteLock.readLock();
        try {
            rLock.lock();
            ValueOperations<String, String> ops = stringRedisTemplate.opsForValue();
            s = ops.get("writeValue");
            try { TimeUnit.SECONDS.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            rLock.unlock();
        }

        return s;
        }

闭锁（CountDownLatch）

实例：

/**
* 放假、锁门
* 1班没人了
* 5个班，全部走完，我们才可以锁大门
* 分布式闭锁
*/

@GetMapping(value = "/lockDoor")
@ResponseBody
public String lockDoor() throws InterruptedException {


    RCountDownLatch door = redisson.getCountDownLatch("door");
    door.trySetCount(5);
    door.await();       //等待闭锁完成
    return "放假了...";
}

@GetMapping(value = "/gogogo/{id}")
@ResponseBody
public String gogogo(@PathVariable("id") Long id) {
    RCountDownLatch door = redisson.getCountDownLatch("door");
    door.countDown();       //计数-1
    return id + "班的人都走了...";
}

redisson解决击缓存击穿问题

当我们学习完上面的这些redisson的知识之后，再来看这个问题就变得格外简单了。我们只需要在缓存中没有数据且将需要查询数据库的时候引入redisson即可。下面是一段代码的实例。

     public Map<String, List<category2Vo>> queryCategoryListJson() {
        ValueOperations<String, String> stringStringValueOperations = stringRedisTemplate.opsForValue();
        String categoryJson = stringStringValueOperations.get(productConstant.reidsConstant.CATEGORY_JSON_CODE.getCode());
        if (StringUtils.isEmpty(categoryJson)){
            RLock lock = redisson.getLock(productConstant.reidsConstant.PRODUCT_REDISSON_LOCK.getCode());
            lock.lock();

            try {
                //查询数据库
                //将查询出来的数据信息保存到redis当中
                try { TimeUnit.SECONDS.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); }
            }catch (Exception e){
                e.printStackTrace();
            }finally {
                lock.unlock();
            }

        }
        //因为存储的时候是使用的json字符串，所以在返回数据的时候要将json转换成我们需要的对象
        return JSON.parseObject(categoryJson, new TypeReference<Map<String, List<category2Vo>>>() {
        });
    }

小魏苦练算法

关注

21
点赞
踩
18

收藏

觉得还不错? 一键收藏
打赏
2
评论
在分布式的环境下如何解决缓存穿透，雪崩，击穿问题以及使用redisson解决缓存击穿问题

为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。对于缓存击穿，我们可以将查询的数据条件都哈希到一个足够大的布隆过滤器中，用户发送的请求会先被布隆过滤器拦截，一定不存在的数据就直接拦截返回了，从而避免下一步对数据库的压力。不存在数据设置短过期时间：对于某个查询为空的数据，可以将这个空结果进行Redis缓存，但是设置很短的过期时间，比如30s，可以根据实际业务设定。当然这种方式比较粗暴，对于某些业务场景是不适合的。
复制链接

扫一扫