一、数据库设计
1. 商品主表(Product)
- 存储商品基础信息:`product_id`、名称、分类、品牌、描述、主图等。
- 关联字段:`category_id`(分类ID)、`brand_id`(品牌ID)。
2. 规格模板表(SpecTemplate)
- 定义规格类型(如重量、包装、口味):`template_id`、名称、描述。
- 示例:水果类可定义“重量(500g/1kg)”,零食类定义“包装(袋装/盒装)”。
3. 规格值表(SpecValue)
- 存储具体规格选项:`value_id`、`template_id`(关联模板)、值(如“500g”)、排序权重。
4. 商品规格关联表(ProductSpec)
- 绑定商品与规格模板:`product_id`、`template_id`、是否多选(如“口味”可多选)。
5. SKU表(Sku)
- 生成具体商品规格组合:`sku_id`、`product_id`、规格值组合(JSON或关联表)、价格、库存、条形码。
- 示例:苹果(500g/红富士)→ SKU_001,苹果(1kg/红富士)→ SKU_002。
二、业务逻辑实现
1. 规格组合生成
- 算法:通过递归或位运算生成所有可能的规格组合(如重量×包装×口味)。
- 去重优化:过滤无效组合(如“500g+盒装”可能不存在)。
- 动态定价:根据规格值调整价格(如大包装单价更低)。
2. 库存管理
- SKU级库存:每个SKU独立管理库存,避免超卖。
- 库存预警:设置阈值,低库存时自动提醒或下架。
- 锁库存:用户下单时锁定对应SKU库存,支付超时释放。
3. 价格计算
- 基础价+规格溢价:如基础价10元,加“有机”标签+5元。
- 促销活动:支持按SKU或规格维度打折(如“500g装8折”)。
三、前端交互设计
1. 规格选择器
- 多级联动:用户选择“重量”后,动态加载对应“包装”选项。
- 视觉反馈:已选规格高亮显示,不可选规格置灰。
- 实时价格:选择规格后立即显示最终价格。
2. 商品详情页
- 规格矩阵:以表格形式展示所有SKU及价格(适合少量规格)。
- 图片切换:不同规格对应不同商品图(如不同颜色包装)。
3. 购物车与结算
- 合并显示:购物车中展示“商品名+规格”(如“苹果 500g 红富士”)。
- 规格修改:支持在购物车中直接更改规格(需校验库存)。
四、系统扩展性优化
1. 规格模板复用
- 同一分类商品共享规格模板(如所有水果共用“重量”模板)。
- 支持模板版本控制,修改后不影响已绑定商品。
2. API设计
- 获取规格列表:`GET /api/products/{id}/specs` 返回模板及可选值。
- 获取SKU信息:`GET /api/skus?product_id={id}&spec_values=500g,袋装` 返回匹配SKU。
3. 缓存策略
- 规格数据缓存至Redis,减少数据库查询。
- SKU库存使用分布式锁(如Redlock)防止超卖。
五、典型业务场景处理
1. 缺货处理
- 当某SKU库存为0时,前端自动禁用对应规格组合。
- 提供“到货通知”功能,用户订阅后库存恢复时推送提醒。
2. 规格依赖
- 逻辑约束:如“1kg装”必须选择“礼盒包装”。
- 技术实现:在SKU生成时通过规则引擎校验组合有效性。
3. 批量操作
- 后台支持按规格维度批量修改价格或库存(如所有“500g”装降价)。
六、测试与监控
1. 测试用例
- 规格组合全量测试:确保所有可能组合均能正确生成SKU。
- 并发测试:模拟多用户同时购买同一SKU,验证库存扣减准确性。
2. 监控指标
- 规格加载耗时:确保前端选择器响应<500ms。
- SKU库存同步延迟:监控缓存与数据库一致性。
七、技术选型建议
- 数据库:MySQL(关系型)或MongoDB(文档型,适合灵活规格)。
- 缓存:Redis(存储规格模板和SKU库存)。
- 搜索:Elasticsearch(支持按规格筛选商品)。
- 框架:Spring Cloud(微服务架构)或React/Vue(前端交互)。
通过以上设计,美团买菜系统可实现高效的多规格商品管理,同时保障用户体验和系统稳定性。实际开发中需根据业务规模调整技术细节,如采用分布式ID生成器(如Snowflake)确保SKU唯一性。