Redis实战篇（二：商户查询缓存）

目录

 

三、商户查询缓存

1.缓存介绍

2.添加商户缓存

（1）缓存模型和思路

（2）代码实现

3.店铺类型缓存 

4.缓存更新策略

5.实现商铺缓存与数据库双写一致 

6.缓存穿透

（1）介绍

（2）编码解决商品查询的缓存穿透问题

7.缓存雪崩 

 8.缓存击穿

（1）介绍

（2）利用互斥锁解决缓存击穿问题 

（3）利用逻辑过期解决缓存击穿问题

9.缓存工具封装

---

 

三、商户查询缓存

1.缓存介绍

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

缓存有很多种形式，如：

硬件缓存： 一般指的是机器上的 CPU、硬盘等等组件的缓存区间，一般是利用的内存作为一块中转区域，都通过内存交互信息，减少系统负载，提供传输效率。

客户端缓存： 一般指的是某些应用，例如浏览器、手机 App、视频缓冲等等，都是在加载一次数据后将数据临时存储到本地，当再次访问时候先检查本地缓存中是否存在，存在就不必去远程重新拉取，而是直接读取缓存数据，这样来减少远端服务器压力和加快载入速度。

服务端缓存： 一般指远端服务器上，考虑到客户端请求量多，某些数据请求量大，这些热点数据经常要到数据库中读取数据，给数据库造成压力，还有就是 IO、网络等原因有一定延迟，响应客户端较慢。所以，在一些不考虑实时性的数据中，经常将这些数据存在内存中（内存速度非常快），当请求时候，能够直接读取内存中的数据及时响应。

为什么要使用缓存？

① 缓存数据存储于代码中，而代码运行在内存中，内存的读写性能远高于磁盘，缓存可以大大降低用户访问并发量带来的服务器读写压力。

② 实际开发中，企业的数据量，少则几十万，多则几千万，这么大的数据量。如果没有缓存，系统是几乎撑不住的，所以企业会大量运用缓存技术。

③ 但是缓存也会增加代码复杂度和运营成本，也有可能引发数据不一致的现象（缓存中的数据没有及时更新客户端中的新数据）。

2.添加商户缓存

（1）缓存模型和思路

我们先启动前端和后端的项目，登陆之后随便访问一个商户，查看浏览器发送的请求。

 不出意外是 ShopController 里的业务逻辑：

可以发现：在我们查询商户信息时，我们是直接操作从数据库中去进行查询的，这样效果肯定慢

 所以我们可以在客户端与数据库之间加上一个 Redis 缓存：

先从 Redis 中查询，如果没有查到，再去 MySQL 中查询，同时查询完毕之后，将查询到的数据也存入 Redis，这样当下一个用户来进行查询的时候，就可以直接从 Redis 中获取到数据。以此往复，Redis 中的数据越来越多，命中率也越来越大，大大加快了服务端的响应速度。

 因此，我们根据 id 查询商户的流程就可以修改为：

（2）代码实现

ShopController：

    @GetMapping("/{id}")
    public Result queryShopById(@PathVariable("id") Long id) {
        return shopService.queryById(id);
    }

 IShopService：

public interface IShopService extends IService<Shop> {

    Result queryById(Long id);
}

 ShopServiceImpl：

@Service
public class ShopServiceImpl extends ServiceImpl<ShopMapper, Shop> implements IShopService {
    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public Result queryById(Long id) {
        // 1.从redis查询商铺缓存
        String shopKey = CACHE_SHOP_KEY + id;
        String shopJson = stringRedisTemplate.opsForValue().get(shopKey);
        // 2.判断是否存在
        if (StrUtil.isNotBlank(shopJson)) {
            // 3.存在，直接返回
            Shop shop = JSONUtil.toBean(shopJson, Shop.class);
            return Result.ok(shop);
        }
        // 4.不存在，根据id查询数据库
        Shop shop = getById(id);
        // 5.判断数据库中是否存在
        if(shop == null){
            // 6.不存在，返回错误
            return Result.fail("店铺不存在");
        }
        // 7.存在，写入redis
        stringRedisTemplate.opsForValue().set(shopKey,JSONUtil.toJsonStr(shop));
        // 8.返回
        return Result.ok(shop);
    }
}

运行结果：

打开 Redis，也能够看到我们缓存的数据：

3.店铺类型缓存 

完成了商户数据缓存之后，我们尝试做一下商户类型数据缓存。

在很多地方，我们都会用到商户类型的数据，而且这个数据还不会变，所以很合适加入缓存中。

 在 ShopTypeController 中，这个操作也只是简单的一个查询数据库的操作。

修改后，代码如下：

ShopTypeController：

@RestController
@RequestMapping("/shop-type")
public class ShopTypeController {
    @Resource
    private IShopTypeService typeService;

    @GetMapping("list")
    public Result queryTypeList() {
        return typeService.queryList();
    }
}

 IShopTypeService：

public interface IShopTypeService extends IService<ShopType> {

    Result queryList();
}

 ShopTypeServiceImpl：

@Service
public class ShopTypeServiceImpl extends ServiceImpl<ShopTypeMapper, ShopType> implements IShopTypeService {
    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public Result queryList() {
        // 1.在redis中查询店铺类型缓存
        String key = CACHE_SHOP_TYPE_KEY;//"cache:shop:list"
        List<String> stringTypeList = stringRedisTemplate.opsForList().range(key, 0, -1);//0是开始索引，-1是结束索引（表示最后一个元素）
        // 2.判断是否命中
        if (!stringTypeList.isEmpty()) {
            // 3.命中，直接返回
            // List<String>  ===> List<ShopType>
            List<ShopType> shopTypeList = stringTypeList.stream()
                    .map(jsonStr -> JSONUtil.toBean(jsonStr, ShopType.class))
                    .collect(Collectors.toList());
            return Result.ok(shopTypeList);
        }
        // 4.没有命中，查询数据库
        List<ShopType> shopTypeList = query().orderByAsc("sort").list();
        // 5.判断数据库中是否存在
        if (shopTypeList == null) {
            // 6.不存在，返回错误信息
            return Result.fail("店铺类型不存在！");
        }
        // 7.存在，存入redis
        // List<ShopType>  ===> List<String>
        stringTypeList = shopTypeList.stream()
                .map(shopType -> JSONUtil.toJsonStr(shopType))
                .collect(Collectors.toList());
        stringRedisTemplate.opsForList().rightPushAll(key, stringTypeList);
        // 8.返回
        return Result.ok(shopTypeList);
    }
}

 运行结果：

可以看到，第二次加载时速度明显快速很多很多。

打开 Redis，也能够看到我们缓存的数据：

4.缓存更新策略

数据同时保存在缓存和数据中，涉及数据一致性问题，如果对数据库数据做了一些修改，缓存是不知道的，这种场景下会造成业务数据错误。

所以，这时就涉及到缓存更新策略。

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

业务场景：

• 低一致性需求：使用内存淘汰机制，例如店铺类型的查询缓存（因为这个很长一段时间都不需要更新）
• 高一致性需求：主动更新，并以超时剔除作为兜底方案，例如店铺详情查询的缓存

主动更新策略有如下三种方式：

1. Cache Aside Pattern 人工编码方式：缓存调用者在更新完数据库之后再去更新缓存，也称之为双写方案
2. Read/Write Through Pattern：缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。但是维护这样一个服务很复杂，市面上也不容易找到这样的一个现成的服务，开发成本高
3. Write Behind Caching Pattern：调用者只操作缓存，其他线程去异步处理数据库，最终实现一致性。但是维护这样的一个异步的任务很复杂，需要实时监控缓存中的数据更新，其他线程去异步更新数据库也可能不太及时，而且缓存服务器如果宕机，那么缓存的数据也就丢失了