电商系统设计实战：从业务拆解到高并发架构

简介：这是一份面向计算机科学与技术、信息管理及相关专业学生的《管理信息系统》课程设计参考文档，核心内容为电子商务网站的系统设计。文档从系统分析入手，完整覆盖网站前台业务需求、系统功能图、前后台功能需求、数据库设计、用户体验、安全机制、搜索引擎优化、项目管理与法律合规等知识点，并附有具体的模块划分与页面功能描述，适合正在撰写系统设计说明书、准备课程设计答辩或初学电商系统架构的读者使用。资源为1个doc文件，压缩包约2.02MB，内部按标准课程设计报告格式组织，包含项目概述、详细设计、测试说明等章节。已有34人学习下载。通过这份说明书，读者可直观理解电商类系统从需求分析到数据库落地的完整流程，学习如何撰写规范的设计文档，也能为个人商务网站等相似项目的开发与文档编排提供扎实参考。

1. 电子商务网站的系统设计在解决什么问题

电商系统看起来是一堆页面加一个购物车，但真正把它放到生产环境里跑，问题会从订单状态、库存扣减、支付回调、搜索排序一路蔓延到凌晨的大促流量。系统设计不是画一张架构图交差，而是要在需求不完整、流量不确定、团队分工不同的前提下，先把业务边界、数据一致性、扩展路径和故障边界定下来。这份设计文档的读者通常是后端开发、架构师、运维和产品，不同角色要从中拿到各自需要的输入：开发知道模块怎么拆、接口怎么定义，运维知道需要多少机器和监控项，产品知道哪些需求会被技术约束。

常见的误区是一上来就画微服务拓扑，或者直接选型 Kubernetes、Redis、消息队列。真正扎实的做法是先回答“业务规模是多少、数据长什么样、哪些操作绝对不能错”，再谈技术组件。下面按我平时做电商系统设计的顺序，把完整链路拆开讲。

2. 从业务拆解到容量估算：设计的前置输入

2.1 核心业务域与订单状态机

电商系统的设计首先要圈定业务边界，而不是技术边界。我习惯先把系统拆成六个业务域：商品域、库存域、订单域、支付域、用户域、营销域。每个域有独立的职责和数据归属，比如商品域管 SPU/SKU 和详情，库存域只负责可售数量，订单域管订单生命周期。域之间通过事件或接口通信，而不是共享数据库表。

订单状态机是整个系统里最容易被改坏的地方。初始状态一般是“已创建”，用户提交订单后进入“待支付”，支付回调成功进入“已支付”，然后流转到“已发货”“已完成”。但实际业务中还会插入“已取消”“退款中”“已关闭”等状态。设计时要把状态流转图直接画进文档，并明确每个状态变更的触发源是用户请求、支付回调还是定时任务。

已创建 -> 待支付 -> 已支付 -> 已发货 -> 已完成 | | | | | 退款中 -> 已退款 | 已取消 已关闭

这个状态机看起来简单，真正复杂的是超时未支付自动关闭、支付回调与用户取消并发到达时的处理。我一般会在状态机里规定：只有“待支付”状态允许取消，“已支付”状态必须由支付网关回调或人工补偿触发变更，任何其他路径都视为非法流转，直接抛异常。这样能规避掉大量因回调乱序导致的订单状态错乱。

2.2 流量模型与 QPS/TPS 估算

系统设计文档里必须有一张容量估算表，否则后面的集群规模、缓存容量、数据库分片都没法定。估算的起点不是“日活用户”，而是“核心操作的每秒请求数”。常见的做法是取峰值系数，比如日活 100 万，平均每个用户每天浏览 20 个商品详情页，那么商品详情 QPS 大约是 100万 * 20 / 86400 ≈ 231，但这是全天平均。电商有典型的峰值时段，比如晚 8 点到 10 点，流量可能是日均的 3 到 5 倍，所以峰值 QPS 要按 4 倍估算，约 920。

下单和支付属于写操作，频率远低于浏览。一般下单转化率在 2% 到 5% 之间，按日活 100 万、转化率 3% 计算，每天订单量 3 万，分摊到 4 小时峰值时段，下单 TPS 约为 30000 / 14400 ≈ 2，峰值按 5 倍算也就 10。这个量级单机数据库完全扛得住，真正让系统崩溃的往往是商品详情页的读流量和秒杀场景的瞬间写流量。

2.3 容量估算与资源规划表

表格是系统设计文档里最高信息密度的部分。下面是一张可以直接参考的估算模板：

根据这张表，后端服务的起始规模就很容易推出来：详情页读多写少，前面挂 CDN 和 Redis，Web 服务节点按单机支撑 1000 QPS 估算，准备 6 到 8 台；订单服务写多，单机支撑 100 TPS 足够，2 台起步，但为了保证可用性至少 3 台。数据库方面，订单表日增 3 万行，一年千万级，单表没有问题，但如果设计目标是三年不拆表，就需要提前按用户 ID 分片。

提示：容量估算里的数字不要精确到个位。系统设计文档的价值在于量级判断，不是预测未来。你只需证明“当前方案在目标流量下不会出现结构性瓶颈”。

3. 分层架构与核心模块的落地设计

3.1 经典分层与微服务拆分边界

对于大多数电商系统，我给出的架构不是满屏微服务，而是先分层，再在层内按业务域拆分。从下往上依次是：接入层（负载均衡、CDN、API 网关）、应用层（按业务域拆分的服务）、领域层（业务规则与状态机）、数据层（MySQL、Redis、Elasticsearch、对象存储）。基础设施层包含消息队列、注册中心、配置中心和监控链路。

微服务的拆分边界要以“业务变更频率”和“团队所有权”为依据，而不是按技术分层。商品、订单、支付、库存、用户这五个域天然具备独立的变更频率和扩展需求，适合拆成独立服务。而优惠券、购物车这类模块如果团队规模不够，可以先作为订单服务内的模块存在，等到出现独立团队或性能瓶颈再拆。一开始就拆成十几个服务，带来的网络开销、分布式事务和部署成本会远超收益。

网关层的关键设计是路由和鉴权分离。我通常会在网关做三件事：解析用户身份并写入请求头、按 URL 前缀路由到对应服务、做全局限流。业务参数校验、权限细化放在各服务内部。网关不应该承载业务逻辑，否则会变成一个大泥球。

3.2 商品、库存、订单的数据模型设计

数据模型是系统设计文档里最不能含糊的部分。商品域建议分四张表：spu（标准产品单元）、sku（库存量单位）、category（类目）、sku_attribute（规格属性）。SPU 是抽象商品，比如“iPhone 15”，SKU 是具体可售版本，比如“iPhone 15 黑色 256GB”。商品详情页展示的信息大部分来自 SPU，而购物车和订单只关心 SKU。

订单域的核心表是order和order_item。order表存订单主信息，包括订单号、用户 ID、总金额、状态、收货地址快照；order_item表存每个 SKU 的购买数量、单价、快照信息。为什么要做快照？因为商品名称、价格、图片在用户下单后可能被修改，订单必须保留下单那一刻的数据，否则后续售后、对账、审计都会出问题。快照字段可以冗余在order_item里，也可以单独存 JSON 字段，我倾向于后者，避免表字段爆炸。

库存数据模型比较特殊。库存分“物理库存”和“可售库存”，物理库存是仓库里真实的数量，可售库存是前台展示的可购买数量。用户下单扣减的是可售库存，支付成功后再锁定物理库存，发货后扣减物理库存。这个区分能避免用户拍下但未支付时占用真实库存，也不会出现超卖。

3.3 用 SQL 和伪代码实现下单核心流程

下单是最核心的写操作，涉及订单创建和库存扣减的原子性。常见的做法是“先扣库存，再创建订单”。下面是一个简化的伪代码流程：

begin transaction 1. 验证用户、收货地址、SKU 状态 2. 查询当前库存数量 3. 执行条件更新：库存扣减，仅当库存 > 购买数量 4. 如果影响行数为 0，回滚并返回“库存不足” 5. 插入 order 记录 6. 插入 order_item 记录 7. 提交事务 end transaction

对应的 SQL 核心是条件更新，而不是先查再改：

UPDATE inventory SET available_qty = available_qty - #{buyQty} WHERE sku_id = #{skuId} AND available_qty >= #{buyQty};

这条语句利用了 MySQL 的行锁和原子更新，避免并发下超卖。如果UPDATE返回的影响行数为 0，说明库存不足或 SKU 不存在，直接终止下单。订单表的插入在同一个事务里，保证库存扣减和订单创建的强一致。

为什么不用“先查库存，再扣减”？因为在并发场景下，两个请求可能同时查到剩余 1 件库存，然后都通过检查，导致超卖。条件更新把“检查库存”和“扣减库存”合并为一个原子操作，是最简单可靠的方案。不过这个方案在秒杀场景下会让所有请求竞争同一行锁，性能会急剧下降，后面第 4 章会讲怎么用 Redis 优化。

注意：事务里不要执行远程调用，比如调支付接口、发短信。远程调用的延迟和不确定性会拉长事务时间，导致数据库连接和锁资源被长时间占用。正确的做法是事务内只操作本服务数据库，事务成功后通过消息队列触发后续动作。

4. 高并发与一致性：缓存、MQ、分布式锁的配合

4.1 缓存更新策略与缓存击穿防护

电商系统里 90% 以上的流量都打在商品详情页上，缓存是抗住读压力的第一道防线。我常用的策略是 Cache Aside，读请求先查 Redis，命中直接返回；未命中则查数据库，回填缓存并设置过期时间。这个模式简单可靠，但有一个经典的坑：数据库更新和缓存淘汰的时序问题。

我见过很多团队先更新数据库再删缓存，但如果在删除缓存前有并发读请求把旧数据回填到缓存，就会导致长时间的数据不一致。更稳妥的做法是“延迟双删”，先删缓存，再更新数据库，最后延迟几百毫秒再删一次缓存。这个延迟值要根据业务的读写耗时来定，目的是等并发的读请求完成回填后，再清掉可能被写入的旧缓存。

缓存穿透和缓存击穿是两个必须处理的问题。穿透是查询了一个不存在的 key，每次都会打到数据库；击穿是某个热点 key 过期瞬间，大量请求同时打到数据库。防穿透的办法是缓存空值并设置较短过期时间，或者用布隆过滤器拦截。防击穿的办法是加互斥锁，只允许一个请求去查数据库并回填，其余请求等待后直接读缓存。一个简单的 Java 伪代码如下：

public String getProductInfo(String skuId) { String key = "product:" + skuId; String value = redis.get(key); if (value != null) { return value; } // 互斥锁：只让一个线程查库 String lockKey = "lock:product:" + skuId; boolean locked = redis.setIfAbsent(lockKey, "1", 3, TimeUnit.SECONDS); if (!locked) { // 没拿到锁，短暂等待后重试 Thread.sleep(50); return getProductInfo(skuId); } try { value = db.querySkuInfo(skuId); if (value == null) { redis.set(key, "", 60, TimeUnit.SECONDS); } else { redis.set(key, value, 900, TimeUnit.SECONDS); } return value; } finally { redis.delete(lockKey); } }

这段代码里的锁是为了控制回填数据库的并发，不是业务锁。锁的过期时间设 3 秒，要保证查库和回填在这个时间内完成，否则锁提前释放会导致重复回填。如果业务查询时长不稳定，可以把锁续期做成独立线程，但大多数电商场景 3 秒足够。

4.2 消息队列削峰与最终一致性

下单后的流程包括支付回调、通知仓储发货、发送短信通知、更新用户积分、同步搜索索引。这些动作如果全部同步执行，下单接口的响应时间会被拖到几秒，而且其中任何一个环节失败都会导致整个订单失败。实际上真正必须同步完成的只有订单创建和库存扣减，其余动作都可以异步化。

常见的做法是引入消息队列，比如 RocketMQ 或 Kafka。订单事务提交后，发送一个“订单已创建”事件到 MQ，下游服务各自消费。这里最难的是保证“本地事务”和“消息发送”的一致性：如果先提交事务再发消息，可能事务成功但消息发送失败；如果先发消息再提交事务，消费者可能在事务提交前就消费到不存在的订单。

业界比较落地的方案是事务消息，RocketMQ 在这方面支持得最完整。业务方先发送“半消息”，MQ 不会让消费者立刻看到；然后执行本地事务；本地事务成功后，反向确认消息可投递。如果 MQ 长时间收不到确认，会反向查业务方的本地事务状态，根据查询结果决定投递还是回滚消息。这套机制保证了消息最终会被投递，且不会出现订单未创建但消息已消费的情况。

4.3 库存扣减的 Redis 加 Lua 实现

高并发下直接把库存扣减压在 MySQL 行锁上容易把数据库打挂。秒杀和限量抢购场景的常见方案是先用 Redis 扣减库存，模糊地控制超卖风险，再把结果异步落库。Redis 的DECR命令天然原子，但我们需要“扣减前检查库存”的复合逻辑，这时就要用 Lua 脚本保证原子性。

-- 参数：KEYS[1] 是库存 key -- KEYS[2] 是已售 key（可选） -- ARGV[1] 是本次扣减数量 local available = tonumber(redis.call('GET', KEYS[1]) or '0') local buyCount = tonumber(ARGV[1]) if available < buyCount then return 0 end redis.call('DECRBY', KEYS[1], buyCount) return available - buyCount

这段脚本的核心逻辑是“先读取、再比较、最后扣减”，整个流程在 Redis 单线程内执行，不存在并发交叉。Java 侧可以通过DefaultRedisScript执行该脚本，脚本返回值大于等于 0 表示扣减成功，返回 0 表示库存不足。成功扣减后，将扣减记录写入消息队列，由消费端异步同步回 MySQL 的 inventory 表。

用 Redis 扣库存的代价是丢数据风险，比如 Redis 宕机可能丢失部分扣减记录。因此要有一个对账任务，定期将 Redis 中的剩余库存与 MySQL 的物理库存比对，发现差异后进行人工或自动修正。系统设计的文档里一定要写明这个对账机制，否则 Redis 方案无法通过业务方的审计。

5. 系统设计落地后的验证：链路压测与故障演练的三个技巧

5.1 压测链路要包含缓存和消息队列，而不是只打后端接口

很多团队压测只测单个服务的 QPS，结果上线后一接真实流量就崩。原因是压测没有覆盖完整链路，数据库连接池、Redis 连接池、MQ 生产端的线程数都会成为瓶颈。正确做法是压测从网关层发起，流量经过鉴权、路由、业务逻辑、缓存、数据库、消息队列的完整路径。可以用 JMeter 或 k6 写脚本，但压测数据要模拟真实分布，比如 80% 读请求打到商品详情、10% 加购、5% 下单、5% 其他，而不是均匀分布。

压测过程中重点观察三个指标：P99 延迟、数据库连接池活跃连接数、Redis 内存命中率。如果 P99 延迟突增但 CPU 不高，多半是线程池排队或锁等待；如果数据库连接数打满，说明缓存命中率不够或者 SQL 有慢查询；如果 Redis 命中率低于 90%，要检查缓存过期时间是否设置得过短。

5.2 用“降级开关”验证订单状态机在异常路径下的表现

系统设计里最容易被忽略的是“依赖不可用时的行为”。以支付回调为例，支付网关可能重复回调、乱序回调，甚至回调内容缺失。我的做法是在设计文档里明确每个核心依赖的降级策略，并在压测时主动关闭 Redis、设置 MySQL 慢查询阈值等手段模拟故障，验证订单流程是否还能走通。

一个实用的技巧是在缓存查询入口加“降级开关”，通过配置中心动态关闭缓存，让流量直接打到数据库。这个开关不仅能用来验证数据库的承载能力，还能在 Redis 故障时快速恢复服务。另一个技巧是对订单状态机做随机验证脚本，模拟“未支付就发货”“已取消就支付”等非法流转，确保每个非法路径都能被正确拒绝。

5.3 速查表：压测结果达标的标准

压测完成后，把达到以上指标时的并发数和资源利用率记录在文档中。后续每次变更上线前，跑一遍相同的压测场景做回归对比。这样系统设计就不是一份静止的 Word 文档，而是随着流量增长和代码演进不断更新的活地图。

本文还有配套的精品资源，点击获取