1. 电商商品模块的核心定位与业务价值
电商平台的商品模块是整个交易体系的基础设施，其重要性相当于实体零售中的货架陈列系统。我在参与多个电商项目重构时发现，商品模块的设计质量直接影响着后续订单转化率、运营灵活性和系统扩展性。一个典型的反面案例是某母婴电商初期采用扁平化商品结构，导致SKU管理混乱，促销活动时出现大量价格冲突，最终被迫进行耗时半年的模块重构。
商品模块需要同时满足三个维度的需求：
- 消费者视角：提供完整的商品信息展示、多维度检索、价格计算能力
- 运营视角：支持灵活的商品上下架、组合营销、库存调配
- 技术视角：保证高并发读取性能、数据一致性、分布式事务处理
2. 商品基础数据模型设计
2.1 核心实体关系建模
经过多个项目的迭代验证，我总结出商品模块最稳定的ER模型应包含以下核心实体：
mermaid复制erDiagram
SPU ||--o{ SKU : has
SPU {
string spu_code PK
string title
string description
int category_id
int brand_id
datetime create_time
}
SKU {
string sku_code PK
string spu_code FK
string spec_values
decimal price
int stock
string barcode
}
Category ||--o{ Category : parent
Category {
int id PK
string name
int parent_id
int level
}
Brand {
int id PK
string name
string logo
}
注意：实际项目中需要根据业务特点调整，例如奢侈品电商可能需要增加鉴定报告实体，生鲜电商需要增加批次/保质期字段
2.2 规格参数系统的实现方案
商品规格系统是设计难点，经过多次踩坑后我推荐采用三级结构：
- 规格组（如"颜色"、"尺寸"）
- 规格项（如"红色"、"XL"）
- 规格值（实际存储的SKU组合值）
最佳实践是使用JSONB类型存储规格数据（以PostgreSQL为例）：
sql复制CREATE TABLE product_specs (
sku_code VARCHAR(32) PRIMARY KEY,
spu_code VARCHAR(32) NOT NULL,
specs JSONB NOT NULL, -- 示例: {"color":"red","size":"XL"}
price DECIMAL(10,2) CHECK(price > 0),
stock INTEGER DEFAULT 0
);
-- 建立GIN索引加速规格查询
CREATE INDEX idx_product_specs ON product_specs USING GIN(specs);
3. 高并发场景下的技术实现
3.1 商品详情页的性能优化
某次大促期间，我们商品接口QPS峰值达到12万，通过以下方案保证响应时间<50ms：
多级缓存策略：
- 客户端缓存：ETag+304 Not Modified
- CDN边缘缓存：静态资源+商品基础信息
- 分布式缓存：Redis集群存储热点商品
- 本地缓存：Caffeine缓存规格参数
java复制// 伪代码示例：多级缓存查询逻辑
public ProductDetail getProductDetail(String skuCode) {
// 1. 检查本地缓存
ProductDetail detail = localCache.get(skuCode);
if (detail != null) return detail;
// 2. 查询分布式缓存
detail = redisTemplate.opsForValue().get("product:" + skuCode);
if (detail != null) {
localCache.put(skuCode, detail);
return detail;
}
// 3. 回源数据库并设置缓存
detail = productDAO.getDetail(skuCode);
redisTemplate.opsForValue().set(
"product:" + skuCode,
detail,
5, TimeUnit.MINUTES,
random.nextInt(30) // 缓存时间随机防止雪崩
);
return detail;
}
3.2 库存管理的分布式事务
我们采用"预占库存+异步确认"的方案解决超卖问题：
-
下单时先执行库存预占：
sql复制UPDATE sku_stock SET locked_stock = locked_stock + ? WHERE sku_code = ? AND (stock - locked_stock) >= ? -
支付成功后异步扣减真实库存：
sql复制UPDATE sku_stock SET stock = stock - ?, locked_stock = locked_stock - ? WHERE sku_code = ? -
订单超时未支付则释放预占：
sql复制UPDATE sku_stock SET locked_stock = locked_stock - ? WHERE sku_code = ?
4. 商品搜索的架构设计
4.1 搜索引擎选型对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Elasticsearch | 分词能力强，支持复杂聚合 | 资源消耗大，运维复杂 | 综合电商、多维度搜索 |
| Solr | 稳定性高，文档丰富 | 实时性稍差 | 商品属性固定的垂直电商 |
| MySQL全文索引 | 无需额外组件，一致性高 | 性能有限，功能简单 | 小型电商、初期项目 |
4.2 搜索字段的索引策略
建议建立如下索引组合（以ES为例）：
json复制{
"mappings": {
"properties": {
"spu_title": {
"type": "text",
"analyzer": "ik_max_word",
"fields": {
"keyword": {"type": "keyword"}
}
},
"category_path": {
"type": "keyword"
},
"price": {
"type": "scaled_float",
"scaling_factor": 100
},
"specs.color": {
"type": "keyword"
}
}
}
}
5. 商品管理的扩展设计
5.1 多商户商品体系
平台型电商需要处理商户自营商品与平台商品的混合管理，我们的解决方案是：
- 商品表增加
tenant_id字段区分归属 - 价格策略采用"基准价+商户溢价"模式
- 搜索服务按商户权限过滤结果
5.2 商品审核流程
建议采用状态机模式管理商品生命周期：
python复制class ProductStateMachine:
states = ['DRAFT', 'PENDING_REVIEW', 'APPROVED', 'REJECTED', 'OFFLINE']
transitions = [
{'trigger': 'submit', 'source': 'DRAFT', 'dest': 'PENDING_REVIEW'},
{'trigger': 'approve', 'source': 'PENDING_REVIEW', 'dest': 'APPROVED'},
{'trigger': 'reject', 'source': 'PENDING_REVIEW', 'dest': 'REJECTED'},
{'trigger': 'relist', 'source': 'REJECTED', 'dest': 'DRAFT'},
{'trigger': 'offline', 'source': 'APPROVED', 'dest': 'OFFLINE'}
]
在实际项目中，商品模块往往需要20-30个开发人日的持续迭代。建议初期先实现最小可行版本（SPU/SKU基础模型+库存管理），后续根据业务增长逐步扩展促销体系、评价系统等关联模块。我们团队在第三次重构时引入的"商品快照"方案，成功将订单纠纷率降低了47%——这印证了良好的商品模块设计对电商业务的关键价值。