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

一、概念定义

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

(未经同意，请勿转载)