Redis场景问题

集群的Session共享问题

session共享问题：多台Tomcat并不共享session存储空间，当请求切换到不同tomcat服务时导致数据丢失的问题。
session的替代方案应该满足：
•数据共享
•内存存储
•key、value结构

所以我们基于Redis实现共享session登录

流程图

• 这里的token用于替代session，session的一些处理都是tomcat处理的，所以我们还需要对token做一些处理。

1. 设置token30分钟后消失，当请求的时候需要重新设置30分钟。
2. 设置拦截器，拦截所有用户请求，将token的ttl重新设置成30min，放行

缓存

什么是缓存

缓存就是数据交换的缓冲区（称作Cache [ kæʃ ] ），是存贮数据的临时地方，一般读写性能较高。

缓存的作用：

• • 降低后端负载
  • 提高读写效率，降低响应时间

缓存的成本：

• • 数据一致性成本
  • 代码维护成本
  • 运维成本

添加缓存

@Override
  public Result queryShopList() {
    String listShop = "shop:list";
    //查询缓存
    List values = stringRedisTemplate.opsForHash().values(listShop);
    //缓存命中
    if(!values.isEmpty()){
      ArrayList<ShopType> shopTypes = new ArrayList<>();
      for(Object str:values){
        shopTypes.add(JSONUtil.toBean((String)str,ShopType.class));
      }
      return Result.ok(shopTypes);
    }
    //缓存未命中
    List<ShopType> typeList =
        query().orderByAsc("sort").list();
    //数据库没有这条记录（这里可以设置缓存空对象，防止缓存穿透后面会有）
    if (typeList==null) {
      return Result.fail("暂无店铺");
    }
    //找到数据写入缓存
    for(ShopType temp : typeList){
      stringRedisTemplate.opsForHash().put(listShop,temp.getId().toString(),JSONUtil.toJsonStr(temp));
    }
    //返回
    return Result.ok(typeList);
  }

缓存更新策略

• 业务场景：
  • 低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存
  • 高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存
    

在更新数据库的同时更新缓存是较好的方案

删除缓存也需要考虑是先删除缓存还是先更新数据库？
场景一：先删除缓存在更新数据库

• 如果在删除缓存之后，更新数据库之前另一个请求来访问，发现缓存未命中，就会访问数据库，并且将查询的数据写入缓存，这就会造成旧数据又被写入到缓存中，下次访问还会找到旧的数据。

场景二：先更新数据库

• 当查询的时候发现未命中，准备把查询的数据写入缓存的时候，开始更新数据，先更新数据库，在删除缓存，之后又被之前的线程重新覆盖成了旧数据。
  但是这个发生的概率非常小，查询并写入数据库的比较快。

缓存更新策略的最佳实践方案：

1. 低一致性需求：使用Redis自带的内存淘汰机制
2. 高一致性需求：主动更新，并以超时剔除作为兜底方案
   • 读操作：
     • 缓存命中则直接返回
     • 缓存未命中则查询数据库，并写入缓存，设定超时时间
   • 写操作：
     • 先写数据库，然后再删除缓存
     • 要确保数据库与缓存操作的原子性

缓存穿透

缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。

常见的解决方案有两种：

• 缓存空对象
  • 优点：实现简单，维护方便
  • 缺点：
    • 额外的内存消耗
    • 可能造成短期的不一致
• 布隆过滤
  • 优点：内存占用较少，没有多余key
  • 缺点：
    • 实现复杂
    • 存在误判可能

解决缓存穿透流程图

public Shop queryWithPassThrough(Long id) {
    String shopId = CACHE_SHOP_KEY+id;
    String info = stringRedisTemplate.opsForValue().get(shopId);
    if (StrUtil.isNotBlank(info)){
      //找到信息
      Shop shop = JSONUtil.toBean(info, Shop.class);
      return shop;
    }
    if(info!=null){
      return null;
    }
    //未找到
    Shop shop = getById(id);
    if(shop==null){
      //防止缓存穿透
      stringRedisTemplate.opsForValue().set(shopId,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
      return null;
    }
    stringRedisTemplate.opsForValue().set(shopId,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL,TimeUnit.MINUTES);
    return shop;
  }

缓存穿透产生的原因是什么？

• 用户请求的数据在缓存中和数据库中都不存在，不断发起这样的请求，给数据库带来巨大压力

缓存穿透的解决方案有哪些？

• 缓存null值
• 布隆过滤
• 增强id的复杂度，避免被猜测id规律
• 做好数据的基础格式校验
• 加强用户权限校验
• 做好热点参数的限流

缓存雪崩

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

解决方案：

• 给不同的Key的TTL添加随机值
• 利用Redis集群提高服务的可用性
• 给缓存业务添加降级限流策略
• 给业务添加多级缓存

缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

常见的解决方案有两种：

• 互斥锁
• 逻辑过期

互斥锁：

逻辑过期：

二者优缺点：

互斥锁：这里的互斥锁和java中的互斥锁是不一样的，java的互斥锁，没有获得锁会发生进程等待，但是这里的锁如果没有获得需要继续执行把旧数据返回。可以使用redis中的setnx key val（当key不存在的时候才能写入）对应的StringRedisTemplate的函数是：

Boolean flag = stringRedisTemplate.opsForValue()
        .setIfAbsent(key, "1", 10, TimeUnit.SECONDS);

逻辑过期：是需要在存入redis的信息中增加一个过期时间，当进行查询的时候先匹配以下是否已经过期，如果过期执行缓存的重建。这样可以解决缓存击穿的问题。
我们知道原有的Shop类是没有过期时间的属性的，我们需要怎么加上这个属性呢？有两种方法：

1. 创建一个类，含有过期时间的属性，让Shop类继承这个类，这个方法的做法简单，后续取值的时候不需要进行一些修改，但是会对目标类（Shop）进行修改。
2. 创建一个类，含有过期时间的属性和Data（Object）的属性，用于存放目标类实例，这个方法不会对目标类造成修改，但是在从缓存中取数据的时候需要进行一些修改。例如以下代码实例：

String shopJson  = stringRedisTemplate.opsForValue().get(key);
/......code.etc........../
RedisData redisData = JSONUtil.tiBean(shopJson,RedisData.class);
JSONObject data = (JSONObject) redisData.getData();
Shop shop = JSONUtil.toBean(data,Shop.class);