Redis缓存穿透-雪崩-击穿现象与解决办法

一.缓存穿透
1.什么是缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。如发起为id为“"-1"的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
官方解释：缓存穿透是指查询一个一定不存在的数据，由于缓存不命中，接着查询数据库也无法查询出结果，因此也不会写入到缓存中，这将会导致每个查询都会去请求数据库，造成缓存穿透；
例如：对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。这种恶意攻击场景的缓存穿透就会直接把数据库给打死
2.解决办法
思路：可以给key设置一些格式规则，然后查询之前先过滤掉不符合规则的Key
（1）采用布隆过滤器BloomFilter
将所有可能查询的数据 hash到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉。在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。
另一种解释1.接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截;
（2）缓存空值
如果一个查询返回的数据为空(不管是数据不 存在，还是系统故障)，
直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。设置一个过期时间，但它的过期时间会很短，最长不超过五分钟，或者当有值的时候将缓存中的值替换掉即可
另一个解释：从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击

@Override
public Notice findByPrimaryKey(String id){
       Notice notice = (Notice) redisTemplate.opsForValue().get("noticeId-"+id);
        if(notice == null){
	//缓存为空时，查询数据库并缓存数据
    	notice = noticeMapper.selectByPrimaryKey(Integer.valueof(id));
	 if(notice == null){
	     //对于id在数据库中不存在的查询，单独处理（过期时间设置为60秒）。
	    redisTemplate.opsForValue().set( k:"noticeId- "+id,notice, l: 60，TimeUnit.SECONDS);
	}
	//可用数据在REDIS中存10天
	redisTemplate.opsForValue().set( k:"noticeId-"+id ,notice, I:10，TimeUnit.DAYS);
	}
	return notice;
   }

上面代码中，对空值设置较短的过期时间，时间太长会导致空数据不能及时更新掉，占用系统资源，时间太短又起不到防止缓存穿透的作用，具体以实际情况配置
这种方法会存在两个问题：
如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；
即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。
（3）接口限流与熔断、降级
重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些服务不可用时候，进行熔断，失败快速返回机制。
二.缓存雪崩
1.什么是缓存雪崩
指在同一个时间段内缓存大面积的键集中过期失效，使得所有的查询都落在数据库上，导致数据库CPU和内存负载过高，甚至宕机。
比如一个雪崩的简单过程：
1、redis集群大面积故障
2、缓存失效，但依然大量请求访问缓存服务redis
3、redis大量失效后，大量请求转向到mysql数据库
4、mysql的调用量暴增，很快就扛不住了，甚至直接宕机
5、由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各服务器集群的雪崩，最后网站彻底崩溃。
举个栗子：如果首页所有 Key 的失效时间都是 12 小时，中午 12 点刷新的，我零点有个大促活动大量用户涌入，假设每秒 6000 个请求，本来缓存可以抗住每秒 5000 个请求，但是缓存中所有 Key 都失效了。此时 6000 个/秒的请求全部落在了数据库上，数据库必然扛不住，真实情况可能 DBA 都没反应过来直接挂了。
2.解决办法
（1）加锁排队
key： whiltList value：1000w个uid 指定setNx whiltList value nullValue mutex互斥锁解决，Redis的SETNX去set一个mutex key， 当操作返回成功时，再进行load db的操作并回设缓存； 否则，就重试整个get缓存的方法

public String getByKey(String keyA,String keyB) {
//通过Key获取value
 String value = redisService.get(keyA);
 if (StringUtil.isEmpty(value)) {
 	value = redisService.get(keyB);
 String newValue = getFromDbById();
 redisService.set(keyA,newValue,31, TimeUnit.DAYS);
 redisService.set(keyB,newValue);
 }
 return value;
}

（2） 数据预热
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

（3） 双层缓存策略
C1为原始缓存，C2为拷贝缓存，C1失效时，可以访问C2，C1缓存失效时间设置为短期，C2设置为长期。
（4） 定时更新缓存策略
失效性要求不高的缓存，容器启动初始化加载，采用定时任务更新或移除缓存，
（5）不同过期时间
设置不同的过期时间，让缓存失效的时间点尽量均匀
（6）热点数据永不过期
部分用户访问特别频繁的热点数据，设置永不过期
(7) 保证缓存层服务的高可用性
缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，比如 Redis Sentinel 和 Redis Cluster 都实现了高可用
（8）依赖隔离组件为后端限流并降级
在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
三.缓存击穿
1.什么是缓存击穿
官方解释：缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期)，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力
另一解释：缓存击穿是指一个 Key 非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个 Key 在失效的瞬间，持续的大并发直接落到了数据库上，就在这个 Key 的点上击穿了缓存。
2.解决办法
（1）互斥锁

public static String getData(String key) throws InterruptedException { 
	//从Redis查询数据 
	String result = getDataByKV(key); 
	//参数校验 
	if (StringUtils.isBlank(result)) { 
		try { 
		//获得锁 
		if (reenLock.tryLock()) { 
			//去数据库查询 
			result = getDataByDB(key); 
			//校验 
			if (StringUtils.isNotBlank(result)) { 
			//插进缓存 setDataToKV(key, result); 
			} 
		} else { 
			//睡一会再拿 
			Thread.sleep(100L); result = getData(key); } 
		} finally { 
		//释放锁 reenLock.unlock(); } 
		} 
		return result; 
}

对于加锁的优化过程看下面 补充优化

（2）热点数据永不过期
不过期将不存在该问题
(3) 1）.使用同步锁 synchronized 关键字，修饰在获取缓存的方法里面，保证在多用户同时请求条件下，只有第一个进入的线程去判断是否要查询数据库并存入缓存，其他线程只需在第一个线程结束后，从缓存中读取数据即可，无需再查询数据库。

@Override
public Notice findByPrimaryKey(String id) {
     Notice notice = (Notice)redisTemplate.opsForValue().get("noticeId-"+id);
       //双重检查锁
       if(notice == null){
            synchronized (this){
	//第一个线程进入获取缓存中的数据,其他线程等待
	notice = (Notice) redisTemplate.opsForValue().get("noticeId-"+id);
	if(notice == null){
	      //缓存为空时，查询数据库并缓存数据
	       notice = noticeMapper.selectByPrimaryKey(Integer.valueof(id));
	       if(notice == null){
		//对于id在数据库中不存在的查询，单独处理（过期时间设置为60秒）
		redisTemplate.opsForValue( ).set( k: "noticeId-"+id,notice, I: 60，TimeUnit.SECONDS);
	         }
		//可用数据在REDIS中存储10天
		redisTemplate.opsForValue( ).set( k: "noticeId-"+id ,notice, I:10，TimeUnit.DAYS);
	      }
	   }
	     return notice;
	}

上面的代码是对缓存穿透的再次优化，加入 线程同步锁 以及 双重检查锁 。
双重检查锁：1.避免当缓存数据 没有失效 时，其他线程排队等待。
2.当第一个线程从数据库中获取到数据并存入缓存中时，其他线程直接从缓存获取数据即可。
2) .第二种是不设置缓存时间，由后台创建定时任务去维护这部分缓存数据。这种方法请求时直接从缓存中获取数据，无需再判断是否从数据库中获取，定时任务也可在请求较少的时间段分批更新缓存数据。
当然代码量、代码复杂度增大，分批更新代表需要多个定时任务去维护缓存数据，同时更新有可能会造成缓存雪崩的情况
缓存并发
这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行。

缓存预热
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。
这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决思路：
1、直接写个缓存刷新页面，上线时手工操作下；
2、数据量不大，可以在项目启动的时候自动进行加载；
目的就是在系统上线前，将数据加载到缓存中。

加锁的补充优化过程
方法1：

public synchronized List<String> getData01() {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据       
result = getDataFromCache();
        if (result.isEmpty()) {
            // 从数据库查询数据 
 result = getDataFromDB();
            // 将查询到的数据写入缓存 
  setDataToCache(result);
        }
        return result;
      }

注：这种方式确实能够防止缓存失效时高并发到数据库，但是缓存没有失效的时候,在从缓存中拿数据时需要排队取锁，这必然会大大的降低了系统的吞吐量。
方法二：

static Object lock = new Object();
    public List<String> getData02() {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据       
 result = getDataFromCache();
        if (result.isEmpty()) {
            synchronized (lock) {
                // 从数据库查询数据              
  result = getDataFromDB();
                // 将查询到的数据写入缓存             
  setDataToCache(result);
            }
        }
        return result;
    }　

注：这个方法在缓存命中的时候，系统的吞吐量不会受影响，但是当缓存失效时，请求还是会打到数据库，只不过不是高并发而是阻塞而已。但是，这样会造成用户体验不佳，并且还给数据库带来额外压力。
方法三

public List<String> getData03() {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据       
 result = getDataFromCache();
        if (result.isEmpty()) {
            synchronized (lock) {
           //双重判断,第二个以及之后的请求不必去找数据库,直接命中缓存                		   // 查询缓存              
  	result = getDataFromCache();
                if (result.isEmpty()) {
                    // 从数据库查询数据                
    result = getDataFromDB();
                    // 将查询到的数据写入缓存                    			
setDataToCache(result);
                }
            }
        }
        return result;
    }

注：双重判断虽然能够阻止高并发请求打到数据库，但是第二个以及之后的请求在命中缓存时，还是排队进行的。比如，当30个请求一起并发过来,在双重判断时，第一个请求去数据库查询并更新缓存数据，剩下的29个请求则是依次排队取缓存中取数据，请求排在后面的用户的体验会不爽。

方法四

static Lock reenLock = new ReentrantLock();
    public List<String> getData04() 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 getData04();// 重试 
 }
            }
        }
        return result;
    }

注：最后使用互斥锁的方式来实现，可以有效避免前面几种问题