从Zara风衣到华为笔记本：拆解SPU/SKU设计如何支撑千万级电商商品库
从Zara风衣到华为笔记本：拆解SPU/SKU设计如何支撑千万级电商商品库
当你在电商平台选购一件Zara风衣时，下拉菜单里排列着12种颜色与尺码的组合；而切换到华为笔记本页面，处理器、内存、颜色的排列组合可能多达数十种。这些看似简单的选项背后，是电商系统最核心的SPU/SKU架构在支撑。一个设计良好的商品体系，能让服装与3C数码这两个截然不同的品类共享同一套数据模型，同时保持前端体验的流畅与灵活。
1. 商品体系的底层逻辑：SPU与SKU的本质差异
**SPU（Standard Product Unit）**是产品的"身份证"。它定义了商品不可变的公共属性——就像华为MateBook D 14的铝合金机身、14英寸屏幕这些特征，不会因为选择不同颜色或配置而改变。在数据库设计中，SPU表通常包含以下核心字段：
CREATE TABLE spu_info ( spu_id BIGINT PRIMARY KEY, spu_name VARCHAR(100) NOT NULL, -- 如"华为MateBook D 14 2023款" category_id BIGINT NOT NULL, -- 关联商品分类 brand_id BIGINT NOT NULL, -- 关联品牌表 description TEXT, -- 商品详情HTML base_attributes JSON -- 存储CPU型号、屏幕分辨率等固定参数 );**SKU（Stock Keeping Unit）**则是库存管理的原子单位。它由SPU+销售属性组合而成，每个SKU对应唯一的库存和价格。以Zara风衣为例，其SKU生成逻辑遵循笛卡尔积运算：
颜色集合 = [黑色, 藏青, 卡其] 尺码集合 = [S, M, L, XL] SKU总数 = 3(颜色) × 4(尺码) = 12个独立库存单元关键区别在于：
- 信息维度：SPU描述"是什么"，SKU定义"具体哪个"
- 业务影响：修改SPU属性（如产品材质）影响所有SKU，而调整某个SKU价格只影响单一商品
- 系统耦合度：SPU与类目、品牌强关联，SKU则与订单、库存系统紧密绑定
提示：在跨境电商场景中，同一SPU下的不同SKU可能对应完全不同的海关编码和税率，这需要在SKU表中增加
customs_code等扩展字段。
2. 多品类适配：从服装到3C的统一建模实践
2.1 服装类商品的轻量级建模
Zara风衣的SPU/SKU关系相对简单，主要处理二维组合问题。其属性可分为：
| 属性类型 | 示例 | 存储位置 | 是否影响SKU |
|---|---|---|---|
| 基本属性 | 材质:聚酯纤维 | SPU表 | 否 |
| 销售属性 | 颜色:黑色 | SKU属性表 | 是 |
| 销售属性 | 尺码:M | SKU属性表 | 是 |
前端交互的关键在于：
- 实时检测属性组合的库存状态
- 不同颜色对应不同的商品主图
- 尺码表需要与详情页联动展示
2.2 3C数码的多层嵌套组合
华为笔记本的复杂度呈指数级增长，典型配置组合包括：
# 伪代码展示SKU生成逻辑 colors = ['深空灰', '皓月银'] cpus = ['i5-1240P', 'i7-1260P'] rams = ['16GB', '32GB'] storages = ['512GB', '1TB'] skus = [] for color in colors: for cpu in cpus: for ram in rams: for storage in storages: skus.append({ 'spec': f"{color}/{cpu}/{ram}/{storage}", 'price': calculate_price(cpu, ram, storage), 'stock': get_initial_stock(color, cpu, ram, storage) }) # 最终生成2×2×2×2=16个SKU这种场景需要特殊处理：
- 价格公式化：基础价格+CPU溢价+内存溢价+存储溢价
- 库存预占机制：高配版本可能共享部分低配组件库存
- 属性依赖：某些CPU可能不支持32GB内存组合
2.3 统一模型的关键设计
通过抽象属性系统实现跨品类支持：
classDiagram class SPU { +Long id +String name +List<BaseAttribute> baseAttrs } class SKU { +Long id +SPU spu +Map<SaleAttr, String> saleAttrs +BigDecimal price +Integer stock } class BaseAttribute { +String name +String value } class SaleAttribute { +String name +List<String> options } SPU "1" *-- "*" SKU SPU "1" *-- "*" BaseAttribute SaleAttribute "1" *-- "*" SKU3. 高并发场景下的工程实现策略
3.1 库存服务的分片设计
千万级SKU系统需要特殊的库存存储方案：
方案对比表：
| 存储方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| MySQL行存储 | ACID保证 | 扩展性差 | SKU量<100万 |
| Redis集群 | 高性能 | 持久化成本高 | 秒杀系统 |
| TiDB分布式 | 线性扩展 | 运维复杂 | 超大规模电商 |
推荐的分片策略：
// 基于SKU ID的哈希分片示例 public Shard getShard(Long skuId) { int hash = Math.abs(skuId.hashCode() % 1024); if (hash < 300) return Shard.SHARD_1; else if (hash < 600) return Shard.SHARD_2; else return Shard.SHARD_3; }3.2 商品详情的缓存治理
SPU+SKU组合的详情页需要多层缓存：
- CDN缓存：静态化的SPU基础信息，TTL=1小时
- Redis缓存：
# Key设计示例 spu_detail:{spu_id} -> JSON sku_stock:{sku_id} -> Integer sku_price:{sku_id} -> BigDecimal - 本地缓存：Guava Cache存储热点SKU数据，有效期30秒
注意：当修改某个SKU价格时，需要同时清除Redis缓存和布隆过滤器，确保价格实时性。
3.3 分布式事务的库存扣减
采用TCC模式保证库存一致性：
def try_deduct(sku_id, quantity): if redis.decrby(f"stock:{sku_id}", quantity) >= 0: create_temp_log(sku_id, quantity) return True else: redis.incrby(f"stock:{sku_id}", quantity) return False def confirm_deduct(order_id): write_mysql(order_id) # 正式扣减 delete_temp_log(order_id) def cancel_deduct(order_id): records = get_temp_log(order_id) for sku_id, qty in records: redis.incrby(f"stock:{sku_id}", qty)4. 业务扩展性的深度优化
4.1 动态属性系统的实现
通过元数据管理支持新增属性：
-- 属性定义表 CREATE TABLE attribute_definition ( attr_id BIGINT PRIMARY KEY, attr_name VARCHAR(50) NOT NULL, attr_type ENUM('BASE', 'SALE') NOT NULL, value_type ENUM('TEXT', 'NUMBER', 'ENUM') NOT NULL, options JSON COMMENT '枚举值列表，如["红色","蓝色"]' ); -- 属性关联表 CREATE TABLE spu_attribute ( spu_id BIGINT, attr_id BIGINT, attr_value TEXT NOT NULL, PRIMARY KEY (spu_id, attr_id) );4.2 价格策略的插件化设计
支持多种定价模型：
- 成本加成：基础成本×利润率
- 市场竞争：跟随主竞品价格浮动
- 会员分级：不同等级享受不同折扣
价格计算引擎接口示例：
public interface PriceCalculator { BigDecimal calculate(SkuInfo sku, UserInfo user); default boolean support(SkuInfo sku) { return true; } } // 注解驱动实现类选择 @PriceStrategy(type = "VIP") public class VipPriceCalculator implements PriceCalculator { @Override public BigDecimal calculate(SkuInfo sku, UserInfo user) { return sku.getBasePrice() .multiply(user.getDiscountRate()) .setScale(2, RoundingMode.HALF_UP); } }4.3 商品推荐的维度融合
结合SPU/SKU特征进行精准推荐：
- 协同过滤：购买过该SPU的用户还看了哪些
- 属性相似：相同CPU/内存配置的笔记本
- 价格带匹配：±20%价格区间的替代商品
在推荐系统中，SPU提供品类特征，SKU提供具体选择依据。一个常见的做法是将SPU和SKU的特征向量拼接：
# 伪代码：生成商品嵌入向量 def get_item_embedding(spu_id, sku_id): spu_vec = spu_model.get_embedding(spu_id) # 品类、品牌等宏观特征 sku_vec = sku_model.get_embedding(sku_id) # 配置、价格等微观特征 return np.concatenate([spu_vec, sku_vec])在实际项目中，最容易被低估的是销售属性与类目体系的关联设计。我们曾遇到一个案例：当笔记本增加"键盘语言"属性时，由于未与地区分类绑定，导致法国站点展示了中文键盘的SKU。这提醒我们，任何影响前端筛选的属性，都必须与类目、地区等业务上下文建立显式关联。