高并发下的缓存击穿、雪崩、穿透和分布式锁(三)

偏执的太偏执、 2024-02-20 09:30 51阅读 0赞

## 一.缓存穿透 ##

**概念：** 去查询缓存和数据库都不存在的数据，然后大量请求不存在的数据，导致数据库压力过大崩溃。

**解决方案：** 把不存在的数据null存入缓存，并给个短期的过期时间。

## 二.缓存雪崩 ##

**概念：** 缓存采用相同的过期时间，然后在某一时刻会同时过期，然后请求全部访问数据库，导致数据库崩溃。

**解决方案：** 把过期时间随机。

## 三.缓存击穿 ##

**概念：** 某个会过期的缓存会被大量请求访问，然后在失效的一刻，大量请求访问数据库，导致数据库崩溃。

**解决方案：** 加锁，大量请求，先让一个请求去查询数据库，然后存在缓存，其余请求都去查询缓存。

加锁：

//1.只要是同一把锁，就能锁住需要这个锁的线程。
    //因为springboot是单例的，又因为this代表当前对象，所以可以锁住访问的所有线程
    synchronized(this){
        
    	//(1) 首先去缓存查询是否存在缓存，存在就不用去查询数据库。
    	//(2) 不存在去查询数据库并且放在缓存里面。
    	//注意：要把(1) 和 (2) 都放在锁里面操作。不然会出现锁的时序问题。
    }
    
    //2.在方法上直接加synchronized也行。

## 四.分布式锁 ##

### 1.为什么需要分布式锁 ###

在分布式的情况下，比如：会员服务，可能会有多个，然而上面的加锁行为，只能锁住一个服务，这样就会出现问题。  
![在这里插入图片描述][73ef91098efe42f8bb79de05c4131c81.png]

### 2.分布式锁的基本原理 ###

比如，我们现在有这么多会员服务，现在都要查数据库，现在我们约定只有一个人能查数据库，查完以后放到缓存里面。

这样呢，所有服务都要进来，需要抢占一个锁，本地情况下，我们可以使用语法比如synchronize(this)锁住当前对象，只要大家用的是一个对象，就能锁住了。

在分布式情况下也一样，我们this在分布式情况下，肯定没得用。

但是，我们可以考虑现实生活中的一个例子，比如，我们几千个人都去上公共厕所，里面只有一个坑位，那如何保证他们有序的进行，就是说，只要我进来了，我就给这个厕所上把锁，那别人就不能进来了。然后，上完以后，再出门解锁，这样其他人又能进来了。

所以，我们分布式锁，也是这个思想原理，所有的会员服务，无论你是哪一个实例，大家都去一个公共的地方占锁，如果占到了锁，就去执行业务，如果没有站到锁的，那等待一下。

当我们业务执行完了以后，然后，释放锁，这样别人就可以占到这个锁了。

我们说的这个占坑，可以去任何一个地方去占，只要大家都去公共的一个地方，比如大家都去数据库，哪怕给数据库里面插入一条记录，如果这个人插入进去了，说明是成功的，如果插入的时候，看到已经有记录了，他就不能插入成功。  
![在这里插入图片描述][32390c6341854e98bb8864c6d437afdd.png]

[73ef91098efe42f8bb79de05c4131c81.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/06cccc8f791d4e46ad2f0541b18b4a12.png
[32390c6341854e98bb8864c6d437afdd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/63683509096c48248e516d5165968107.png