Redis缓存

一、 缓存穿透

缓存穿透是指查询一条数据库和缓存都没有数据，会一直查询数据库，对数据库的访问压力就会增大。

解决方案有两种：

1. 缓存空对象：代码维护较简单，但是效果不好。
2. 布隆过滤器：代码维护复杂，效果很好。

1、缓存空对象

缓存空对象是指当一个请求过来缓存中和数据库中都不存在该请求的数据，第一次请求就会跳过缓存进行数据库的访问，并且访问数据库后返回为空，此时也将该空对象进行缓存。

若是再次进行访问该空对象的时候，就会直接 击中缓存 ，而不是再次 数据库。

原理图

代码如下：

public class UserServiceImpl {
     @Autowired
     UserDAO userDAO;
     @Autowired
     RedisCache redisCache;

     public User findUser(Integer id) {
          Object object = redisCache.get(Integer.toString(id));
          // 缓存中存在，直接返回
          if(object != null) {
               // 检验该对象是否为缓存空对象，是则直接返回null
               if(object instanceof NullValueResultDO) {
                    return null;
               }
               return (User)object;
          } else {  
               // 缓存中不存在，查询数据库
               User user = userDAO.getUser(id);
               // 存入缓存
               if(user != null) {
                    redisCache.put(Integer.toString(id),user);
               } else {
                    // 将空对象存进缓存
                    redisCache.put(Integer.toString(id), new NullValueResultDO());
               }
               return user;
          }
     }          
}

2、 布隆过滤器

（1）定义

布隆过滤器是一种基于概率的数据结构，主要用来判断某个元素是否在集合内，它具有运行速度快（时间效率），占用内存小（空间效率），但是有一定的误识别率和删除困难的问题。它只能告诉你某个元素一定不在集合内，或可能在集合内。

（2）特点

1. 一个非常大 的二进制位数组 （数组里只有0和1）
2. 若干个 哈希函数
3. 空间效率 和 查询效率高
4. 不存在 漏报 （False Negative）：某个元素在某个集合中，肯定能报出来。
5. 可能存在 误报 （False Positive）：某个元素不在某个集合中，可能也被爆出来。
6. 不提供删除方法，代码维护困难。
7. 位数组初始化都为0，它不存元素的具体值，当元素经过哈希函数哈希后的值（也就是数组下标）对应的数组位置值改为1。

（3）原理图

初始化的布隆过滤器的结构图如下：

如果我们要映射一个值到布隆过滤器中，我们需要使用 多个不同的哈希函数 生成 多个哈希值， 然后将初始化的位数组对应的下标的值修改为1，例如针对值 “baidu” 和三个不同的哈希函数分别生成了哈希值 1、4、7，则上图转变为：

那么为什么会有误判率呢？

我们现在再存一个值 “tencent”，如果哈希函数返回 3、4、8 的话

结果如下：

值得注意的是，4 这个 bit 位由于两个值的哈希函数都返回了这个 bit 位，因此它被覆盖了。现在我们如果想查询 “dianping” 这个值是否存在，哈希函数返回了 1、5、8三个值，结果我们发现 5 这个 bit 位上的值为 0，说明没有任何一个值映射到这个 bit 位上，因此我们可以很确定地说 “dianping” 这个值不存在。

而当我们需要查询 “baidu” 这个值是否存在的话，那么哈希函数必然会返回 1、4、7，然后我们检查发现这三个 bit 位上的值均为 1，那么我们可以说 “baidu” 存在了么？答案是不可以，只能是 “baidu” 这个值可能存在。

这是为什么呢？答案跟简单，因为随着增加的值越来越多，被置为 1 的 bit 位也会越来越多，这样某个值 “taobao” 即使没有被存储过，但是万一哈希函数返回的三个 bit 位都被其他值置位了 1 ，那么程序还是会判断 “taobao” 这个值存在。

那么具体布隆过布隆过滤的判断的准确率和一下 两个因素 有关：

1. 布隆过滤器大小 ：越大，误判率就越小，所以说布隆过滤器一般长度都是非常大的。
2. 哈希函数的个数 ：哈希函数的个数越多，那么误判率就越小。

那么为什么不能删除元素呢？

原因很简单，因为删除元素后，将对应元素的下标设置为零，可能别的元素的下标也引用该下标，这样别的元素的判断就会收到影响

代码：

<dependency>
    <groupId>com.google.guavagroupId>
    <artifactId>guavaartifactId>
    <version>27.0.1-jreversion>
dependency>

public static void MyBloomFilterSysConfig {

     @Autowired
     OrderMapper orderMapper

    // 1.创建布隆过滤器  第二个参数为预期数据量10000000，第三个参数为错误率0.00001
    BloomFilter<CharSequence> bloomFilter =  
       BloomFilter.create(Funnels.stringFunnel(Charset.forName("utf-8")),10000000, 0.00001);
    // 2.获取所有的订单，并将订单的id放进布隆过滤器里面
    List<Order> orderList = orderMapper.findAll()
    for (Order order : orderList ) {
        Long id = order.getId();
        bloomFilter.put("" + id);
    }
}

  	// 判断订单id是否在布隆过滤器中存在
	bloomFilter.mightContain("" + id)

二、缓存击穿

缓存击穿 是指一个key非常热点，在不停的扛着大并发， 大并发 集中对这一个点进行访问，当这个key在失效的瞬间，持续的 大并发 就穿破缓存，直接请求数据库，瞬间对数据库的访问压力增大。

缓存击穿这里强调的是 并发 ，造成缓存击穿的原因有以下两个：

1. 该数据没有人查询过 ，第一次就大并发的访问。（冷门数据）
2. 添加到了缓存，reids有设置数据失效的时间 ，这条数据刚好失效，大并发访问（热点数据）

对于缓存击穿的解决方案就是加锁，具体实现的原理图如下：

当用户出现 大并发 访问的时候，在查询缓存的时候和查询数据库的过程加锁，只能第一个进来的请求进行执行，当第一个请求把该数据放进缓存中，接下来的访问就会直接集中缓存，防止了 缓存击穿 。

业界比价普遍的一种做法，即根据key获取value值为空时，锁上，从数据库中 load 数据后再释放锁。若其它线程获取锁失败，则等待一段时间后重试。这里要注意，分布式环境中要使用 分布式锁 ， 单机 的话用普通的锁（ synchronized 、 Lock ）就够了。

单机版 的锁实现具体实现的代码如下：

// 获取库存数量
public String getProduceNum(String key) {
    try {
        synchronized (this) {   //加锁
            // 缓存中取数据，并存入缓存中
            int num= Integer.parseInt(redisTemplate.opsForValue().get(key));

            if (num> 0) {
                //没查一次库存-1
                redisTemplate.opsForValue().set(key, (num- 1) + "");
                System.out.println("剩余的库存为num：" + (num- 1));
            } else {
                System.out.println("库存为0");
            }
        }
    } catch (NumberFormatException e) {
        e.printStackTrace();
    } finally {
    }
    return "OK";
}

分布式 的锁实现具体实现的代码如下：

public String getProduceNum(String key) {
    // 获取分布式锁
    RLock lock = redissonClient.getLock(key);
    try {
        // 获取库存数
        int num= Integer.parseInt(redisTemplate.opsForValue().get(key));  
        // 上锁           
        lock.lock();
        if (num> 0) {
            //减少库存，并存入缓存中
            redisTemplate.opsForValue().set(key, (num - 1) + "");
            System.out.println("剩余库存为num：" + (num- 1));
        } else {
            System.out.println("库存已经为0");
        }
    } catch (NumberFormatException e) {
        e.printStackTrace();
    } finally {
        //解锁
        lock.unlock();
    }
    return "OK";
}

三、缓存雪崩

缓存雪崩 是指在某一个时间段，缓存集中过期失效。此刻无数的请求直接绕开缓存，直接请求数据库。

造成缓存雪崩的原因，有以下两种：

1. reids宕机
2. 大部分数据失效

对于缓存雪崩的解决方案有以下两种：

1. 搭建高可用的集群，防止单机的redis宕机。
2. 设置不同的过期时间，防止同一时间内大量的key失效。