乐趣区

关于redis:Redis-缓存的三大问题及其解决方案

Redis 常常用于零碎中的缓存(MySQL 与 Redis 缓存的同步计划),这样能够解决目前 IO 设施无奈满足互联网利用海量的读写申请的问题。

一、缓存穿透

缓存穿透是指缓存和数据库中都没有的数据,而用户一直发动申请,如发动 id 为 - 1 的数据或者特地大的不存在的数据。有可能是黑客利用破绽攻打从而去压垮利用的数据库。

1. 常见解决方案

对于缓存穿透问题,常见的解决方案有以下三种:

  • 验证拦挡:接口层进行校验,如鉴定用户权限,对 ID 之类的字段做根底的校验,如 id<= 0 的字段间接拦挡;
  • 缓存空数据:当数据库查问到的数据为空时,也将这条数据进行缓存,但缓存的有效性设置得要较短,免得影响失常数据的缓存;
public Student getStudentsByID(Long id) {
    
    // 从 Redis 中获取学生信息
    Student student = redisTemplate.opsForValue()
        .get(String.valueOf(id));
    if (student != null) {return student;}
    
    // 从数据库查问学生信息,并存入 Redis
    student = studentDao.selectByStudentId(id);
    if (student != null) {redisTemplate.opsForValue()
            .set(String.valueOf(id), student, 60, TimeUnit.MINUTES);
    } else {
        // 即便不存在,也将其存入缓存中
        redisTemplate.opsForValue()
            .set(String.valueOf(id), null, 60, TimeUnit.SECONDS);
    }
    
    return student;
}
  • 应用布隆过滤器:布隆过滤器是一种比拟独特数据结构,有肯定的误差。当它指定一个数据存在时,它不肯定存在,然而当它指定一个数据不存在时,那么它肯定是不存在的。
2. 布隆过滤器

布隆过滤器是一种比拟非凡的数据结构,有点相似与 HashMap,在业务中咱们可能会通过应用 HashMap 来判断一个值是否存在,它能够在 O(1)工夫复杂度内返回后果,效率极高,然而受限于存储容量,如果可能须要去判断的值超过亿级别,那么 HashMap 所占的内存就很可观了。

而 BloomFilter 解决这个问题的计划很简略。首先用多个 bit 位去代替 HashMap 中的数组,这样的话贮存空间就下来了,之后就是对 Key 进行屡次哈希,将 Key 哈希后的值所对应的 bit 地位为 1。

当判断一个元素是否存在时,就去判断这个值哈希进去的比特位是否都为 1,如果都为 1,那么可能存在,也可能不存在(如下图 F)。然而如果有一个 bit 位不为 1,那么这个 Key 就必定不存在。

留神:BloomFilter 并不反对删除操作,只反对增加操作。这一点很容易了解,因为你如果要删除数据,就得将对应的 bit 地位为 0,然而你这个 Key 对应的 bit 位可能其余的 Key 也对应着。

3. 缓存空数据与布隆过滤器的比拟

上面对这两种计划都进行了简略的介绍,缓存空数据与布隆过滤器都能无效解决缓存穿透问题,但应用场景有着些许不同;

  • 当一些歹意攻打查问查问的 key 各不相同,而且数量巨多,此时缓存空数据不是一个好的解决方案。因为它须要存储所有的 Key,内存空间占用高。并且在这种状况下,很多 key 可能只用一次,所以存储下来没有意义。所以对于这种状况而言,应用布隆过滤器是个不错的抉择;
  • 而对与空数据的 Key 数量无限、Key 反复申请效率较高的场景而言,能够抉择缓存空数据的计划。

二、缓存击穿

缓存击穿是指以后热点数据存储到期时,多个线程同时并发拜访热点数据。因为缓存刚过期,所有并发申请都会到数据库中查问数据。

解决方案
  • 将热点数据设置为永不过期;
  • 加互斥锁:互斥锁能够管制查询数据库的线程拜访,但这种计划会导致系统的吞吐量降落,须要依据理论状况应用。
public String get(key) {String value = redis.get(key);
    if (value == null) { // 代表缓存值过期
        // 设置 3min 的超时,避免 del 操作失败的时候,下次缓存过期始终不能 load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  // 代表设置胜利
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        } else {  // 这个时候代表同时候的其余线程曾经 load db 并回设到缓存了,这时候重试获取缓存值即可
            sleep(50);
            get(key);  // 重试
        }
    } else {return value;}
}

三、缓存雪崩

缓存雪崩产生有几种状况,比方大量缓存集中在或者缓存同时在大范畴中生效,呈现了大量申请去拜访数据库,从而导致 CPU 和内存过载,甚至停机。

一个简略的雪崩过程:

  • Redis 集群产生了大面积故障;
  • 缓存失败,此时仍有大量申请去拜访 Redis 缓存服务器;
  • 在大量 Redis 申请失败后,这些申请将会去拜访数据库;
  • 因为利用的设计依赖于数据库和 Redis 服务,很快就会造成服务器集群的雪崩,最终导致整个零碎的瘫痪。
解决方案

【事先】高可用缓存:高可用缓存是防止出现整个缓存故障。即便个别节点,机器甚至机房都敞开,零碎依然能够提供服务,Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都能够做到高可用;

【事中】缓存降级(长期反对):当拜访次数急剧减少导致服务呈现问题时,咱们如何确保服务依然可用。在国内应用比拟多的是 Hystrix,它通过熔断、降级、限流三个伎俩来升高雪崩产生后的损失。只有确保数据库不死,零碎总能够响应申请,每年的春节 12306 咱们不都是这么过去的吗?只有还能够响应起码还有抢到票的机会;

【预先】Redis 备份和疾速预热:Redis 数据备份和复原、疾速缓存预热。

作者:周二鸭
起源:https://www.cnblogs.com/jojop…

退出移动版