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

一、缓存流程图

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

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

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

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

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

解决方案：

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

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

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

缓存key-null   demo

完善的时候要对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、分布式锁（本地锁）

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

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

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

这只说下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的失效时间都不同。