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

作者:神秘网友 发布时间:2020-10-31 19:45:11

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

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

类目设计

  • 概念定义
    • 什么是类目
    • 前后台类目
  • 属性和属性值
    • 导航属性
    • 销售属性
    • 普通属性
    • 子属性和子属性值
  • 技术设计
    • 关系图
    • 类目属性树形结构图
    • 类目表
    • 缓存
      • 分布式缓存
      • 分布式本地缓存
  • 总结

概念定义

类目简单来说就是商品的分类,用大家最常用的淘宝来看,就是图中圈出来的地方。
基于电商中台架构-商品系统设计(二):类目设计
为什么会有类目,也是其功能决定的,类目目前已经作为电商网站导航的标配,只是不同网站的类目不同罢了。
如果我们的网站只有几十个、上百个商品,或许类目对于我们来说不重要,但是如果商品有成千上万个,甚至更多,那类目对我们来找到具有某些特点的商品就至关重要了。比如现在要找女式牛仔裤,可以通过类目 女装->牛仔裤 就能找到了;否则那就一页一页去搜索,就算我们平台商品质量再好,性价比再高,相信用户也会忍耐不住抓狂了。。

类目分为前台和后台类目。
前台类目的存在主要是面向用户,搜索导航栏,这个是易变的,季节、营销活动都会影响类目导航;
后台类目是直接和商品关联的,商品创建的时候选择好类目,那么对应的类目几乎就不会变化了,它是很稳定的。
好处:
比如现在我们平台新推出一种活动,类目就是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恤进行商品搜索的功能。
一般来说,不管是前台类目还是后台类目都会分为几级,所以最终都会形成一棵类目树。

属性和属性值

每个类目都有属性,属性作为该类目下商品都共有的特征,比如颜色、大小等等。
属性值则是该属性具体的值,比如颜色可以有红色、白色、黑色。
正常来说,前台类目有关联后台类目,则前台类目的属性都是从后台类目的属性集合中选择的。
比如12.12->(A、B)这个关系中,对应属性A(a1,a2),B(b1,b2),则12.12的属性应该属于(a1,a2,b1,b2)集合。
属性也可分为几类,我们使用到的大致为:导航属性、销售属性、普通属性。

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

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

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

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

商品的其他属性。

基于电商中台架构-商品系统设计(二):类目设计
创建商品的时候需要选择类目,然后根据该类目的属性来填充商品的属性值,保存在商品上就类似于key-value的格式。这样就可以根据属性值来筛选商品。

这个关系一般用不上,设计不了这么细致,不过可以预留着。
子属性是挂在某个属性值下面的。子属性值就是该子属性的取值。例如手机类目下,有个属性为品牌,存在一个属性值为iPhone的品牌,则再往下划分可划分出iPhone的子属性型号,对应的子属性值可以为iPhone8、iPhone X等。
所以这里就存在一个关系:类目(手机)->属性(品牌)->属性值(iPhone)->子属性(型号)->iPhone8(子属性值)
子属性也用属性模型来承载,只是设计的时候要建立好属性值和子属性的关联关系。

技术设计

基于电商中台架构-商品系统设计(二):类目设计
其中包含的对应关系有:
前台类目:后台类目(多对多);
类目:属性(1对多);
属性:属性值(1对多);
属性值:子属性(1对多);

基于电商中台架构-商品系统设计(二):类目设计
类目和属性的层级深度根据业务而定,因为是树形结构,所以本身可扩展。
属性挂在后台叶子类目下。

`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表示该类目处于第几级

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

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

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

分布式缓存

使用Redis来存储类目数据结构。
优点:所有client共享一份数据,没有数据不一致的问题
缺点:当系统规模很大,qps将不断增加,缓存中心压力变大。
整体流程如下图:
基于电商中台架构-商品系统设计(二):类目设计

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

刷新策略:定时更新,1.2两步通过定时任务执行、执行频率可根据具体业务可接受程度而定。
该方法的好处是无需在类目更改的所有方法路径加入缓存失效、推送的逻辑。所有逻辑都统一在定时任务里面处理。

分布式本地缓存

优点:所有client本地内存有一份副本,直接从内存读取,速度快。
缺点:所有client需要与server数据同步,关键问题是数据不一致很难保证;
需要封装单独的client jar包以供使用,当jar包升级时需要同步所有依赖方升级,维护成本大;
整体流程图如下:
基于电商中台架构-商品系统设计(二):类目设计

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

这里有几点需要注意:

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

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

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

  1. 类目client是开发后打包给需要使用类目服务的应用引用。该包里面已封装好了关于类目的所有操作,包括定时拉取、解析服务器构建的数据结构、数据校验、本地缓存刷新等功能,对应用提供的就是类目的基本操作,比如根据ID获取类目、获取类目树等等。
  2. 服务器每次构建类目数据结构应维护版本号,这样client可判断是否是最新数据,重新拉取等等。通过先判断版本号,再拉取是一种不错的选择。这样可减少数据未更新而产生的不必要网络传输。
  3. 为什么通过类目client主动从服务器拉取的方式,因为如果服务器主动推送,首先得维护client列表,其次还要维护所有client的推送状态。如果把这个放在client维护,那就大大减少了复杂性。

通过比较分布式缓存和本地缓存两种方式,总结出分布式缓存实现简单,数据一致性易保证。本地缓存需要自己实现client包,会出现短暂的不一致,在高并发下优势更加明显,但强一致业务慎用。最终我们使用分布式缓存即能满足要求。
结构设计:
类目面向电商前台页面,用的最多的就是类目树的获取,所以可以这样来设计。

rootCategoryIds:保存根类目ID列表索引
subCategoryIds + 类目ID:保存该类目下级类目ID列表索引
category + 类目ID:保存该类目具体数据data
通过根类目ID列表和子类目ID列表就能够索引到类目树中所有的类目ID,通过ID就能拿到所有数据。

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

总结

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

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

  1. 基于Thinkphp使用同一个域名,PC和M端访问不同模板

    基于Thinkphp使用同一个域名,PC和M端访问不同模板 一、首先目录结构展示:(主要修改这几个文件) 二、更改入口文件 index.php require DIR . ‘./isMobile.php’; 三、在入口文件index.php同级目录下,增加common.php 文件,代码为: ?phpfunction isMobile

  2. 基于arcgis的遥感影像标签制作(目标检测)

    基于arcgis的遥感影像标签制作(目标检测) 文章目录 1. 在arcgis中新建线矢量 2. 检测框绘制 3. 检测框坐标转换(线矢量) 4. 检测框坐标转换(面矢量) 1. 在arcgis中新建线矢量 新建线矢量,添加空间参考,例如wgs_1984。 2. 检测框绘制 3. 检测框坐标转换

  3. 基于mat做简单的堆内存溢出分析

    基于mat做简单的堆内存溢出分析 文章目录 下载启动mat 生成 dump文件 加载dump文件 首先我们需要下载启动mat 下载mat 官网下载地址 这里更加自己的系统选择合适的压缩包 我选择的是Windows(x86),下载之后是个zip包,解压就直接可以使用 如果分析的dump文件过

  4. Jenkins 基于 Docker 安装 超详细教程

    Jenkins 基于 Docker 安装 超详细教程 docker pull lamdaer/jenkins:0.0.1 docker run -p 8080:8080 --name myjenkins -d lamdaer/jenkins:0.0.1# 参数含义# --name 指定容器名称# -d 容器后台运行# -p 宿主机和容器端口映射 宿主机端口:容器暴露端口 访问 80

  5. 2020-10-30

    2020-10-30 基于MATLAB的离散时间全通系统和系统辨识 主程序 clearclc%主程序(main_DTFT)nandy1 = [0.6 0.6 0.6]; %定义frame控件的背景色nandy = [1 1 1]; %定义整个图形的背景色nandy2 = [0.7 0.7 0.7]; %定义缺省控件的背景色mm = 1; hyh = 1; N = 30;w =

  6. 如何自己申请免费的通配符证书(基于 Let‘s Encrypt 的免费证书

    如何自己申请免费的通配符证书(基于 Let‘s Encrypt 的免费证书) 最近项目上线,需要用到https,在网上找到了可以白嫖的证书,记录一下使用过程 Let’s Encrypt一个非盈利性的证书颁发机构,并且已经被大多数浏览器所信任,而我们可以使用Certbot(一个免费

  7. 基于ROS搭建简易软件框架实现ROV水下目标跟踪(十四完结)--目标

    基于ROS搭建简易软件框架实现ROV水下目标跟踪(十四完结)--目标跟踪模块 模块十分简单,可以介绍的内容很少。包括两个部分:计算目标物中心距图片中心的偏差,对应cabin_vision/object_deviation;PID跟踪控制,对应cabin_behaviors/pid_tracking。 一、偏差

  8. 【Spring】基于XML的IOC案例

    【Spring】基于XML的IOC案例 代码结构: bean.xml ?xml version=1.0 encoding=UTF-8?beans xmlns=http://www.springframework.org/schema/beans xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://www.springframework.org/sch