商品缓存系统建设的方案 - 掘金

随着业务的高速发展, 产品的UV/PV 已经有了数量级的提升,作为访问量的聚集地之一的商品详情页逐步的感受到了压力,特别是活动和大促期间,这样的感觉越发明显。所以除了服务化改造本身,今年我们的重点改造目标之一,就是提升商品详情页的性能和体验。

被动式缓存先行

为了尽快解决页面访问的性能问题,第一步往往会选用最快最有效的方式,我们也不例外,所以在第一个版本中,我们的改造方案如下:


商品详情页的所有数据,提前加载到Redis集群中,设置了一个数据过期时间,比如5分钟或者10分钟,过期后,再从数据库同步最新状态数据。

通过被动式缓存改造后,商详页的性能提升是显著的,但缺点也是明显的,一些动态数据,例如“购买人数”,“剩余份额”,“投资记录”等,更新的频率显得缺乏及时性。所以,商品缓存虽然有了性能提升,但是还远没有达到我们的要求,于是我们就立刻做了第二步。

主动式缓存 + 被动式缓存

采用主动式缓存的出发点在于将访问量,购买量高的产品的数据更新做得更及时,对于不怎么访问或者没有购买量的商品详情页可以延迟更新,通过缓存差异化实现既保持比较高的性能,同样保持用户数据及时性的目的。

具体的架构方案如下:


更新的步骤如下:

1. 设置一个统一的被动缓存过期时间,比如 1小时。

2. 用户访问的时候,商品服务先从Redis中将缓存数据data取出来输出给用户。订单服务判断该商品的剩余份额是否有变化,如果剩余份额有变化则将当前产品ID发送到消息队列。

3. TaskManager从MQ中依次获取需要刷新的产品ID列表,将更新后的最新的订单数据写入Redis。

4. 缓存更新后,下次用户再次访问商详页,相关数据已更新。

5. 对于冷门产品,最迟每隔1小时后,通过被动缓存进行更新。

有了主动式+被动式的缓存方案后,性能和数据一致性是解决了,不过考虑到稳定性和商详页数据扩展性的要求,我们的商品缓存还需要将粒度做得更细,于是有了下面的思路。

商品信息缓存架构

我们可以将商详页上的数据,根据不同的类型,进行一个划分,例如,分成4类:

1、商品基本信息,标题、扩展属性、特殊属性、图片、期限、收益率参数等;

2、项目介绍信息,受托方、合作机构、项目简介、风险提示等;

3、销售信息,已卖份额、购买人数、购买详情等;

4、活动情况,所属活动,活动介绍等。

缓存更新的流程:


  1. 当某类商品信息出现更新后,对应的服务会将对应的信息ID放入MQ中,异步通知产品服务,商品信息出现了更新。

  2. 产品服务中的数据整合模块,根据需要更新的数据类型,对数据的格式进行梳理,便于存储。

  3. 将更新后的数据同步到商品服务对应的缓存系统中。

  4. 前端请求商品服务的时候,就可以拿到更新后的数据。

这个方案的主要目标如下:

  1. 产品数据形成自我管理,不依赖于任何其他系统,将各个依赖系统的数据拿过来,按照产品系统的要求存储起来。

  2. 将数据按照不同的类型区分开,减少彼此的相互影响,即便是某一类数据无法正常获取,不会影响到其他数据。

  3. 按照不同的数据类型,可以制定不同的时效性方案进行处理。比方说,“利率”,时效性可以放到最高。“购买人数”,就可以允许一定的延迟。

实际上还有一些细节在本文中没有提到,例如系统的弹性化,多级缓存的设置等等,后续的文章中会逐步去完善这个体系。大家如果有任何疑问,可以留言,大家一起讨论。

扫描二维码或手动搜索微信公众号【架构栈】: ForestNotes

欢迎转载,带上以下二维码即可


本文由 黑白世界4648 第一时间收藏到GET,原文来自 → juejin.im

「GetParty」

关注微信号,推送好文章

微信中长按图片即可关注

更多精选文章

评论
微博一键登入