Redian新闻
>
分页列表缓存就该这样设计!

分页列表缓存就该这样设计!

公众号新闻

点击上方“芋道源码”,选择“设为星标

管她前浪,还是后浪?

能浪的浪,才是好浪!

每天 10:33 更新文章,每天掉亿点点头发...

源码精品专栏

 
来源:勇哥java实战分享


写这篇文章,我们聊聊分页列表缓存 ,希望能帮助大家提升缓存技术认知。

1 直接缓存分页列表结果

这是最简单易懂的方案,我们按照不同的分页条件查询出结果后,直接缓存分页结果 。

伪代码如下:

public List<Product> getPageList(String param,int page,int size) {
  String key = "productList:page:" + page + "size:" + size + 
               "param:" + param ;
  List<Product> dataList = cacheUtils.get(key);
  if(dataList != null) {
    return dataList;
  }
  dataList = queryFromDataBase(param,page,size);
  if(dataList != null) {
       cacheUtils.set(key , dataList , Constants.ExpireTime);
  }

这种方案的优点是工程简单,性能也快,但是有一个明显的缺陷基因:列表缓存的颗粒度非常大

假如列表中数据发生增删,为了保证数据的一致性,需要修改分页列表缓存。

有两种方式 :

1、依靠缓存过期来惰性的实现 ,但业务场景必须包容;

2、使用 Redis 的 keys 找到该业务的分页缓存,执行删除指令。但 keys 命令对性能影响很大,会导致 Redis 很大的延迟 。

生产环境使用 keys 命令比较危险,发生事故的几率高,非常不推荐使用

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/ruoyi-vue-pro
  • 视频教程:https://doc.iocoder.cn/video/

2 查询对象ID列表,再缓存每个对象条目

直接缓存分页结果虽然好用,但缓存的颗粒度太大,保证数据一致性比较麻烦。

所以我们的目标是更细粒度的控制缓存

我们先查询出商品分页对象ID列表,然后为每一个商品对象创建缓存 ,  通过商品ID和商品对象缓存聚合成列表返回给前端。

伪代码如下:

核心流程:

1、从数据库中查询分页 ID 列表

// 从数据库中查询分页商品 ID 列表
List<Long> productIdList = queryProductIdListFromDabaBase(
                           param, 
                           page, 
                           size);

对应的 SQL 类似:

SELECT id FROM products
ORDER BY id ASC  
LIMIT (page - 1) * size , size 

2、批量从缓存中获取商品对象

Map<Long, Product> cachedProductMap = cacheUtils.mget(productIdList);

假如我们使用本地缓存,直接一条一条从本地缓存中聚合也极快。

假如我们使用分布式缓存,Redis 天然支持批量查询的命令 ,比如 mget ,hmget 。

3、组装没有命中的商品ID

List<Long> noHitIdList = new ArrayList<>(cachedProductMap.size());
for (Long productId : productIdList) {
     if (!cachedProductMap.containsKey(productId)) {
         noHitIdList.add(productId);
     }
}

因为缓存中可能因为过期或者其他原因导致缓存没有命中的情况,所以我们需要找到哪些商品没有在缓存里。

4、批量从数据库查询未命中的商品信息列表,重新加载到缓存

首先从数据库里批量 查询出未命中的商品信息列表 ,请注意是批量

List<Product> noHitProductList = batchQuery(noHitIdList);

参数是未命中缓存的商品ID列表,组装成对应的 SQL,这样性能更快 :

SELECT * FROM products WHERE id IN
                         (1,
                          2,
                          3,
                          4)
;

然后这些未命中的商品信息存储到缓存里 , 使用 Redis 的 mset 命令。

//将没有命中的商品加入到缓存里
Map<Long, Product> noHitProductMap =
         noHitProductList.stream()
         .collect(
           Collectors.toMap(Product::getId, Function.identity())
         );
cacheUtils.mset(noHitProductMap);
//将没有命中的商品加入到聚合map里
cachedProductMap.putAll(noHitProductMap);

5、 遍历商品ID列表,组装对象列表

for (Long productId : productIdList) {
    Product product = cachedProductMap.get(productId);
    if (product != null) {
       result.add(product);
    }
}

当前方案里,缓存都有命中的情况下,经过两次网络 IO ,第一次数据库查询 IO ,第二次 Redis 查询 IO ,  性能都会比较好。

所有的操作都是批量操作,就算有缓存没有命中的情况,整体速度也较快。

查询对象ID列表,再缓存每个对象条目 “ 这个方案比较灵活,当我们查询对象ID列表 ,可以不限于数据库,还可以是搜索引擎,Redis 等等。

下图是开源中国的搜索流程:

精髓在于:搜索的分页结果只包含业务对象 ID  ,对象的详细资料需要从缓存 + MySQL 中获取。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/yudao-cloud
  • 视频教程:https://doc.iocoder.cn/video/

3 缓存对象ID列表,同时缓存每个对象条目

笔者曾经重构过类似朋友圈的服务,进入班级页面 ,瀑布流的形式展示班级成员的所有动态。

我们使用推模式将每一条动态 ID 存储在 Redis  ZSet 数据结构中 。Redis ZSet 是一种类型为有序集合的数据结构,它由多个有序的唯一的字符串元素组成,每个元素都关联着一个浮点数分值。

ZSet 使用的是 member -> score 结构 :

  • member : 成员,也是默认的第二排序维度( score 相同时,Redis 以 member 的字典序排列)
  • score : 分值,存储类型是 double

如上图所示:ZSet 存储动态 ID 列表  ,  member 的值是动态编号 , score 值是创建时间

通过 ZSet 的 ZREVRANGE 命令 就可以实现分页的效果。

ZREVRANGE 是 Redis 中用于有序集合(sorted set)的命令之一,它用于按照成员的分数从大到小返回有序集合中的指定范围的成员。

为了达到分页的效果,传递如下的分页参数 :

通过 ZREVRANGE 命令,我们可以查询出动态 ID 列表。

查询出动态 ID 列表后,还需要缓存每个动态对象条目,动态对象包含了详情,评论,点赞,收藏这些功能数据 ,我们需要为这些数据提供单独做缓存配置。

无论是查询缓存,还是重新写入缓存,为了提升系统性能,批量操作效率更高。

缓存对象结构简单,使用 mget 、hmget 命令;若结构复杂,可以考虑使用 pipleline,Lua 脚本模式 。 笔者选择的批量方案是 Redis 的 pipleline 功能。

我们再来模拟获取动态分页列表的流程:

  1. 使用 ZSet 的 ZREVRANGE 命令 ,传入分页参数,查询出动态 ID 列表 ;
  2. 传递动态 ID 列表参数,通过 Redis 的 pipleline 功能从缓存中批量获取动态的详情,评论,点赞,收藏这些功能数据 ,组装成列表 。

4 总结

本文介绍了实现分页列表缓存的三种方式:

  1. 直接缓存分页列表结果
  2. 查询对象ID列表,只缓存每个对象条目
  3. 缓存对象ID列表,同时缓存每个对象条目

这三种方式是一层一层递进的,要诀是:细粒度的控制缓存批量加载对象



欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢

已在知识星球更新源码解析如下:

最近更新《芋道 SpringBoot 2.X 入门》系列,已经 101 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。

获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。

文章有帮助的话,在看,转发吧。

谢谢支持哟 (*^__^*)

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
这才叫走心的消防登高面设计!连甲方都挑不出任何毛病!(附文本下载)61㎡的LOFT,卧室这样设计好看又省空间开门见厅没玄关?鞋柜这样设计,189双鞋都塞得下!【装修干货】对标大厂,Gateway 网关系统就该这么设计!一大波创意十足的汉堡主题LOGO设计!Newton全新别墅又一力作!现代生活美学空间就该这样设计!Open House 6/24-25【岛妹说】政府大院开门让农户晒粮,为人民服务就该这样豆瓣评分9.6,纸上的“美学博物馆”:孩子的美育,就该这样做!国风茶饮包装审美疲劳?不妨这样设计!绕过“卷王”服装设计!这些赛道也能让你上岸时尚名校!支付系统就该这么设计,稳的一批!!AI绘图带火游戏设计!听说能抓住风口的人都要“发财”了?!分布式中灰度方案就该这样设计!男生夏天就该这样子穿!百元搞定一身穿搭,整个夏季冰凉清爽在森林里创造全球设计!比利时设计师是怎么工作的?读康有为论书法Redis实现分页+多条件模糊查询组合方案无胸肌,不男人!想要胸肌大、卧推猛,就该这样练!为更美好的生活设计!2023“芭莎设计大赏”全新启程道人笔记(十五)少时光阴容易过,外婆恩情难忘怀原木奶油风的家,客厅这样设计真有腔调让 GPT-4 帮我设计一个分布式缓存系统,从尝试到被我逼疯!拒接“35岁以上中年人”,青旅有权这样设置吗?充满力量的混凝土设计!墨西哥650㎡沙漠堡垒——「山楂」端午礼盒包装这样设计,仪式感满满!AI设计进军规划圈!网友直呼:我还做什么设计!端午礼盒包装这样设计,好夏日!道人笔记(十八)学信息网络正当红, 换专业心中有思量大楼这样设计,简直是吸尘器!或将拯救海洋!就该这样!华女取钱遭抢劫奋起反抗,华裔大哥出收力擒女匪AI绘图带火游戏设计!听说抓住风口的人都要发财了!道人笔记(十七)勤学苦自得勤学果, 浮躁地不染浮躁因道人笔记(十六)心怀善意苍生万物皆有情,一年苦读及第春风先许我大型分布式系统中,缓存就该这么玩高级黑+高级灰,大平层就该这么设计!
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。