你的数据库真的穿“防弹衣”了吗

Posted 2022-05-18 苏州程序大白

你的数据库真的穿“防弹衣”了吗

• ✨博主介绍
• 前言
• • 看一段示例代码
  • 解决缓存击穿的方法
  • 方法二
  • 方法三
  • 方法四
• 💫点击直接资料领取💫

✨博主介绍

🌊 作者主页：苏州程序大白

🌊 作者简介：🏆CSDN人工智能域优质创作者🥇，苏州市凯捷智能科技有限公司创始之一，目前合作公司富士康、歌尔等几家新能源公司

💬如果文章对你有帮助，欢迎关注、点赞、收藏

💅 有任何问题欢迎私信，看到会及时回复
💅关注苏州程序大白，分享粉丝福利

前言

华强来到一家程序员商店买缓存，问程序员：“你这缓存保熟吗？” …

缓存经常被用来减少数据库访问量，以此来提高系统性能，承受更多的并发请求，就像“防弹衣”一样保护着数据库，防止被一颗颗“请求子弹”击中。
但引入缓存，也带来了一些新的问题，比如缓存击穿、缓存穿透、缓存雪崩、缓存数据一致性等问题。今天来聊聊缓存击穿，百度一搜有很多相关的文章，但按照网上的一些教程去解决缓存击穿，真的可以保证这一“防弹衣”不被击穿吗？

看一段示例代码

public ResponseDTO getRoleById(Long id) throws Exception 
    String key = "User:Role:" + id;
    List<Long> data = (List<Long>) redisUtil.get(key);
    if (data == null) 
        data = userMapper.selectRoleIdByUserId(id);
        Long buffTime = (long) new Random().nextInt(30) * 60;
        redisUtil.set(key, data, buffTime);
    
    return new ResponseDTO(Status.SUCCESS.code, "", data);

这段代码使用redis做了缓存，只要缓存中有数据就不会去查数据库，但如果缓存中没数据，这时又恰好又大量请求来袭，那这些请求就会去访问数据库，如果并发请求量很大，数据库就有可能被打死，这就是缓存击穿。

解决思路也很简单，只让一个请求去查数据库然后更新缓存，其他请求先等着，等查数据库的兄弟更新完缓存我再去查缓存。具体实现也很容易，加个锁不就好了。那一起来看看接下来这几段代码。

解决缓存击穿的方法

public ResponseDTO getRoleById(Long id) throws Exception 
    String key = "User:Role:" + id;
    List<Long> data = (List<Long>) redisUtil.get(key);
    boolean isLock = false;
    ReentrantLock lock = new ReentrantLock();
    try 
        if (data == null) 
            if (lock.tryLock()) 
                isLock = true;
                data = userMapper.selectRoleIdByUserId(id);
                Long buffTime = (long) new Random().nextInt(30) * 60;
                redisUtil.set(key, data, buffTime);
             else 
                Thread.sleep(100); // 此处仅为例子，具体由实际查询情况定，也可以循环查询几次
                data = (List<Long>) redisUtil.get(key);
            
        
    
    finally 
        if (isLock)
            lock.unlock();
    
    return new ResponseDTO(Status.SUCCESS.code, "", data);

这个解决方案完全是一种错误的方案，因为这里的锁，锁了个寂寞。

锁是为了解决多线程问题的，即多个线程争用一把锁，谁抢到了谁用，但在SpringMVC中，一个请求就会建立一个线程，把锁定义在方法中（ReentrantLock lock = … 那行代码），那不就是一个线程一把锁，我和自己抢，然后我锁我自己吗，锁了个寂寞。所以这种方法无法防止缓存击穿。

方法二

把锁拿到外面定义并实例化，这样就能做到所有线程用一把锁。

static ReentrantLock lock = new ReentrantLock();
@Override
public ResponseDTO getRoleById(Long id) throws Exception 
    String key = "User:Role:" + id;
    List<Long> data = (List<Long>) redisUtil.get(key);
    boolean isLock = false;
    try 
        if (data == null) 
            if (lock.tryLock()) 
                isLock = true;
                data = userMapper.selectRoleIdByUserId(id);
                Long buffTime = (long) new Random().nextInt(30) * 60;
                // Thread.sleep(90);  // 模拟用
                redisUtil.set(key, data, buffTime);
             else 
                Thread.sleep(100);  // 此处仅为例子，具体由实际查询情况定，也可以循环查询几次
                data = (List<Long>) redisUtil.get(key);
            
        
    
    finally 
        if (isLock)
            lock.unlock();
    
    return new ResponseDTO(Status.SUCCESS.code, "", data);

这样看着可行，但又有了新问题，如果有两个并发请求，请求A和请求B，A和B请求参数不同，即想要得到的数据也不同，并且此时缓存中也没有A、B想要的数据，于是去查数据库，假设此时A拿到了锁，正在查数据库，刚好B这时到达，因为A拿到了锁还没有释放，导致B加锁失败，于是B睡眠然后等着查缓存。这时候A查完了数据，也更完了缓存，返回了正确的数据，过了一会，B睡醒了，但缓存中依然没有B想要的数据，于是返回了null。

下面来复现一下这种情况，为了模拟这种并发情况，我们在查数据库时也Thread.sleep()一下，模拟锁还没释放，又有其他非同参的请求到达。

那使用ReentrantLock是不是无法解决缓存击穿呢，倒也不是，可以维护一个ConcurrentHashMap，以方法名和请求参数为key，如果key存在数据且无法用已经存在的锁成功加锁，说明已经有其他相同请求线程在读数据库，然后就可以睡眠，稍后去读缓存，如果没有数据，则新建一把锁，加锁后读数据库、刷缓存。

方法三

用synchronized关键字加锁。

public ResponseDTO getRoleById(Long id) throws Exception 
    String key = "User:Role:" + id;
    List<Long> data = (List<Long>) redisUtil.get(key);
   if(data == null) 
       synchronized (this) 
            data = (List<Long>) redisUtil.get(key);
            if(data != null) 
                return new ResponseDTO(Status.SUCCESS.code, "", data);
            
            data = userMapper.selectRoleIdByUserId(id);
            Long buffTime = (long) new Random().nextInt(30) * 60;
            redisUtil.set(key, data, buffTime);
        
   
    return new ResponseDTO(Status.SUCCESS.code, "", data);

这种方法可以解决缓存击穿问题，但会影响系统性能。比如此时缓存中无数据，然后有1000个请求同时到来，然后这1000个线程开始争夺锁，一个加锁成功，去查了数据库，更新缓存，剩下999个在等待锁释放再抢锁，然后此时即使缓存有数据，这999个也是挨个加锁、读缓存，变成了一种串行执行，而不是并行读缓存。只有接下来到达的其他请求，才是并行去读取缓存。

方法四

使用分布式锁。（个人认为这才是最佳解决方案）

public ResponseDTO getRoleById(Long id) throws Exception 
    String key = "User:Role:" + id;
    List<Long> data = (List<Long>) redisUtil.get(key);
   if(data == null) 
       // 加锁，并设置过期时间为 30s，即超过30s自动解锁
       if(redisUtil.setNx("getRoleById:" + id, 30L)) 
           data = userMapper.selectRoleIdByUserId(id);
           Long buffTime = (long) new Random().nextInt(30) * 60;
           redisUtil.set(key, data, buffTime);
           redisUtil.remove("getRoleById:"+id); // 解锁
        else 
           // 轮询五次，每次间隔 100 ms  此处为例子，具体策略有具体情况定
           int count = 0;
           while(data == null && count < 5) 
                Thread.sleep(100);
                data = (List<Long>) redisUtil.get(key);
                count++;
           
       
   
    return new ResponseDTO(Status.SUCCESS.code, "", data);

这种类似于ReentrantLock + ConcurrentHashMap解决方案，不同类请求加不同锁，同类请求加锁失败就等待读缓存。既保证了缓存无数据时到达的请求可以并发访问更新后的缓存，又保证了不同参数的请求能读到正确数据。

如果是单机部署，可以使用synchronized或者ReentrantLock + ConcurrentHashMap解决，但用synchronized会导致部分请求串行，性能较低。

如果要分布式部署，使用单机锁也可以，毕竟部署几十台几百台，这点并发量数据库还是扛得住的，但显然使用分布式锁更合适。

如果目前是单机部署，但考虑到未来可能会分布式部署，用redis做了缓存，那就用分布式锁吧，毕竟欠下的技术债，总归是要还的。

💫点击直接资料领取💫

❤️关注苏州程序大白公众号❤️

👇 👇👇