基于电商中台架构-商品系统设计(二):类目设计

一、概念定义

1.什么是类目

类目简单来说就是商品的分类,用大家最常用的淘宝来看,就是图中圈出来的地方。

基于电商中台架构-商品系统设计(二):类目设计

为什么会有类目,也是其功能决定的,类目目前已经作为电商网站导航的标配,只是不同网站的类目不同罢了。

如果我们的网站只有几十个、上百个商品,或许类目对于我们来说不重要,但是如果商品有成千上万个,甚至更多,那类目对我们来找到具有某些特点的商品就至关重要了。比如现在要找女式牛仔裤,可以通过类目 女装->牛仔裤 就能找到了;否则那就一页一页去搜索,就算我们平台商品质量再好,性价比再高,相信用户也会忍耐不住抓狂了。。

2.前后台类目

类目分为前台和后台类目。

前台类目的存在主要是面向用户,搜索导航栏,这个是易变的,季节、营销活动都会影响类目导航;

后台类目是直接和商品关联的,商品创建的时候选择好类目,那么对应的类目几乎就不会变化了,它是很稳定的。

好处:

比如现在我们平台新推出一种活动,类目就是12.12,如果没有前后台类目分离,那我们需要找到需要做活动的商品把他们类目改为12.12,但明显这个方式不妥;那重新维护一套和这些商品的关联关系,这样搞个新模块那还不如直接用类目来承载呢,这样我们把前后台类目做个映射关系就OK了。

关联关系可以根据需求任意组合。

举例:现在有批商品,分别有后台类目A、B、C,我们要对A、B类目的商品做活动导航,则做个映射关系,12.12->(A、B),将前台类目12.12和后台A、B做关联,这样就可以通过导航12.12找到所有A、B类目下的商品了。

此外,前台类目易变而且不和商品直接关联还有个好处,它可以扩展成很多种方式。比如新增活动频道,通过URL的方式直接跳转;通过关键词的方式定义,比如类目T恤就是通过关键词T恤进行商品搜索的功能。

一般来说,不管是前台类目还是后台类目都会分为几级,所以最终都会形成一棵类目树。

3.属性和属性值

每个类目都有属性,属性作为该类目下商品都共有的特征,比如颜色、大小等等。

属性值则是该属性具体的值,比如颜色可以有红色、白色、黑色。

正常来说,前台类目有关联后台类目,则前台类目的属性都是从后台类目的属性集合中选择的。

比如12.12->(A、B)这个关系中,对应属性A(a1,a2),B(b1,b2),则12.12的属性应该属于(a1,a2,b1,b2)集合。

属性也可分为几类,我们使用到的大致为:导航属性、销售属性、普通属性。

导航属性:作为根据类目进入筛选页的属性选项。

基于电商中台架构-商品系统设计(二):类目设计

销售属性:商品详情页可供选择的sku规格属性,不同属性价格可能会不同。

基于电商中台架构-商品系统设计(二):类目设计

普通属性:商品的其他属性。

基于电商中台架构-商品系统设计(二):类目设计

创建商品的时候需要选择类目,然后根据该类目的属性来填充商品的属性值,保存在商品上就类似于key-value的格式。这样就可以根据属性值来筛选商品。

4.子属性和子属性值

这个关系一般用不上,设计不了这么细致,不过可以预留着。

子属性是挂在某个属性值下面的。子属性值就是该子属性的取值。例如手机类目下,有个属性为品牌,存在一个属性值为iPhone的品牌,则再往下划分可划分出iPhone的子属性型号,对应的子属性值可以为iPhone8、iPhone X等。

所以这里就存在一个关系:类目(手机)->属性(品牌)->属性值(iPhone)->子属性(型号)->iPhone8(子属性值)

子属性也用属性模型来承载,只是设计的时候要建立好属性值和子属性的关联关系。

二、技术设计

1.关系图

基于电商中台架构-商品系统设计(二):类目设计

其中包含的对应关系有:

前台类目:后台类目(多对多);

类目:属性(1对多);

属性:属性值(1对多);

属性值:子属性(1对多);

2.类目属性树形结构图

基于电商中台架构-商品系统设计(二):类目设计

类目和属性的层级深度根据业务而定,因为是树形结构,所以本身可扩展。

属性挂在后台叶子类目下。

3.类目表

cate_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',

  `gmt_create` datetime NOT NULL COMMENT '创建时间',

  `gmt_modified` datetime NOT NULL COMMENT '修改时间',

  `pid` bigint(20) DEFAULT NULL COMMENT '父id',

  `leaf` tinyint(4) NOT NULL COMMENT '是否叶子节点 1:是0:不是',

  `level` tinyint(4) NOT NULL COMMENT '层级',

  `title` varchar(64) NOT NULL COMMENT 'title',

  `cate_type` tinyint(4) NOT NULL COMMENT '前台后台类目 1:前台 2:后台',

  `back_categories` varchar(255) DEFAULT NULL COMMENT '后台类目id集合 适用于前台 英文逗号分隔',

  `root_cate_id` bigint(20) DEFAULT NULL COMMENT '根类目id',

  `order_seq` int(11) NOT NULL COMMENT '排序序列',

  `picture_url` varchar(255) DEFAULT NULL COMMENT '图片url',

  `need_audit` tinyint(4) NOT NULL COMMENT '是否需要审核 1:是0:不是',

  `is_delete` tinyint(4) NOT NULL COMMENT '状态0:正常 1:删除',

  `biz_type` varchar(64) NOT NULL COMMENT '平台类型',

  `language` varchar(64) DEFAULT 'zh' COMMENT '语言',

  `country` varchar(64) DEFAULT 'CN' COMMENT '国家',

  `extension` mediumtext COMMENT '扩展字段',

  `version` int(11) NOT NULL DEFAULT '0' COMMENT ‘版本',复制代码

其中pid存储上级类目ID

level表示该类目处于第几级

4.缓存

由于类目作为电商系统的基础数据,很多模块都会依赖它,随着电商系统规模的扩大,类目查询请求、并发量会不断增加,所以一开始我们就采用缓存的方式。

采用类目做缓存的几点考量:

  • 类目作为基础数据,查询请求巨大;
  • 类目数据相比其他基础数据来说内存占用不高;
  • 类目是共享数据;
  • 类目变更实时性要求不高,没有严格的数据一致性要求;

缓存的两种方式:分布式缓存和分布式本地缓存

4.1分布式缓存:

使用Redis来存储类目数据结构。

优点:所有client共享一份数据,没有数据不一致的问题

缺点:当系统规模很大,qps将不断增加,缓存中心压力变大。

整体流程如下图:

基于电商中台架构-商品系统设计(二):类目设计

  1. 从DB查询类目数据
  2. 构建需要保存的数据结构,并推到缓存
  3. 接收client查询请求
  4. 从构建好的缓存中查询
  5. 返回数据

刷新策略:定时更新,1.2两步通过定时任务执行、执行频率可根据具体业务可接受程度而定。

该方法的好处是无需在类目更改的所有方法路径加入缓存失效、推送的逻辑。所有逻辑都统一在定时任务里面处理。

4.2分布式本地缓存:

优点:所有client本地内存有一份副本,直接从内存读取,速度快。

缺点:所有client需要与server数据同步,关键问题是数据不一致很难保证;

需要封装单独的client jar包以供使用,当jar包升级时需要同步所有依赖方升级,维护成本大;

整体流程图如下:

基于电商中台架构-商品系统设计(二):类目设计

  1. 1.从DB读取类目数据
  2. 2.构建需要缓存的类目数据结构。
  3. 3.通过开发的类目client jar包向服务器拉取数据。
  4. 4.返回构建好的数据结构。

这里有几点需要注意:

1.可以通过很多种方式来达到client的数据刷新:

  • 将构建好的数据包存放在DB,client统一从DB刷新;
  • 服务器通过发消息广播的方式,client监听刷新本地缓存;
  • 通过jar包实现封装定时拉取的方式,定时刷新本地缓存。

由于我们系统中对类目的更新实时性要求不高、没有严格一致性要求。所以设计时可采用定时刷新的方式。jar包的方式对于依赖方是最易用的方式。也正是实时性、一致性要求不高,所以才可使用本地缓存。如果系统因为本地缓存数据不一致而将导致很严重的后果,那还是慎用。

2.类目client是开发后打包给需要使用类目服务的应用引用。该包里面已封装好了关于类目的所有操作,包括定时拉取、解析服务器构建的数据结构、数据校验、本地缓存刷新等功能,对应用提供的就是类目的基本操作,比如根据ID获取类目、获取类目树等等。

3.服务器每次构建类目数据结构应维护版本号,这样client可判断是否是最新数据,重新拉取等等。通过先判断版本号,再拉取是一种不错的选择。这样可减少数据未更新而产生的不必要网络传输。

4.为什么通过类目client主动从服务器拉取的方式,因为如果服务器主动推送,首先得维护client列表,其次还要维护所有client的推送状态。如果把这个放在client维护,那就大大减少了复杂性。

通过比较分布式缓存和本地缓存两种方式,总结出分布式缓存实现简单,数据一致性易保证。本地缓存需要自己实现client包,会出现短暂的不一致,在高并发下优势更加明显,但强一致业务慎用。最终我们使用分布式缓存即能满足要求。

结构设计:

类目面向电商前台页面,用的最多的就是类目树的获取,所以可以这样来设计。

  • rootCategoryIds:保存根类目ID列表索引
  • subCategoryIds + 类目ID:保存该类目下级类目ID列表索引
  • category + 类目ID:保存该类目具体数据data

通过根类目ID列表和子类目ID列表就能够索引到类目树中所有的类目ID,通过ID就能拿到所有数据。

该结构其实可适用于分布式缓存和本地缓存的数据结构。通过构建该数据结构就能快速拿到类目树中的任一节点。

三、总结

虽然类目结构不复杂,但因为其使用非常频繁,所有在电商系统中需要好好设计类目的存取。介绍了一些分布式缓存和本地缓存,但不详细,详细的缓存知识可参考网上其他资料。上面讲到的本地缓存的实现方式也是借鉴了淘宝的类目体系,如果非要使用本地缓存也可以参考一下。

更多文章欢迎访问 http://www.apexyun.com/

联系邮箱:public@space-explore.com

(未经同意,请勿转载)

原文 

https://juejin.im/post/5c0a3c0c5188250b064f51f4

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 基于电商中台架构-商品系统设计(二):类目设计

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址