Redis 缓存问题详解

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: Redis 缓存问题详解

缓存穿透

  • 缓存穿透指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库
  • 如果有恶意用户使用无数的线程并发访问不存在数据,这些请求都会到达数据库,很有可能会将数据库击垮

解决方案

缓存空对象

  • 思路:用户请求某一个 id 时,redis 和数据库中都不存在,我们直接将 id 对应空值缓存到 redis,这样下次用户重复请求这一 id 时,redis 中就可以命中(命中 null),就不会去请求数据库
  • 优点:实现简单,维护方便
  • 缺点:

    • 额外的内存消耗(可以通过添加 TTL 解决)

-  可能造成短期的不一致(控制 TTL 时间一定程度可以缓解):当缓存了 null 的时候,我们正好在数据库中设置了值,用户查询到的为 null,但是数据库中实际存在,这就会造成不一致(插入数据时自动覆盖之前的 null 数据可解决)

布隆过滤

  • 在客户端和 redis 之间加一层 布隆过滤器,当用户访问时,首先有布隆过滤器判断数据是否存在,若不存在,直接拒绝;若存在,正常流程处理即可
  • 布隆过滤器如何判断数据是否存在?

    • 布隆过滤器可以简单理解为 byte 数组,存储二进制位,当要判断数据库中数据是否存在时,并不是直接将数据存储到布隆过滤器,而是通过哈希算法计算出哈希值,再将这些哈希值转换为二进制位保存到布隆过滤器中。判断数据是否存在时,判断对应位置是 0/1 即可(这种存在与否是一种概率上的统计,并不是 100% 准确,因此 不存在真的不存在,存在不一定存在,所以仍存在穿透风险)
  • 优点:内存占用少,没有多余 key(二进制)
  • 缺点:

    • 实现复杂
    • 存在误判可能(不一定准确)

缓存空对象 Java 实现

/**
 * 缓存穿透
 *
 * @param id
 * @return
 */
public Shop queryWithPassThrough(Long id) {
    String key = CACHE_SHOP_KEY + id;
    // 1.从redis查询商铺缓存
    String shopJson = stringRedisTemplate.opsForValue().get(key);
    // 2.判断是否存在
    if (StrUtil.isNotBlank(shopJson)) {
        // 3.存在,直接返回
        return JSONUtil.toBean(shopJson, Shop.class);
    }
    // 判断命中的是否是空值
    if (shopJson != null) {
        // 返回一个错误信息
        return null;
    }
    // 4.不存在,根据id查询数据库
    Shop shop = getById(id);
    // 5.不存在,返回错误
    if (shop == null) {
        // 将空值写入 redis(缓存穿透)
        stringRedisTemplate.opsForValue().set(key, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
        return null;
    }
    // 6.存在,写入redis
    stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), CACHE_SHOP_TTL, TimeUnit.MINUTES);
    // 7.返回
    return shop;
}

缓存雪崩

  • 缓存雪崩是指在同一时段大量的缓存 key 同时失效或者 Redis 服务宕机,导致大量请求到达数据库,带来巨大压力

  • 解决方案

    • 给不同的 key 的 TTL 添加随机值(解决同时失效问题):比如在做缓存预热时,需要将数据库中的数据提前批量导入到缓存中,由于在同一时间导入,这些数据的 TTL 值相同,这就可能会导致在某一时刻这些数据同时过期,就会出现雪崩。为了解决这个问题,我们在导入时可以给 TTL 加一个随机数(比如 TTL 为 30±1~5 ),这样这些 key 的过期时间就会分散在一个时间段内,而不是同时失效,从而避免雪崩发生
    • 利用 Redis 集群提高服务的可用性(解决 Redis 宕机):借助 Redis 哨兵机制,有一个机器宕机时,哨兵可以自动选一个机器替代宕机机器,同时主从可以实现数据同步,从而确保 Redis 的高可用
    • 给缓存业务添加降级限流策略:比如快速失败,拒绝服务,避免请求压入数据库
    • 给业务添加多级缓存:浏览器可以添加缓存(一般是静态资源),反代服务器 Nginx 可以添加缓存,Nginx 缓存未命中再去请求 Redis,Redis 缓存未命中到达 JVM,JVM 内部还可以建立本地缓存,最后达到数据库

缓存击穿

  • 缓存击穿问题 也叫热点 key 问题,就是一个被 高并发访问 并且 缓存重建业务较复杂 的 key 突然失效了,无数的请求访问会在瞬间给数据库带来巨大的冲击
缓存重建:redis 中的缓存在到期后就会失效,失效后需要重新从数据库中查询写入 redis。从数据库中查询并构建数据这一过程可能比较复杂,需要进行多表联查等,最终得到结果缓存起来。这一业务可能耗时比较长(几十甚至数百毫秒),在这一时间段内,redis 中一直没有缓存,到达的请求都会未命中去访问数据库

解决方案

互斥锁

  • 线程请求时发现未命中,在查询数据库前进行加锁操作,等到写入缓存后再释放锁。这样有其他线程未命中时,在查询数据库也会去获取互斥锁,获取失败后休眠一段时间后重新查询即可
  • 显然,只有写入缓存后其他线程才能获取到数据,虽然能保证一致性,但性能比较差,还有可能造成死锁

  • Java 实现

/**
 * 获取锁
 *
 * @param key
 * @return
 */
private boolean tryLock(String key) {
    Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", LOCK_SHOP_TTL, TimeUnit.SECONDS);
    return BooleanUtil.isTrue(flag);
}


/**
 * 释放锁
 *
 * @param key
 */
private void unlock(String key) {
    stringRedisTemplate.delete(key);
}


/**
 * 互斥锁
 *
 * @param id
 * @return
 */
public Shop queryWithMutex(Long id) {
    String key = CACHE_SHOP_KEY + id;
    // 1.从redis查询商铺缓存
    String shopJson = stringRedisTemplate.opsForValue().get(key);
    // 2.判断是否存在
    if (StrUtil.isNotBlank(shopJson)) {
        // 3.存在,直接返回
        return JSONUtil.toBean(shopJson, Shop.class);
    }
    // 判断命中的是否是空值
    if (shopJson != null) {
        // 返回一个错误信息
        return null;
    }

    // 4. 实现缓存重建
    // 4.1 获取互斥锁
    String lockKey = LOCK_SHOP_KEY + id;
    Shop shop = null;
    try {
        boolean isLock = tryLock(lockKey);
        // 4.2 判断是否获取成功
        if (!isLock) {
            // 4.3 失败,则休眠并重试
            Thread.sleep(50);
            // 递归
            return queryWithMutex(id);
        }
        // 4.4 成功,根据 id 查询数据库
        shop = getById(id);
        // 模拟重建延时
        Thread.sleep(200);
        // 5.不存在,返回错误
        if (shop == null) {
            // 将空值写入 redis(缓存穿透)
            stringRedisTemplate.opsForValue().set(key, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
            return null;
        }
        // 6.存在,写入redis
        stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), CACHE_SHOP_TTL, TimeUnit.MINUTES);
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    } finally {
        // 7. 释放互斥锁
        unlock(lockKey);
    }
    // 8.返回
    return shop;
}
  • 我们使用 jmeter 测试一下,发送 1000 次请求,可以看到所有的请求都是通过,并且数据库仅进行了一次查询


逻辑过期

  • 顾名思义,并不是真正的过期,可以看作是永不过期。当我们向 redis 中缓存数据时不设置 TTL,在存储数据时添加一个过期时间字段(并非TTL,当前时间基础上+过期时间,逻辑上维护的时间),这样一来任何线程来查询时都可以命中,只需要逻辑上判断是否过期即可
  • 如下图,若线程1来查询缓存时发现逻辑时间已经过期,就需要重建缓存,然后获取互斥锁,为了避免发生获取锁等待时间过长的问题,线程1会开启一个新的线程(线程2)来代替自己进行缓存重建操作,缓存重建完成后再释放锁,而线程1直接返回过期的数据。当其他线程也未命中的时候,获取互斥锁失败会直接返回过期数据。这样性能上虽然有保证,但一致性无法保证

  • Java 实现
/**
 * 缓存预热
 *
 * @param id
 * @param expireSeconds 逻辑过期时间
 */
public void saveShop2Redis(Long id, Long expireSeconds) throws InterruptedException {
    // 1. 查询店铺数据
    Shop shop = getById(id);
    Thread.sleep(200);
    // 2. 封装逻辑过期时间
    RedisData redisData = new RedisData();
    redisData.setData(shop);
    redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));
    // 3. 写入redis
    stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData));
}

private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);

/**
 * 逻辑过期
 *
 * @param id
 * @return
 */
public Shop queryWithLogicalExpire(Long id) {
    String key = CACHE_SHOP_KEY + id;
    // 1.从redis查询商铺缓存
    String shopJson = stringRedisTemplate.opsForValue().get(key);
    // 2.判断是否存在
    if (StrUtil.isBlank(shopJson)) {
        // 3.未命中,直接返回
        return null;
    }
    // 4. 命中,需要先把json反序列化为对象
    RedisData redisData = JSONUtil.toBean(shopJson, RedisData.class);
    Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);
    LocalDateTime expireTime = redisData.getExpireTime();
    // 5. 判断是否过期
    if (expireTime.isAfter(LocalDateTime.now())) {
        // 5.1 未过期,直接返回店铺信息
        return shop;
    }
    // 5.2 已过期,需要缓存重建
    // 6. 缓存重建
    // 6.1 获取互斥锁
    String lockKey = LOCK_SHOP_KEY + id;
    boolean isLock = tryLock(lockKey);
    // 6.2 判断是否获取锁成功
    if (isLock) {
        // 6.3 成功,开启独立线程,实现缓存重建
        CACHE_REBUILD_EXECUTOR.submit(() -> {
            try {
                // 重建缓存
                this.saveShop2Redis(id, 20L);
            } catch (Exception e) {
                throw new RuntimeException(e);
            } finally {
                // 释放锁
                unlock(lockKey);
            }
        });
    }
    // 6.4 返回过期的商铺信息
    return shop;
}

对比

解决方案 优点 缺点
互斥锁 没有额外的内存消耗
保证一致性
实现简单
线程需要等待,性能受影响
可能有死锁风险
逻辑过期 线程无需等待,性能较好 不保证一致性
有额外内存消耗
实现复杂
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
5天前
|
消息中间件 缓存 NoSQL
Redis经典问题:缓存雪崩
本文介绍了Redis缓存雪崩问题及其解决方案。缓存雪崩是指大量缓存同一时间失效,导致请求涌入数据库,可能造成系统崩溃。解决方法包括:1) 使用Redis主从复制和哨兵机制提高高可用性;2) 结合本地ehcache缓存和Hystrix限流降级策略;3) 设置随机过期时间避免同一时刻大量缓存失效;4) 使用缓存标记策略,在标记失效时更新数据缓存;5) 实施多级缓存策略,如一级缓存失效时由二级缓存更新;6) 通过第三方插件如RocketMQ自动更新缓存。这些策略有助于保障系统的稳定运行。
137 1
|
8天前
|
存储 消息中间件 缓存
Redis缓存技术详解
【5月更文挑战第6天】Redis是一款高性能内存数据结构存储系统,常用于缓存、消息队列、分布式锁等场景。其特点包括速度快(全内存存储)、丰富数据类型、持久化、发布/订阅、主从复制和分布式锁。优化策略包括选择合适数据类型、设置过期时间、使用Pipeline、开启持久化、监控调优及使用集群。通过这些手段,Redis能为系统提供高效稳定的服务。
|
3天前
|
缓存 NoSQL 安全
Redis经典问题:缓存击穿
本文探讨了高并发系统中Redis缓存击穿的问题及其解决方案。缓存击穿指大量请求同一未缓存数据,导致数据库压力过大。为解决此问题,可以采取以下策略:1) 热点数据永不过期,启动时加载并定期异步刷新;2) 写操作加互斥锁,保证并发安全并设置查询失败返回默认值;3) 预期热点数据直接加缓存,系统启动时加载并设定合理过期时间;4) 手动操作热点数据上下线,通过界面控制缓存刷新。这些方法能有效增强系统稳定性和响应速度。
59 0
|
4天前
|
缓存 NoSQL 应用服务中间件
Redis多级缓存
Redis多级缓存
9 0
|
4天前
|
缓存 NoSQL 关系型数据库
Redis 缓存 一致性
Redis 缓存 一致性
7 0
|
4天前
|
缓存 监控 NoSQL
Redis经典问题:缓存穿透
本文介绍了缓存穿透问题在分布式系统和缓存应用中的严重性,当请求的数据在缓存和数据库都不存在时,可能导致数据库崩溃。为解决此问题,提出了五种策略:接口层增加校验、缓存空值、使用布隆过滤器、数据库查询优化和加强监控报警机制。通过这些方法,可以有效缓解缓存穿透对系统稳定性的影响。
86 3
|
5天前
|
缓存 NoSQL 搜索推荐
Redis缓存雪崩穿透等解决方案
本文讨论了缓存使用中可能出现的问题及其解决方案。首先,缓存穿透是指查询数据库中不存在的数据,导致请求频繁到达数据库。解决方法包括数据校验、缓存空值和使用BloomFilter。其次,缓存击穿是大量请求同一失效缓存项,可采取监控、限流或加锁策略。再者,缓存雪崩是大量缓存同时失效,引发数据库压力。应对措施是避免同一失效时间,分散缓存过期。接着,文章介绍了Spring Boot中Redis缓存的配置,包括缓存null值以防止穿透,并展示了自定义缓存过期时间的实现,以避免雪崩效应。最后,提供了在`application.yml`中配置不同缓存项的个性化过期时间的方法。
|
6月前
|
缓存 NoSQL 安全
Redis缓存雪崩、击穿、穿透解释及解决方法,缓存预热,布隆过滤器 ,互斥锁
Redis缓存雪崩、击穿、穿透解释及解决方法,缓存预热,布隆过滤器 ,互斥锁
190 5
|
7月前
|
缓存 NoSQL 数据库
Redis学习笔记-如何应对缓存雪崩、击穿、穿透
Redis学习笔记-如何应对缓存雪崩、击穿、穿透
38 0
|
存储 缓存 NoSQL
Redis --- 缓存雪崩、击穿、穿透与数据库缓存双一致性
Redis --- 缓存雪崩、击穿、穿透与数据库缓存双一致性
Redis --- 缓存雪崩、击穿、穿透与数据库缓存双一致性