【springboot】redis——高并发下缓存穿透问题

╰半夏微凉° 2024-02-19 18:52 78阅读 0赞

> 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在高并发，流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。  
> 我们通过下面一个例子来说明：  
> demo源码访问：[https://github.com/NerlCheng/springboot/tree/master/03-redis][https_github.com_NerlCheng_springboot_tree_master_03-redis]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70]

> 我们用三个蓝色的框进行表示代码  
> 1、在高并发的时候，比如突然有1W人次访问我们getAllOrder方法。  
> 2、因为是高并发，此时执行效果类似于，1W次的访问同时进入getAllOrder方法。  
> 3、此时，篮框1中的代码会执行一万次，如果此时缓存中没有数据，则返回的orderList为null。  
> 4、继续执行篮框2中的代码，经过判断，这一万次的请求都是为符合null==orderlist的，则这一万次的请求都进入了if语句中，并执行篮框3中代码进行数据库查询，此时导致对数据库1万次的请求，为此很有可能导致数据库请求量过大而崩溃。

> 我们想要的效果：  
> 当1W人次的请求是，第一个人查询redis缓存后，发现数据为null，进而这个人的请求去查询数据库，并将数据库写入到redis中，从而后面 的9999个人都是从redis缓存中查到相关的数据。

我们可以可以通过多线程进行模拟多并发的情景：  
对代码进行微微的调整进行日志打印：

@Override
        public List<tb_Order> getAllOrder1() {
        
    // 高并发条件下，此处有问题：缓存穿透问题
            // 查询缓存
            List<tb_Order> orderList= (List<tb_Order>) redisTemplate.opsForValue().get("AllOrder");
    
            if (null ==orderList){
        
                // 缓存为空，查询一遍数据库
                System.out.println("查询数据库------------");
                orderList= orderMapper.getAllOrder();
                redisTemplate.opsForValue().set("AllOrder",orderList);
            }else{
        
                System.out.println("查询redis缓存------------");
            }
            return orderList;
        }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70 1]  
另外我们在controller中通过多线程调用：

@GetMapping("/boot/getallorder1")
        public Object getAllOrder1(){
        
            //线程 该线程调用底层查询所有订单的方法
            Runnable runnable =new Runnable() {
        
                @Override
                public void run() {
        
                    orderServiceInterface.getAllOrder1();
                }
            };
            
            // 多线程测试一下缓存穿透问题
            ExecutorService executorService = Executors.newFixedThreadPool(25);
            for (int i=0;i<10000;i++){
        
                executorService.submit(runnable);
            }
            
            return orderServiceInterface.getAllOrder1();
        }

启动程序后，我们可以通过日志可以看到如下结果：（执行前不要忘记将原来的缓存删除哦，否则依旧显示查询的缓存）  
通过下面的图片可以看出来，在查询的时候，访问了很多次数据库，只有到了后面的时候才去查询缓存。  
备注：之所以他们在后期去查询缓存了，是因为计算机执行慢的问题。（不要太在意这些细节）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70 3]

为了解决上面的问题，我们有两种方案：

### 方法一：对getAllOrder方法加上锁：代码如下： ###

//对方法进行加锁，但是这样的性能不是很高
        @Override
        public synchronized List<tb_Order> getAllOrder2() {
        
            List<tb_Order> orderList= (List<tb_Order>) redisTemplate.opsForValue().get("AllOrder");
    
            if (null ==orderList){
        
                // 缓存为空，查询一遍数据库
                System.out.println("查询数据库------------");
                orderList= orderMapper.getAllOrder();
                redisTemplate.opsForValue().set("AllOrder",orderList);
            }else{
        
                System.out.println("查询redis缓存------------");
            }
            return orderList;
        }

### 方法二：双重检测 ###

//加上双层检测锁
        @Override
        public List<tb_Order> getAllOrder3() {
        
            List<tb_Order> orderList= (List<tb_Order>) redisTemplate.opsForValue().get("AllOrder");
    
            // 双重检测锁
            if (null==orderList){
        
                synchronized (this){
        
                    // 在redis中获取
                    orderList= (List<tb_Order>) redisTemplate.opsForValue().get("AllOrder");
                    if (null==orderList){
        
                        System.out.println("查询数据库------------");
                        orderList= orderMapper.getAllOrder();
                        redisTemplate.opsForValue().set("AllOrder",orderList);
                    }else {
        
                        System.out.println("查询redis缓存------------");
                    }
                }
            }else{
        
                System.out.println("查询redis缓存------------");
            }
            return orderList;
        }

[https_github.com_NerlCheng_springboot_tree_master_03-redis]: https://github.com/NerlCheng/springboot/tree/master/03-redis
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/18e8379e249c40fa87042f240db275d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/bdda43fa9bac4d66a50f6bc49203c219.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/7a9f116e012b43de81c361ab551858b2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpbWluZzY2_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/7077159c3f42450d862e3a379ad2e516.png