redis的缓存穿透、缓存击穿、缓存雪崩、并发问题解析

最新推荐文章于 2025-06-11 13:10:01 发布

猿类是匿

最新推荐文章于 2025-06-11 13:10:01 发布

阅读量192

点赞数

分类专栏：数据库文章标签： redis

数据库专栏收录该内容

2 篇文章

订阅专栏

首先明白在分布式的环境下、数据量很大非常容易出现数据库与redis数据不一致的情况
如果想要保持强一致性的数据就不要使用缓存，否则可以使用合适的的方法进行保持数据库与缓存数据一致方法如下

数据发生变换后及时更新缓存数据
缓存失败的增加重试机制

进入正题：

缓存穿透

查询请求------》缓存（key不存在）-----》数据库也没有
试想如果有人利用这一特点频繁的访问一些缓存中没有的数据就会瞬间对数据库访问量增大，那么就会造成数据库的io阻塞，雪崩等情况

方案：
如果发现没有数据就放一个空字符，并设置过期时间

缓存击穿

与缓存穿透类似，他是一个key过期了，同时访问突然增长，导致数据库异常（抢购活动、秒杀活动）

方案
加锁控制，当第一次访问时没有值，查询数据库并放入缓存
- 方案1、使用互斥锁排队

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

public String getWithLock(String key, Jedis jedis, String lockKey, String uniqueId, long expireTime) {
    // 通过key获取value
    String value = redisService.get(key);
    if (StringUtil.isEmpty(value)) {
        // 分布式锁，详细可以参考https://blog.youkuaiyun.com/fanrenxiang/article/details/79803037
        //封装的tryDistributedLock包括setnx和expire两个功能，在低版本的redis中不支持
        try {
            boolean locked = redisService.tryDistributedLock(jedis, lockKey, uniqueId, expireTime);
            if (locked) {
                value = userService.getById(key);
                redisService.set(key, value);
                redisService.del(lockKey);
                return value;
            } else {
                // 其它线程进来了没获取到锁便等待50ms后重试
                Thread.sleep(50);
                getWithLock(key, jedis, lockKey, uniqueId, expireTime);
            }
        } catch (Exception e) {
            log.error("getWithLock exception=" + e);
            return value;
        } finally {
            redisService.releaseDistributedLock(jedis, lockKey, uniqueId);
        }
    }
    return value;
}

这样做思路比较清晰，也从一定程度上减轻数据库压力，但是锁机制使得逻辑的复杂度增加，吞吐量也降低了，有点治标不治本。

方案2、接口限流与熔断、降级

重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些服务不可用时候，进行熔断，失败快速返回机制。

方案3、布隆过滤器

bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。

缓存雪崩

缓存中key同时过期，恰好面临高并发查询，而缓存中的数据突然消失导致又去访问数据，导致数据库异常，发生雪崩

方案：
- 方案1、也是像解决缓存穿透一样加锁排队，实现同上;

方案2、建立备份缓存，缓存A和缓存B，A设置超时时间，B不设值超时时间，先从A读缓存，A没有读B，并且更新A缓存和B缓存;

方案3、设置缓存超时时间的时候加上一个随机的时间长度，比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟，酱紫可从一定程度上避免雪崩问题；
(四)缓存并发问题
这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行，具体的代码就不上了，当然加锁也是可以的，至于为什么不用redis中的事务，留给各位看官自己思考探究。

转载：https://blog.youkuaiyun.com/fanrenxiang/article/details/80542580