一、前言1.1 写作初衷如果说用户中心是电商的身份底座那商品中心就是电商的业务基石、流量入口、交易源头。从事Java开发7年的工程师绝大多数对商品模块的认知只停留在SPU是商品整体、SKU是具体规格的浅层概念只会简单做新增、修改、上下架CRUD。但在亿级电商平台中商品中心是整个系统最复杂、数据量最大、变更最频繁、关联链路最多的核心领域。订单、库存、价格、营销、搜索、推荐、售后所有链路全部强依赖商品模型。商品模型一旦设计不合理会引发营销叠加错乱、库存扣减异常、搜索检索失效、订单创建失败、数据对账不平、迭代效率极低等一系列连锁架构问题。15年资深架构师和普通开发的核心差距普通开发只会实现商品功能架构师会设计支撑百万级SKU、多业态兼容、常年迭代不变动的通用商品模型。本文摒弃网上碎片化、入门级的SPU/SKU讲解从DDD领域边界、核心模型原理、类目属性体系、生产级表结构、全生命周期管控、高并发上下架、架构取舍、线上踩坑复盘全方位落地企业级商品中心架构带你掌握大厂通用的商品建模方法论彻底吃透电商核心根基。1.2 本文核心收益读完本文你将彻底掌握商品中心DDD限界上下文与领域边界彻底杜绝业务模型耦合问题SPU/SKU核心底层原理、设计本质、适用场景告别模糊认知平台类目、商品属性、规格参数的标准化建模方案大厂通用商品完整生命周期架构设计新增、审核、上架、下架、删除、归档百万级商品海量数据存储、检索、冷热分离解决方案高并发商品上下架架构、缓存一致性、ES同步最终一致性方案商品模块高频线上故障根治方案与架构演进思路大厂商品架构面试高频考点高分应答逻辑1.3 前置回顾上一篇我们完成了用户中心领域架构完整落地搭建了全站统一身份、权限、安全体系。本文将基于五层微服务架构与DDD拆分原则落地电商最核心、最复杂的商品领域为后续购物车、价格引擎、下单交易链路打下坚实模型基础。二、商品中心DDD领域边界定义架构师核心认知2.1 限界上下文精准定义商品领域核心职责负责全平台商品数据标准化管理、类目属性管控、商品生命周期流转、商品数据检索与透出为全链路业务提供标准商品基础数据。核心只解决一个问题标准化定义商品是什么、商品有什么属性、商品处于什么状态。2.2 领域绝对边界红线规则高频踩坑点2.2.1 归属商品领域商品新增、编辑、审核、上架、下架、删除、归档SPU/SKU基础信息维护类目、品牌、参数属性管理商品图片视频素材管理商品状态管控、基础数据透出。2.2.2 绝对不归属商品领域架构核心取舍商品价格、活动价、优惠价归属营销价格领域90%新手架构必踩坑商品库存数量、库存锁定归属独立库存领域商品销量、访客数据归属数据统计领域商品收藏、浏览记录归属用户行为领域商品订单交易数据归属订单交易领域架构黄金原则商品中心只存静态、固有、不变的商品属性所有动态、可变、业务关联数据全部剥离保证商品领域极致稳定、高可用、低变更。三、商品核心模型深度拆解SPU/SKU本质原理3.1 为什么必须拆分SPU和SKU架构设计根源很多工程师工作多年依然搞不懂SPU/SKU拆分的架构本质只停留在表面认知。架构设计初衷复用共性、区分差异减少冗余数据、统一标准化管理。一款手机品牌、型号、介绍、详情是所有规格通用的共性数据颜色、内存、价格、库存是不同规格的差异数据。如果不拆分SPU/SKU每一个规格都重复存一遍商品详情、参数、品牌信息会产生海量数据冗余、更新成本极高、数据一致性无法保证。3.2 SPU核心概念标准化产品单元SPU 一款标准商品的共性集合存储商品不变、通用、公共的核心信息品牌、类目、商品名称、商品详情、图文介绍、通用参数、售后服务说明。核心特征一个SPU代表一款商品不随规格变化全局唯一。3.3 SKU核心概念最小库存交易单元SKU 商品可交易、可库存、可下单的最小粒度存储商品差异化、可变、交易相关信息颜色、尺寸、规格、售价、成本、库存、重量、编码。核心特征用户下单、库存扣减、价格计算、物流计费全部以SKU为最小单元。3.4 模型落地场景举例iPhone 15 是一个SPUiPhone 15 黑色 128G、iPhone 15 白色 256G 是两个不同的SKU共性数据统一维护在SPU差异数据独立维护在SKU完美实现一次编辑、全局生效差异化独立管控。四、类目属性规格体系建模电商标准化核心商品之所以能实现搜索筛选、分类展示、参数匹配核心依托于三级类目属性参数规格体系的标准化建模这是支撑百万级商品统一管理的底层核心。4.1 三级类目体系平台通用标准所有电商统一采用一级类目→二级类目→三级类目三级分层架构不允许四级及以上类目避免层级过深、运维复杂、用户体验差。一级类目大品类数码、服饰、食品、家居二级类目细分品类数码→手机、耳机、平板三级类目精准品类手机→苹果手机、华为手机架构设计亮点三级类目绑定对应属性模板同一类目下的商品参数统一标准化保证平台商品数据规整、筛选统一。4.2 属性与规格差异化建模4.2.1 商品属性筛选参数用于列表页筛选、搜索匹配公共可筛选维度例如产地、材质、保质期、屏幕尺寸。属性不影响价格、不区分SKU。4.2.2 商品规格SKU区分参数用于区分不同SKU直接影响交易、价格、库存例如颜色、内存、尺寸、版本。规格变化必然生成新SKU。架构核心区分规则能用来筛选但不改变价格库存的是属性能改变价格库存、区分单品的是规格。五、生产级核心表结构设计带索引、带设计思路以下为阿里、京东通用生产级商品核心表完全适配平台型、自营型电商字段精简、索引合理、无冗余、可支撑亿级数据。5.1 商品SPU主表 product_spu存储商品所有共性公共数据数据稳定、变更少、查询量大。-- 商品SPU主表存储商品静态共性数据 spu_id BIGINT 雪花主键ID spu_name VARCHAR 商品名称 brand_id BIGINT 品牌ID category3_id BIGINT 三级类目ID product_desc TEXT 商品详情图文 service_policy VARCHAR 售后政策 status TINYINT 商品状态0-草稿 1-待审核 2-已上架 3-已下架 4-已归档 5-已删除 is_hot TINYINT 是否热门商品0-否 1-是 create_time DATETIME 创建时间 update_time DATETIME 更新时间 -- 核心索引适配高频查询、筛选场景 PRIMARY KEY (spu_id) INDEX idx_category (category3_id) -- 类目维度批量查询商品 INDEX idx_status (status) -- 商品状态筛选 INDEX idx_brand (brand_id) -- 品牌维度筛选设计亮点只存公共静态数据剥离所有动态交易字段保证SPU表轻量化、查询极速。5.2 商品SKU表 product_sku存储差异化交易数据是库存、价格、下单的核心关联表高频读写。-- 商品SKU表存储商品差异化交易数据下单/库存/价格最小单元 sku_id BIGINT 雪花主键ID spu_id BIGINT 关联SPU主键ID sku_name VARCHAR SKU规格名称 spec_value VARCHAR 规格组合值如黑色128G price DECIMAL 销售售价前台展示价 cost_price DECIMAL 成本价内部核算 market_price DECIMAL 市场价划线价 weight DECIMAL 商品重量物流计费用 status TINYINT SKU状态0-禁用 1-正常 create_time DATETIME 创建时间 update_time DATETIME 更新时间 -- 核心索引适配交易、查询高频场景 PRIMARY KEY (sku_id) INDEX idx_spu_id (spu_id) -- 根据SPU批量查询所有SKU INDEX idx_status (status) -- 筛选可交易有效SKU UNIQUE KEY idx_spu_spec (spu_id, spec_value) -- 杜绝同一SPU生成重复规格SKU5.3 商品属性表 product_attribute存储商品所有筛选属性支撑列表页筛选、搜索检索。-- 商品属性表存储筛选类公共属性用于前台搜索、分类筛选 id BIGINT 自增主键 spu_id BIGINT 关联SPU主键ID attr_name VARCHAR 属性名称如产地、材质 attr_value VARCHAR 属性值如国产、纯棉 sort INT 排序权重前台展示排序 -- 核心索引 INDEX idx_spu_id (spu_id)5.4 商品规格关联表 product_spec存储SKU规格组合数据支撑多规格动态生成SKU能力。-- 商品规格关联表存储SKU维度差异化规格支撑动态SKU生成 id BIGINT 自增主键 sku_id BIGINT 关联SKU主键ID spu_id BIGINT 关联SPU主键ID spec_name VARCHAR 规格名称如颜色、内存 spec_value VARCHAR 规格值如黑色、128G -- 核心索引 INDEX idx_sku_id (sku_id) INDEX idx_spu_id (spu_id)六、商品全生命周期架构管控完整闭环商品从创建到销毁拥有完整的状态流转架构必须严格管控每一个节点的权限、数据同步、状态一致性避免脏数据、异常商品透出。6.1 商品六大状态流转草稿 → 待审核 → 已上架 → 已下架 → 已归档 → 已删除草稿商家编辑中不对外透出、不占库存待审核编辑完成等待平台审核前台不可见已上架审核通过前台展示、可搜索、可下单交易已下架商家/平台手动下架停止交易保留数据可重新上架已归档长期未更新、停产商品归档封存禁止修改已删除逻辑删除数据留存备查彻底不可透出6.2 核心架构规则所有状态变更必须幂等防止重复上架、重复下架引发数据错乱上架商品强校验必填参数完整性、图片合规、价格合法、库存合法下架瞬间熔断交易购物车立即失效、停止新下单、关闭营销活动七、百万级商品高并发架构方案大厂生产级7.1 海量商品数据分层存储方案商品数据量大、查询频繁、搜索维度多单一MySQL无法支撑性能需求必须采用MySQL主存Redis缓存ES检索三层架构。MySQL存储权威原始数据负责增删改、事务一致性Redis集群缓存热门商品、首页商品、高频访问SKU扛住C端高并发查询Elasticsearch承载商品搜索、分类筛选、条件过滤、排序分页解脱MySQL查询压力7.2 高并发上下架 缓存一致性方案7.2.1 核心痛点商品上下架属于高频写操作会引发缓存失效、ES数据不同步、脏数据透出、搜索残留旧数据等问题。7.2.2 生产级最终一致性方案先更新MySQL商品状态保证数据库权威数据准确删除Redis对应商品缓存防止旧缓存残留发送RocketMQ商品变更事件消费端异步更新ES索引数据定时任务兜底比对MySQL与ES数据修复不一致脏数据架构师核心取舍思维大促场景商品上下架并发极高强一致性会严重拖慢接口吞吐量。因此主动放弃瞬时强一致采用「数据库先行缓存淘汰异步ES更新定时兜底」的最终一致性方案在系统高性能和数据准确性之间做到最优平衡完全适配亿级大促流量场景。7.3 商品冷热数据分离架构热数据近3个月上架、有销量、高访问商品常驻MySQLRedisES极致提速冷数据长期下架、无流量、老旧商品定时归档至历史表减少主表数据体量提升查询性能八、生产高频踩坑复盘真实线上事故8.1 坑点1动态数据耦合商品表引发全线错乱现象商品价格、库存变更频繁触发商品数据更新导致缓存频繁失效、ES频繁刷新、接口抖动。根因新手架构将价格、库存字段存入商品表动态变更牵连静态商品数据。根治方案严格DDD边界动态业务数据全部剥离独立领域商品表只存静态属性。8.2 坑点2SKU规格设计不规范生成重复SKU现象同一规格组合生成多个SKU导致下单库存错乱、价格混乱。根因无规格唯一校验未做sku规格组合唯一索引约束。根治方案SPU规格组合建立唯一索引杜绝重复SKU生成。8.3 坑点3商品下架后搜索仍能搜到用户无法下单现象后台商品已下架ES搜索依然透出用户点击下单失败体验极差。根因上下架只更新数据库异步ES更新延迟无兜底机制。根治方案下架同步删除热点缓存MQ异步更新ES定时任务兜底校验。8.4 坑点4无状态幂等控制重复上下架引发数据异常现象重复调用上架接口引发商品状态错乱、日志混乱、营销活动重复绑定。根治方案状态前置校验实现上下架接口全局幂等重复请求直接拦截。九、大厂面试高频考点 15年架构师高分话术SPU和SKU的设计本质是什么为什么电商必须拆分SPU/SKU商品属性和商品规格的核心区别分别适配什么业务场景商品上下架如何保证缓存、数据库、ES数据最终一致性海量商品场景下如何做冷热数据分离、性能优化商品模块最大的架构难点是什么如何避免业务耦合架构师高分答题模板回答商品架构问题遵循「业务本质→DDD边界→模型设计→技术方案→架构取舍→故障兜底」逻辑拒绝碎片化知识点体现系统化架构思维区别于普通CRUD开发。十、本篇总结 下篇预告10.1 本篇总结本文彻底拆解了电商商品中心的架构本质、领域边界、核心模型、表结构、生命周期管控、高并发解决方案彻底摆脱新手CRUD思维建立15年架构师级别的商品建模能力。核心架构思维商品架构的核心是标准化、解耦、稳定用静态模型支撑万千动态业务变化。10.2 下篇预告下一篇我们将深度落地购物车架构设计攻克未登录/登录状态、购物车合并、冷热数据分离、缓存架构、购物车校验、高并发加购等核心难点补齐电商交易前置核心链路。
