缓存穿透、缓存击穿与缓存雪崩解决方案

Bertha 。 2023-01-22 01:54 41阅读 0赞

## 一、缓存流程图 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70][]

释义：前端发起请求，先查缓存是否有，缓存有则直接返回前端，缓存没有，则请求数据库，请求数据库成功，先存至缓存，然后在返回前端

红线代表缓存没有查询到的情况，黑线代表缓存查询到的情况

缓存的意义：数据库数据存入缓存，请求直接从内存中读取不用经过数据库(牵扯IO)，减轻数据库压力并且提升性能。

## 二、缓存穿透【穿透缓存、数据库，都无数据】 ##

定义：缓存穿透，是指缓存和数据库中都无数据，而用户不断发起请求；如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

解决方案：

1）在接口层增加校验。比如：①用户鉴权校验，②id做基础校验，id<=0的直接拦截并返回。

2）使用临时缓存机制。缓存和数据库都取不到，此时可将key-value对写为key-null，设置较短的缓存有效时间（如30秒，设置太长可能导致正常情况没法使用）。如此，可防止用户反复用同一id暴力按查询攻击。

3）布隆过滤器处理缓存穿透（这个也很好）

缓存key-null   demo

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70 1][]

完善的时候要对key设置一个相对短暂的失效时间

## 三、缓存击穿【击穿缓存，能在数据库中查到】 ##

定义：缓存击穿，是指缓存中没有，数据库中有的数据（一般情况是缓存时间到期）；此时，由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，导致数据库压力瞬间增大。

解决方案：

1）热点数据设置为永不过期。

2）加互斥锁，对查询操作进行同步。参考代码如下。

static Lock reenLock = new ReentrantLock();
       public List<String> getData() throws InterruptedException {
           List<String> result = new ArrayList<String>();
           // 从缓存取数
           result = getDataFromCache();
           if (result.isEmpty()) {
               if (reenLock.tryLock()) {
                   try {
                       System.out.println("拿到锁,从DB获取数据库后写入缓存");
                       // 从数据库取数
                       result = getDataFromDB();
                       // 将查询到的数据写入缓存
                       setDataToCache(result);
                   } finally {
                       reenLock.unlock();// 释放锁
                   }
               } else {
                   result = getDataFromCache();// 先再查一下缓存
                   if (result.isEmpty()) {
                       System.out.println("没拿到锁,缓存也无数据,等待...");
                       Thread.sleep(100);//等待
                       return getData();//重试
                   }
     
               }
           }
           return result;
       }

说明：

1）缓存中有数据，直接返回结果。

2）缓存中没有数据，获取锁并从数据库去取数据，没释放锁之前，其他并行进入的线程会等待100ms，再重新去缓存取数据。这样就防止都去数据库重复取数据，重复往缓存中更新数据情况出现。

3）当然这是简化处理，理论上如果能根据key值加锁就更好了，就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据，上面代码明显做不到这点。方案：锁可以细粒度到key。

## 四、缓存雪崩 ##

定义：缓存雪崩，是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。

与“缓存击穿”区别：缓存击穿，是指并发查询同一条数据；缓存雪崩，是不同的数据都已基本同时过期，很多数据缓存查不到，都转而查询数据库。

解决方案：

1）批量往Redis存数时，每个Key的失效时间设置为随机值，如此可保证数据不会在同一时间大面积失效。

setRedis(Key，value，time + Math.random() \* 10000)；

2）如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中，也可避免全部失效的问题。

3）热点数据设置永不过期，有更新操作则更新缓存即可。

其他解决雪崩的方法

1、分布式锁（本地锁）

> 当突然有大量的请求到数据库服务器的时候，进行对数据库服务请求限制。这个可以使用锁的机制，保证只有一个线程（请求）进行数据库的访问操作，否则则直接排队等待（如果是集群服务器的话，要使用分布式锁，单机版可以使用本地锁）。确实可以解决雪崩效应，但是会减少服务器的吞吐量。（适合与小项目）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70 2][]

通过ReentrantLock来保证每次只能有一个线程执行进而防止大量请求发生导致的雪崩，但是缺点就是吞吐量比较低。除了reentrantLock，还可以做限流。

2、使用消息中间件（最靠谱），消息中间件可以解决高并发问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70 3][]

这只说下MQ处理的思想

> 1、如果redis查询不到结果的情况，这个时候直接将查询DB的方法作为一个消息防止消息中间件中，

3、redis+ehcache做一级和二级缓存

public Users getUser(Long id) {
    		String key = this.getClass().getName() + "-" + Thread.currentThread().getStackTrace()[1].getMethodName()
    				+ "-id:" + id;
    		// 1.先查找一级缓存(本地缓存),如果本地缓存有数据直接返回
    		Users ehUser = (Users) ehCacheUtils.get(CACHENAME_USERCACHE, key);
    		if (ehUser != null) {
    			System.out.println("使用key:" + key + ",查询一级缓存 ehCache 获取到ehUser:" + JSONObject.toJSONString(ehUser));
    			return ehUser;
    		}
    		// 2. 如果本地缓存没有该数据，直接查询二级缓存(redis)
    		String redisUserJson = redisService.getString(key);
    		if (!StringUtils.isEmpty(redisUserJson)) {
    			// 将json 转换为对象(如果二级缓存redis中有数据直接返回二级缓存)
    			JSONObject jsonObject = new JSONObject();
    			Users user = jsonObject.parseObject(redisUserJson, Users.class);
    			// 更新一级缓存
    			ehCacheUtils.put(CACHENAME_USERCACHE, key, user);
    			System.out.println("使用key:" + key + ",查询二级缓存 redis 获取到ehUser:" + JSONObject.toJSONString(user));
    			return user;
    		}
    		// 3. 如果二级缓存redis中也没有数据,查询数据库
    		Users user = userMapper.getUser(id);
    		if (user == null) {
    			return null;
    		}
    		// 更新一级缓存和二级缓存
    		String userJson = JSONObject.toJSONString(user);
    		redisService.setString(key, userJson);
    		ehCacheUtils.put(CACHENAME_USERCACHE, key, user);
    		System.out.println("使用key:" + key + "，一级缓存和二级都没有数据,直接查询db" + userJson);
    		return user;
    	}

4、就是上面说的三点，均摊分布redis key的失效时间。比较靠谱，不同的key的失效时间都不同。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70]: /images/20221020/38d68ca455eb4775afc108b445a62367.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70 1]: /images/20221020/e794baed5ca1480e8abf9e53915579cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70 2]: /images/20221020/080606be424e48c0a6c353fd64497613.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70 3]: /images/20221020/b2afc54e555f4bf2b7dbd34432125dba.png