docker中 system limit for_springboot中redis的缓存穿透问题

什么是缓存穿透问题？？

我们使用redis是为了减少数据库的压力，让尽量多的请求去承压能力比较大的redis，而不是数据库。但是高并发条件下，可能会在redis还没有缓存的时候，大量的请求同时进入，导致一大批的请求直奔数据库，而不会经过redis。使用代码模拟缓存穿透问题如下：

首先是service里面的代码：

@Service
public class NewsService {
    @Autowired
    private NewsDAO newsDAO;

    //springboot自动初始化，不需要我们进行配置，直接注入到代码中使用
    @Autowired
    private RedisTemplate<Object,Object> redisTemplate;

    public /*synchronized*/ List<News> getLatestNews(int userId,int offset,int limit){

        //设置序列化方式，防止乱码
        redisTemplate.setKeySerializer(new StringRedisSerializer());

        //第一步：查询缓存
        News news= (News) redisTemplate.opsForValue().get("newsKey");
        //判断是否存在缓存
        if(null == news){//查询数据库
                news = newsDAO.selectByUserIdAndOffset(userId,offset,limit).get(0);
                //
                redisTemplate.opsForValue().set("newsKey",news);

                System.out.println("进入数据库。。。。。。。。");
            
        }else{
            System.out.println("进入缓存。。。。。。。。。");
        }
        return newsDAO.selectByUserIdAndOffset(userId,offset,limit);

    }
}

然后是使用线程池在Controller里面对请求进行模拟：

@Controller
public class HomeController {
    @Autowired
    UserService userService;

    @Autowired
    NewsService newsService;

    //遇到的坑，如果不加method，页面启动不起来。
    @RequestMapping(value = "/home",method = {RequestMethod.GET, RequestMethod.POST})
    @ResponseBody
    public String index(Model model){
        //这边是可以读出数据来的

        //线程池------缓存穿透问题的复现
        ExecutorService executorService = Executors.newFixedThreadPool(8*2);

        for(int i = 0;i < 50000;i++){
            executorService.submit(new Runnable() {
                @Override
                public void run() {
                    List<News> newsList = newsService.getLatestNews(0,0,10);
                }
            });
        }

        List<News> newsList = newsService.getLatestNews(0,0,10);
        News news=newsList.get(0);
        return news.getImage();
    }
}

结果如图：大量的请求进入数据库，那么如何解决这个问题？

方法一、在方法上加锁：

@Service
public class NewsService {
    @Autowired
    private NewsDAO newsDAO;

    //springboot自动初始化，不需要我们进行配置，直接注入到代码中使用
    @Autowired
    private RedisTemplate<Object,Object> redisTemplate;

    //第一种方式：方法加锁
    public synchronized List<News> getLatestNews(int userId,int offset,int limit){

        //设置序列化方式，防止乱码
        redisTemplate.setKeySerializer(new StringRedisSerializer());

        //第一步：查询缓存
        News news= (News) redisTemplate.opsForValue().get("newsKey");
        //判断是否存在缓存
        if(null == news){
//查询数据库
                news = newsDAO.selectByUserIdAndOffset(userId,offset,limit).get(0);
                //
                redisTemplate.opsForValue().set("newsKey",news);

                System.out.println("进入数据库。。。。。。。。");

        }else{
            System.out.println("进入缓存。。。。。。。。。");
        }


        return newsDAO.selectByUserIdAndOffset(userId,offset,limit);

    }
}

直接在方法上加锁，保证每次只有一个请求可以进入。但是这个方法存在一个缺陷，每次只有一个请求可以进入，请求处理的速度变得相当的慢，不利于系统的实时性。

方法二、使用双重校验锁：

@Service
public class NewsService {
    @Autowired
    private NewsDAO newsDAO;

    //springboot自动初始化，不需要我们进行配置，直接注入到代码中使用
    @Autowired
    private RedisTemplate<Object,Object> redisTemplate;

    //第一种方式：方法加锁
    public /*synchronized*/ List<News> getLatestNews(int userId,int offset,int limit){

        //设置序列化方式，防止乱码
        redisTemplate.setKeySerializer(new StringRedisSerializer());

        //第一步：查询缓存
        News news= (News) redisTemplate.opsForValue().get("newsKey");
        //判断是否存在缓存
        if(null == news){

            //第二种方式：双重检测锁
            synchronized (this){
                //查询数据库
                news = newsDAO.selectByUserIdAndOffset(userId,offset,limit).get(0);
                //
                redisTemplate.opsForValue().set("newsKey",news);

                System.out.println("进入数据库。。。。。。。。");
            }

        }else{
            System.out.println("进入缓存。。。。。。。。。");
        }


        return newsDAO.selectByUserIdAndOffset(userId,offset,limit);

    }
}

这个方法比较好，虽然不能保证只有一个请求请求数据库，但是当第一批请求进来，第二批之后的所有请求全部会在缓存取数据。