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

本文介绍了电商商品类目的概念,包括前后台类目、属性和属性值,以及子属性的关系。同时,文章详细探讨了技术设计,包括类目表、分布式缓存和分布式本地缓存的优缺点,提出使用Redis实现分布式缓存来应对高并发场景,并提供了类目数据结构的设计方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、概念定义

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.1

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值