简介这是一份面向计算机科学与技术、信息管理及相关专业学生的《管理信息系统》课程设计参考文档核心内容为电子商务网站的系统设计。文档从系统分析入手完整覆盖网站前台业务需求、系统功能图、前后台功能需求、数据库设计、用户体验、安全机制、搜索引擎优化、项目管理与法律合规等知识点并附有具体的模块划分与页面功能描述适合正在撰写系统设计说明书、准备课程设计答辩或初学电商系统架构的读者使用。资源为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 容量估算与资源规划表表格是系统设计文档里最高信息密度的部分。下面是一张可以直接参考的估算模板场景日请求量峰值 QPS/TPS存储增量/日主要手段商品详情浏览2000万5000无CDN Redis 缓存搜索/筛选300万750日志 50GBElasticsearch 集群加入购物车50万125数据库 100MB关系型数据库提交订单3万10数据库 30MB事务 消息队列支付回调3万10数据库 30MB可靠消息 幂等根据这张表后端服务的起始规模就很容易推出来详情页读多写少前面挂 CDN 和 RedisWeb 服务节点按单机支撑 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 速查表压测结果达标的标准指标普通浏览场景下单场景P99 响应时间 500ms 1000msP95 响应时间 200ms 500ms错误率 0.1% 0.01%MySQL 慢查询1s0 条0 条Redis 命中率 95% 90%压测完成后把达到以上指标时的并发数和资源利用率记录在文档中。后续每次变更上线前跑一遍相同的压测场景做回归对比。这样系统设计就不是一份静止的 Word 文档而是随着流量增长和代码演进不断更新的活地图。本文还有配套的精品资源点击获取