free life

Redis 缓存实现，缓存穿透、雪崩、击穿解决方案代码实战

文章目录

- 一、什么是缓存？
- - 1.1. 缓存的作用
  - 1.2. 缓存的成本
- 二、添加Redis缓存
- - 2.1 代码示例
- 三、缓存更新策略
- - 3.1 业务场景：
  - 3.2 主动更新策略
  - - 3.2.1 Cache Aside Pattern
    - 3.2.2 Read/Write through
    - 3.2.3 Write Back(Write behind)
  - 3.3 代码实现缓存与数据库双写一致
- 四、缓存穿透
- 五、缓存雪崩
- 六、缓存击穿
- - 6.1 互斥锁代码实现
  - 6.2 逻辑过期代码实现
- 七、Redis封装工具类
- - 7.1 方法改造

一、什么是缓存？

缓存是数据交换的缓冲区（称作Cache）,是存储数据的临时地方，一般读写性能较高。

1.1. 缓存的作用

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

1.2. 缓存的成本

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

二、添加Redis缓存

2.1 代码示例

 // 根据商铺id查询商铺信息
    @Override
    public Result queryById(Long id) {

        // 从redis查询商铺缓存
        String shopJson = stringRedisTemplate.opsForValue().get(RedisConstants.CACHE_SHOP_KEY + id);

        // 判断是否存在
        if (StrUtil.isNotBlank(shopJson)) {
            // 存在，直接返回
            Shop shop = JSONUtil.toBean(shopJson, Shop.class);
            return Result.ok(shop);
        }

        // 不存在，根据商铺id查询数据库
        Shop shop = getById(id);

        // 数据库不存在，返回错误
        if (shop == null) {
            return Result.fail("店铺不存在!");
        }
        // 存在，写入redis并返回
        stringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shop));
        return Result.ok(shop);
    }

三、缓存更新策略

\	内存淘汰	超时剔除	主动更新
说明	不同自己维护，利用Redis的内存淘汰机制，当内存不足时自动淘汰部分数据。下次查询时更新缓存	给缓存数据添加TTL时间，到期后自动剔除缓存。下次查询时更新缓存	编写业务逻辑，在修改数据库的同时，更新缓存
一致性	差	一般	好
维护成本	无	低	高

3.1 业务场景：

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

3.2 主动更新策略

3.2.1 Cache Aside Pattern

由缓存的调用者，在更新数据库的同时更新缓存

引申出三个问题：

删除缓存还是更新缓存？

更新缓存：每次更新数据库都更新缓存，无效写操作较多。（不可取）
删除缓存：更新数据库时让缓存失效，下次查询时再更新缓存。（可取）

如何保证缓存与数据库的操作同时成功或失败？

单体系统，将缓存与数据库操作放在一个事务
分布式系统，利用TCC等分布式事务方案

先操作缓存还是先操作数据库？

先删除缓存，再操作数据库。（会出现线程安全问题，缓存与数据库不一致）
先操作数据库，再删除缓存（会出现线程安全问题，但是几率相对于第一种方案，几率较小。所以第二种方案较为可靠。）

此处可能存在两种情况：1、线程1先更新数据库、删除缓存，线程2读取缓存，缓存不存在，读取数据库更新缓存。
2、线程2读取缓存，缓存正好失效，读取数据库，读取到数据库更新前的脏值，线程1开始更新数据库，删除缓存，线程2更新缓存为更新操作前的脏值，导致数据库与缓存值不一致，产生线程安全问题。

（数据一致）

（数据不一致）

缺陷：

首次请求数据一定不在Cache中的问题

解决方法：可以将热点数据提前写入cache中

写操作比较频繁的话，会导致Cache中的数据会被频繁的删除，会影响缓存命中率。

解决办法：

1、数据库和缓存数据强一致场景：更新DB的时候同样更新cache，不过我们需要加一个锁/分布式锁来保证更新cache的时候不存在的线程安全问题。

2、可以短暂地允许数据库和缓存数据不一致的场景：更新DB的时候同样更新cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。

3.2.2 Read/Write through

核心策略:以缓存为操作为主,数据存先存在于缓存,缓存的数据是不会过期的。

Read Through：先查询缓存中数据是否存在，如果存在则直接返回，如果不存在，则由缓存组件负责从数据库中同步加载数据。

**Write Through：**先查询要写入的数据在缓存中是否已经存在，如果已经存在，则更新缓存中的数据，并且由缓存组件同步更新到数据库中，如果缓存中数据不存在，我们把这种情况叫做Write Miss(写失效)，图中以Write allocate方式。

**Write Miss解决方式：**一个是“Write Allocate(按写分配)”，做法是写入缓存相应位置，再由缓存组件同步更新到数据库中，图中就是指的是这种方式；另一个是“No- write allocate(不按写分配)”，做法是不写入缓存中，而是直接更新到数据库中。

适用场景：

用于读操作较多，相较于Cache aside而言更适合缓存一致的场景。
使用简单屏蔽了底层数据库的操作，只是操作缓存。
这种方式其实可以以Redis为存储，对数据的持久性要求较低的。

3.2.3 Write Back(Write behind)

Write back是相较于Write Through而言的一种异步回写策略。
异步写可以减少与物理磁盘存储的交互，也可以进行合并写等优化。

问题： 实现比较复杂,可能会丢失数据。

适用场景：

用于读少写多的场景，Linux系统的页缓存和MySQL InnoDB 引擎的Cache Pool其实就是使用的WriteBack策略。
相较于Write through 而言拥有更高的写入性能。

3.3 代码实现缓存与数据库双写一致

根据id查询店铺信息，写入缓存，并设置过期时间

    @Override
    public Result queryById(Long id) {

        // 从redis查询商铺缓存
        String shopJson = stringRedisTemplate.opsForValue().get(RedisConstants.CACHE_SHOP_KEY + id);

        // 判断是否存在
        if (StrUtil.isNotBlank(shopJson)) {
            // 存在，直接返回
            Shop shop = JSONUtil.toBean(shopJson, Shop.class);
            return Result.ok(shop);
        }

        // 不存在，根据商铺id查询数据库
        Shop shop = getById(id);

        // 数据库不存在，返回错误
        if (shop == null) {
            return Result.fail("店铺不存在!");
        }
        // 存在，写入redis并返回
        stringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shop), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
        return Result.ok(shop);
    }

修改店铺信息，并删除缓存，添加事务处理

    @Override
    @Transactional
    public Result update(Shop shop) {
        Long id = shop.getId();
        if (id == null) {
            return Result.fail("店铺id不能为空");
        }

        // 更新数据库
        updateById(shop);
        // 删除缓存
        stringRedisTemplate.delete(RedisConstants.CACHE_SHOP_KEY + id);

        return Result.ok();
    }

四、缓存穿透

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

常见的解决方案有两种：

缓存空对象
- 优点：实现简单，维护方便
- 缺点：
  - 额外的内存消耗
  - 可能造成短期的不一致（比如查询某key时，缓存不存在，数据库不存在，设置了空值，后续真正插入了一条该key的值，在空对象缓存未过期时，就造成了短期的不一致）

布隆过滤
- 优点：内存占用较少，没有多余key
- 缺点：
  - 实现复杂
  - 存在误判可能
增加id的复杂度，避免被猜测id规律
做好数据的基础格式校验
加强用户权限校验
做好热点参数的限流

代码示例：缓存空对象

 @Override
 public Result queryById(Long id) {

        // 从redis查询商铺缓存
        String shopJson = stringRedisTemplate.opsForValue().get(RedisConstants.CACHE_SHOP_KEY + id);

        // 判断是否存在
        if (StrUtil.isNotBlank(shopJson)) {
            // 存在，直接返回
            Shop shop = JSONUtil.toBean(shopJson, Shop.class);
            return Result.ok(shop);
        }

        // 判断命中的是否为空值
        if (shopJson == null) {
            // 返回一个错误信息
            return Result.fail("店铺信息不存在！");
        }

        // 不存在，根据商铺id查询数据库
        Shop shop = getById(id);

        // 数据库不存在，返回错误
        if (shop == null) {

            // 将空值写入redis，避免缓存穿透
            // 返回错误信息
            stringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, "", RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
            return Result.fail("店铺不存在!");
        }
        // 存在，写入redis并返回
        stringRedisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shop), RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
        return Result.ok(shop);
    }

五、缓存雪崩

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

解决方案：

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

六、缓存击穿

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