本文介绍: 缓存雪崩是因为大量缓存数据同时过期或者 Redis 集群故障,如果因为缓存雪崩导致 Redis 集群都崩掉了,那么此时只有数据库可以访问我们系统需要可以识别出来缓存故障,立马对各个接口进行限流降级错误,来保护数据库,避免数据库崩掉,可以jvm 内存缓存存储少量缓存数据用于在 Redis 崩了之后提供降级备用数据,那么流程为:限流 –> 降级 –> jvm 缓存数据。有两个线程并发一个线程一个线程假设执行流程如下,会造成双写不一致。,在写的时候,加的是写锁,key 为。

基于社区电商的Redis缓存架构

首先来讲一下 Feed 流的含义:

Feed 流指的是当我们进入 APP 之后,APP 要做一个 Feed 行为,即主动的在 APP 内提供各种各样的内容我们

电商 APP 首页,不停在首页下拉,那么每次拉的时候,APP 就会根据你的喜好、算法来不停地展示新的内容给你看,这就是电商 APP 的 Feed 流了

那么接下来呢就基于首页 Feed 流以及社区电商 APP 中的一些业务场景,来实现一套基于 Redis 的企业级缓存架构,MySQL 为基础,RocketMQ 为辅助

那么在缓存常见问题有:

在 Redis 生产环境中,也存在一些问题如下

下边我们来逐个剖析缓存架构常见的一些问题

首先,热 key 举个例子就是微博突然某个明星出现新闻,那么会有大量请求访问这个数据这个 key 就是key

key 指的是某个 key 所存储value 很大,value 多大 10 mb,那么如果读取这个key 过于频繁,就会对网络带宽造成影响阻塞其他请求

缓存雪崩是因为大量缓存数据同时过期或者 Redis 集群故障,如果因为缓存雪崩导致 Redis 集群都崩掉了,那么此时只有数据库可以访问我们系统需要可以识别出来缓存故障,立马对各个接口进行限流、降级错误,来保护数据库,避免数据库崩掉,可以在 jvm 内存缓存中存储少量缓存数据,用于在 Redis 崩了之后提供降级备用数据,那么流程为:限流 –> 降级 –> jvm 缓存数据

读多写少数据缓存

那么我们先来分析一下在社区电商中,用户分享一个内容时,如何操作缓存:

  1. 用户分享内容
  2. 加锁针对用户 id分布式锁,避免同一用户重复请求,导致数据重复灌入
  3. 用户分享内容写入数据库
  4. 用户个人信息在缓存写一份用户信息注册后一般不会变化,读多写少,因此用户信息非常适合放入缓存中),这样在后续高并发访问用户的数据时,就可以在缓存中进行查询,根据用户前缀 + 用户 id 作为 key,并设置缓存过期时间,过期时间可以设置为 2 天加上随机几小时(添加随机几小时的原因是避免同一时间大量缓存同时过期)
  5. 释放锁

缓存自动延期以及缓存穿透

那么上边我们已经对用户的个人信息进行了缓存,那么某些热门的用户是经常被很多看到的,而有些冷门用户的内容没多少人看,因此将用户信息的缓存过期时间设置2天+随机几小时 ,因此我们针对热门的用户信息数据,要做一个缓存自动延期,因此只要访问用户数据,那么就对该缓存数据进行一个延期,流程如下

  1. 获取用户个人信息
  2. 根据 用户前缀 + 用户id 作为 key 去缓存中查询用户信息
public UserInfo getUserInfo(Integer userId) {
  // 读缓存
  String userInfoJson = redisCache.get("user_info_lock:" + userId);
  if (!StringUtils.isEmpty(userInfoJson)) {
    // 取到的是空缓存 避免一致访问数据库存在的数据导致缓存穿透
    if ("{}".equals(userInfoJson)) {
      // 延期缓存
      redisCache.expire("user_info_lock:" + userId, expireSecond);
      return null;
    } else {
      // 延期缓存
      redisCache.expire("user_info_lock:" + userId, expireSecond);
      UserInfo userInfo = JSON.parseObject(productStr, UserInfo.class);
    }
  }
  // 如果缓存中没有取到数据,则在数据库中查,并放入缓存
  lock("user_lock_prefix" + userId); // 上分布式锁 伪代码
  try {
    // 读数据库
    UserInfo userInfo = userInfoService.get(userId);
    if(userInfo != null) {
      // 如果用户信息不为空,就将用户数写入缓存
      redisCache.set("user_info_lock:" + userId, JSON.toJSONString(userInfo), expireSecond);
    } else {
      // 如果数据库为空写入一个空字符串即可
      redisCache.set("user_info_lock:" + userId, "{}", expireSecond);
    }
  } finally {
    unlock("user_lock_lock:" + userId); // 解锁
  }
}

缓存+数据库双写不一致

在上边存储用户个人信息时,使用的是 缓存+数据库双写,这样可能造成数据不一致性如下

两个线程并发,一个读线程,一个写线程假设执行流程如下,会造成双写不一致

  • 当读线程去缓存中读取数据,此时缓存中数据正好过期,那么该线程就去读数据库中的数据
  • 此时写线程开始执行,修改用户信息,并且写入数据库,再写入缓存
  • 此时读线程再接着执行,将之前在数据库中读取的旧数据写入缓存,覆盖了写线程更新后的数据

造成这种情况的原因是,在读的时候,加的是读锁,key 为 user_info_lock:,在写的时候,加的是写锁,key 为 user_update_lock:,那么读写就可以并发

想要解决的话,可以让读和写操作加同一把锁,让读写串行化,就可以了,如下

让读和写都加同一把锁:user_update_lock

那么完整的写和读操作流程下图

在这里插入图片描述

高并发场景优化

在上边我们已经使用读写加同一把锁来实现缓存数据库双写一致了

但是还存在一种极端情况:某一个用户的信息并不在缓存中,但是突然火了,大量用户来访问,发现缓存中没有,那么大量用户线程就阻塞在了获取锁的这一步操作上,导致大量线程串行化的来获取锁,然后再到缓存中获取数据,下一个线程再获取锁取数

这种情况的解决方案就是给获取锁加一超时时间,如果在 200ms没有拿到锁,就算获取锁失败,这样大量用户线程获取锁失败,就会从串行再转为并发从缓存中取数据了,避免大量线程阻塞获取锁

完整流程图如下,粉色部分优化

在这里插入图片描述

代码如下:

private UserInfo getUserInfo(Long userId) {
    String userLockKey = "user_update_lock:" + userId;
    boolean lock = false;
    try {
        // 尝试加锁,并设置超时时间为 200 ms
        lock = redisLock.tryLock("user_update_lock:", 200);
    } catch(InterruptedException e) {
        UserInfo user = getFromCache(userId);
        if(user != null) {
            return user;
        }
        log.error(e.getMessage(), e);
        throw new BaseBizException("查询失败");
    }
    // 如果加锁超时,就再次去缓存中查询
    if (!lock) {
        UserInfo user = getFromCache(userId);
        if(user != null) {
            return user;
        }
        // 缓存数据为空,查询用户信息失败,因为用户没有拿到锁,因此也无法取 DB 中查询
        throw new BaseBizException("查询失败");
    }
    // 双端检锁,如果拿到锁,再去缓存中查询
    try {
        UserInfo user = getFromCache(userId);
        if(user != null) {
            return user;
        }
        String userInfoKey = "user_info:" + userId;
        // 数据库中查询
        user = userService.getById(userId);
        if (Objects.isNull(user)) {
            redisCache.set(userInfoKey, "{}", RandomUtil.genRandomInt(30, 100));
            return null;
        }
        // 缓存时间设置为 2 天 + 随机几小时
        redisCache.set(userInfoKey, JSON.toJSONString(user), 2 * 24 * 60 * 60RandomUtil.genRandomInt(0, 10) * 60 * 60);
        return user;
    } finally {
        redisLock.unlock(userLockKey);
    }

原文地址:https://blog.csdn.net/qq_45260619/article/details/134689202

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_49791.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注