redis缓存雪崩，缓存穿透等（全）

Redis

一、缓存穿透

1、概念：

主要是大量请求数据时发现redis中没有数据，于是大量请求直达mysql数据库，mysql并发承受很低一般在2000左右，所以可能导致数据库扛不住

2、解决方法：

方法一 ：（没查到的也存起来）
将访问的空值也存储起来，当访问redis和数据库都没有数据时，将空的也存储起来，然后设置过期时间（一般10分钟以内）
，这样在过期时间以内请求都不会直达数据库

代码实现：

 @Override
    public ResultCommon getById(long id) {

		//1、用1个固定的字符串前缀+id作为redis存的key值
        String key=ConstantCommon.Product.REDIS_KEY_ID_INFO_PREFIX +String.valueOf(id);

		//2、id<=0说明请求错的（可能是黑客攻击），直接返回失败，不走redis和mysql
        if(id<=0)return ResultCommon.fail(ResultEnum.PRODUCT_ID_ERROR,id);
        
        Object hmget = redisUtils.hmget(key ,Object.class);

        if(hmget!=null){
        	//查的值不存在，得到之前存的空值对象，直接返回
            if(hmget instanceof RedisNullValue){
                return ResultCommon.fail(ResultEnum.PRODUCT_ID_NOT_EXISTS);
            }
        }
        //redis没有查询到
        if(hmget==null){
            hmget=productMapper.getById(id);
            if(hmget!=null){
            	//查到mysql有值，就存到redis中
                redisUtils.hmset(key,hmget);
            }else {
                redisUtils.hmset(key,RedisNullValue.getInstance());
                //没值就存空值对应对象，设置过期时间
                redisUtils.expire(key,ConstantCommon.RedisCommon.RedisNullValue_expire);
                return  ResultCommon.fail(ResultEnum.PRODUCT_ID_NOT_EXISTS);
            }
        }
        return ResultCommon.success(hmget);
    }

方法二 ：（采用布隆过滤器）推荐

判断一个key一定不存在于当前过滤器中，或者一个key有很大可能存在于过滤器中

缓存预热，获得增加商品的数据的时候，就把当前的id放入布隆过滤器容器中，如果有id过来查询，先不走到业务层，通过一个aop，先用布隆过滤器来判断是否存在这个id，如果不存在直接返回

应用场景

网页黑名单，爬虫网页去重，骚扰电话

实现思想：

看成一个集合

\1. 在项目初始化的时候就预热，放入redis一个key，就加在blfilter一个key

\2. 在增删改的时候，只要涉及到增加key，也放入bloomfilter

查询到redis为null，先用布隆过滤器判断，如果一定不存在就直接返回null

二、redis缓存雪崩

2.1、概念：

缓存失效导致系统雪崩，持久层扛不住 系统雪崩主要是设置多个key一起过期
表示在一定时间内，缓存大面积失效(区分穿透)，导致全部请求命中到持久层(mysql)，导致系统崩溃。

3.2、原因和解决方法

1. 代码逻辑是先查询数据库再放入缓存中，没有查询导致缓存中没有数据，一瞬间来了大量请求全部打到数据库

解决方案:缓存预热，在系统上线后，将可能使用到的数据，直接缓存到redis中

package com.zqs.product1.initRedis;


import com.zqs.product1.common.ConstantCommon;
import com.zqs.product1.pojo.Product;
import com.zqs.product1.service.ProductService;
import com.zqs.product1.utils.RedisUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;
import java.util.List;
import java.util.concurrent.*;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

@Component
public class ProductInit {

    @Autowired
    ProductService productService;
    @Autowired
    RedisUtils redisUtils;

    @PostConstruct
    public  void  initProduct(){

        ExecutorService executorService=Executors.newFixedThreadPool(20);

        CompletableFuture<Void> voidCompletableFuture = CompletableFuture.runAsync(() -> {
            List<Product> products = productService.queryAll();
            products.stream().forEach(product -> {
                redisUtils.hmset(ConstantCommon.Product.REDIS_KEY_ID_INFO_PREFIX + String.valueOf(product.getId()), product);
            });
        }, executorService);
        CompletableFuture<Void> voidCompletableFuture1 = CompletableFuture.allOf(voidCompletableFuture);
        voidCompletableFuture1.join();
        executorService.shutdown();
    }


}

2. 由于redis过期时间设置得比较统一，导致缓存大面积过期 5万个key 过期时间相同

这个就对缓存失效时间进行考虑，比如多少秒加个随机数等，避免大面积失效就可以了

3. Redis宕机，服务器断电等

增加redis高可用，集群、分片、读写分离、哨兵等

三、redis键过期处理机制

redis采用的是定期删除+惰性删除策略。

3.1、（定期删除+惰性删除）工作原理

定期删除：redis默认每个100ms检查，是否有过期的key,有过期key则删除（只是一部分key）机抽取进行检查
这样会导致很多key到时间没有删除
于是加入了惰性删除机制
惰性删除：get 某个key的时候，redis会判断这个key过期没有，如果过期就回收
但是如果 没有定期删除和get数据时，redis的内存会越来越高

3.1内存淘汰机制：配置redis.conf中有一行配置（# maxmemory-policy volatile-lru）

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。

2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。**推荐使用，大部分情况适用。**
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

4）volatile-lru：当内存不足以容纳新写入数据时，**在设置了过期时间的键空间中**，移除最近最少使用的key。这种情况一般是把redis既当缓存，
又做持久化存储的时候才用。不推荐
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

常见选择:

**如果希望一些数据能长期被保存，而一些数据可以被淘汰掉时，选择volatile-lru或volatile-random都是比较不错的。**

allkeys-lru：如果我们的应用对缓存的访问符合幂律分布（也就是存在相对热点数据），或者我们不太清楚我们应用的缓存访问分布状况，
我们可以选择allkeys-lru策略。

allkeys-random：如果我们的应用对于缓存key的访问概率相等，则可以使用这个策略。

四、redis持久化

点击此篇博客