一, 概念定义
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 将不断增加, 缓存中心压力变大.
整体流程如下图:
从 DB 查询类目数据
构建需要保存的数据结构, 并推到缓存
接收 client 查询请求
从构建好的缓存中查询
返回数据
刷新策略: 定时更新, 1.2 两步通过定时任务执行, 执行频率可根据具体业务可接受程度而定.
该方法的好处是无需在类目更改的所有方法路径加入缓存失效, 推送的逻辑. 所有逻辑都统一在定时任务里面处理.
4.2 分布式本地缓存:
优点: 所有 client 本地内存有一份副本, 直接从内存读取, 速度快.
缺点: 所有 client 需要与 server 数据同步, 关键问题是数据不一致很难保证;
需要封装单独的 client jar 包以供使用, 当 jar 包升级时需要同步所有依赖方升级, 维护成本大;
整体流程图如下:
1. 从 DB 读取类目数据
2. 构建需要缓存的类目数据结构.
3. 通过开发的类目 client jar 包向服务器拉取数据.
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/ http://www.apexyun.com/
联系邮箱: public@space-explore.com
(未经同意, 请勿转载)
来源: https://juejin.im/post/5c0a3c0c5188250b064f51f4