简介：这份《电商平台软件架构.pdf》面向电商后端开发、架构设计与技术面试人群，系统梳理高并发电商系统的分层与组件设计，帮助读者建立从业务到基础设施的完整认知框架。内容围绕中台服务展开，涵盖订单、库存、支付、购物车、积分/代金券等核心服务，并延伸至分布式缓存、消息队列、数据存储、API网关、运维监控、第三方接口与安全体系，同时给出中央主库、读写库、TMS/WMS/BI库的数据库架构与订单全流程链路，附黄金超市系统架构图辅助理解。资源包为1个PDF文件，大小约342KB，轻量便于随时查阅与打印。目前已有103人学习，适合作为架构入门梳理、方案设计参考或面试复习提纲，可快速掌握中台复用、读写分离、异步解耦与订单状态同步等关键设计思路。
1. 电商平台软件架构：从一份 PDF 到能扛住大促的落地骨架
很多人第一次拿到「电商平台软件架构.pdf」这类资料时，会下意识把它当成一份可以照抄的图纸，结果照着搭出来的系统在平时跑得好好的，一到大促就雪崩。问题不在 PDF 本身，而在于电商平台软件架构从来不是一张静态图，它是一组围绕「流量突增、库存一致、订单不丢、资金对账」这几个硬约束反复权衡出来的决策集合。这份资料真正值钱的地方，是它把商品、库存、订单、支付、履约这几条链路怎么拆分、怎么通信、怎么兜底讲清楚了。它适合两类人：一类是正准备从单体往微服务迁移的中小团队，另一类是已经拆了服务但被分布式事务和数据一致性折磨的工程师。接下来我不复述 PDF 的目录，而是把它背后的选型逻辑和可复现的落地步骤拆开讲，让你看完能判断自己该抄哪一段、绕开哪个坑。
2. 电商平台软件架构的分层与拆分逻辑：为什么不能一上来就微服务
电商系统的复杂度不是均匀分布的。浏览商品、搜索、推荐这些读多写少的链路，和下单、扣库存、支付这些写操作强一致的链路，对架构的要求完全不同。一份靠谱的电商平台软件架构资料，第一步一定是做业务分层，而不是先画一堆微服务方框。常见做法是按「接入层、应用层、领域层、基础设施层」四层切，再把领域层按业务能力拆成商品域、库存域、交易域、支付域、履约域。这样拆的好处是每个域可以独立选型：商品域可以上缓存和搜索引擎，交易域必须保证事务和幂等。
2.1 按业务能力拆分领域边界
拆分的核心依据是「谁和谁必须强一致，谁和谁可以最终一致」。下单时扣库存必须和创建订单在同一个事务边界内，否则会出现超卖；而订单创建成功后发短信通知、更新推荐画像，这些完全可以异步。我一般会先画一张业务能力矩阵，横轴是业务动作，纵轴是涉及的数据实体，交叉点标出读写类型和一致性要求。矩阵里同一行强依赖的实体，就划进同一个域。
业务动作 订单表 库存表 商品表 用户表 创建订单 写 写 读 读 取消订单 写 写 读 - 支付回调 写 - - 读 浏览商品 - - 读 读这张矩阵能直接告诉你：订单和库存必须放在一个能共享事务的边界里，或者用可靠消息加对账来补偿。很多团队一上来就把订单和库存拆成两个独立服务，结果被分布式事务拖垮，这就是没做这一步的代价。
2.2 从单体到微服务的迁移路径
如果你现在还是单体，不要一步到位拆成十几个服务。稳妥的路径是「先模块化，再服务化」。模块化阶段在单体内部按包名隔离领域，禁止跨模块直接访问对方的数据库表，只能通过接口调用。这一步做完，代码边界清晰了，再挑压力最大或者变更最频繁的模块先拆出去。
# 单体内部模块化示例目录结构 com.example.mall ├── product # 商品域，只暴露 ProductFacade │ ├── api │ ├── domain │ └── infrastructure ├── inventory # 库存域，只暴露 InventoryFacade ├── order # 订单域，依赖 inventory.api 而非其实现 └── payment迁移顺序建议是：先拆无状态、读多的服务（商品查询、搜索），再拆有状态但边界清晰的（库存），最后拆交易和支付。每拆一个服务，都要先补上监控和链路追踪，否则出了问题你连日志在哪都不知道。参数上，服务拆分初期线程池和连接池不要按理论峰值配，按当前峰值的 1.5 倍留余量，观察一周再调。
3. 高并发场景下的读写分离与缓存设计：把大促流量挡在数据库之外
电商平台软件架构里最容易被低估的就是读链路的压力。大促时商品详情页的 QPS 可能是平时的几十倍，如果全部打到数据库，再好的分库分表也扛不住。这一章讲清楚缓存怎么用、读写怎么分、以及缓存和数据库不一致时怎么兜底。
3.1 多级缓存与热点探测
常见做法是「本地缓存 + 分布式缓存 + 数据库」三级。本地缓存扛住单机热点，分布式缓存扛住集群共享数据，数据库只做兜底。热点探测可以用滑动窗口统计 key 的访问频次，超过阈值就自动提升到本地缓存。
# 简化版热点 key 探测，基于滑动窗口计数 from collections import defaultdict, deque import time class HotKeyDetector: def __init__(self, window_sec=10, threshold=100): self.window = window_sec self.threshold = threshold self.access = defaultdict(deque) # key -> 时间戳队列 def record(self, key): now = time.time() q = self.access[key] q.append(now) # 清理窗口外的记录 while q and now - q[0] > self.window: q.popleft() return len(q) >= self.threshold # 是否判定为热点这段代码的逻辑是：每个 key 维护一个时间戳队列，记录访问时刻，超过窗口的旧记录弹出，队列长度超过阈值就判定为热点。参数window_sec控制统计窗口，大促时建议设短一点比如 5 秒，threshold根据单机 QPS 能力设，一般取单机峰值的 10% 到 20%。判定为热点后，把该 key 写入本地缓存并设置较短的过期时间，比如 1 到 3 秒，避免本地数据长期不更新。
3.2 缓存与数据库的一致性策略
缓存不一致是电商架构里的经典玄学问题。常见做法是「先更新数据库，再删除缓存」，而不是更新缓存。删除失败时用消息队列重试，并记录操作日志。对于库存这种强一致要求高的数据，不要只依赖缓存，扣减必须走数据库行锁或分布式锁，缓存只用于展示。
-- 库存扣减，带乐观锁版本号，防止超卖 UPDATE inventory SET stock = stock - #{quantity}, version = version + 1 WHERE sku_id = #{skuId} AND stock >= #{quantity} AND version = #{version};这条 SQL 的关键在stock >= #{quantity}和version条件，前者防止扣成负数，后者防止并发覆盖。执行后检查影响行数，为 0 说明库存不足或版本冲突，需要重试或返回失败。参数version从查询时带过来，重试次数建议不超过 3 次，超过就降级为排队或直接提示用户。
提示：缓存删除失败的重试消息一定要带唯一业务 ID，消费端做幂等，否则重试会把旧数据反复写回。
4. 分布式事务与最终一致性：订单、库存、支付怎么不打架
订单创建、库存扣减、支付回调这三件事跨了多个服务，强一致事务在性能和可用性上都很难接受。电商平台软件架构里普遍采用最终一致性方案，核心是「本地消息表 + 定时补偿 + 对账」。这一章讲清楚怎么落地，以及哪些环节绝对不能省。
4.1 本地消息表实现可靠事件投递
本地消息表的思路是：业务操作和消息写入在同一个本地事务里完成，然后由独立线程把消息投递到消息队列，投递成功再标记消息已发送。这样即使投递失败，消息也不会丢。
-- 本地消息表结构 CREATE TABLE local_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_id VARCHAR(64) NOT NULL, -- 业务唯一 ID，用于幂等 topic VARCHAR(64) NOT NULL, payload TEXT NOT NULL, status TINYINT DEFAULT 0, -- 0 待发送 1 已发送 2 已消费 retry_count INT DEFAULT 0, next_retry_at DATETIME, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_biz (biz_id, topic) );业务代码里，扣库存和写消息在同一个事务中提交。投递线程扫描status=0且next_retry_at到期的记录，发送到消息队列，成功后更新status=1。消费端处理完更新status=2。retry_count超过阈值比如 10 次，就告警人工介入。next_retry_at用指数退避计算，避免频繁重试压垮下游。
4.2 对账与补偿任务的设计
再可靠的异步方案也会有漏网之鱼，所以每天必须有对账任务。对账的核心是比对「订单状态」和「支付流水」「库存流水」是否一致。常见做法是 T+1 跑批，把差异记录到异常表，由人工或自动补偿处理。
# 简化的对账逻辑：比对订单和支付流水 def reconcile(order_list, payment_list): payment_map = {p.order_id: p for p in payment_list} diff = [] for order in order_list: pay = payment_map.get(order.id) if not pay: diff.append(("missing_payment", order.id)) elif order.status == "PAID" and pay.status != "SUCCESS": diff.append(("status_mismatch", order.id)) elif order.amount != pay.amount: diff.append(("amount_mismatch", order.id)) return diff这段逻辑覆盖了三种常见差异：支付流水缺失、状态不一致、金额不一致。实际生产中还要考虑退款、部分支付等场景。对账结果写入异常表后，补偿任务根据差异类型决定是自动修复还是转人工。参数上，对账批次大小建议控制在 1000 到 5000 条，太大容易超时，太小跑不完。
注意：对账任务本身也要幂等，重复跑不能产生重复补偿。
5. 避坑与排查：电商架构落地时最容易翻车的 5 个点
这一章是我自己踩过的坑，每条按「现象 → 原因 → 解决」写，希望能帮你省下几个通宵。
5.1 大促前扩容了应用，数据库却先挂了
现象：应用服务器 CPU 很低，但数据库连接数爆满，接口大面积超时。原因：应用扩容后，每个实例的连接池都按最大值配置，总连接数超过了数据库上限。解决：连接池大小按「数据库最大连接数 / 应用实例数」估算，并留 20% 余量；同时给数据库连接加熔断，超过阈值直接拒绝而不是排队。
5.2 缓存雪崩导致商品详情页集体 502
现象：某个时间点大量缓存同时过期，请求全部打到数据库。原因：缓存过期时间设成了统一值，没有加随机抖动。解决：过期时间加随机偏移，比如基础 300 秒加 0 到 60 秒随机；热点数据用逻辑过期，后台异步刷新，不直接失效。
5.3 分布式事务重试导致库存重复扣减
现象：用户只下了一单，库存却扣了两次。原因：消息重试时消费端没有做幂等，同一条消息被处理多次。解决：消费端用业务唯一 ID 做去重表，处理前先插入去重记录，插入成功才继续，失败直接返回成功。
5.4 分库分表后跨库查询拖垮性能
现象：订单列表页越来越慢，最后超时。原因：分库分表后，按用户维度查订单需要跨多个库，每次都要聚合。解决：建立异构索引表，把常用查询维度冗余一份，比如按商家维度再分一套表，写入时双写，查询走对应索引。
5.5 监控缺失导致故障定位靠猜
现象：线上出问题，团队花了两个小时才定位到是某个下游接口超时。原因：没有链路追踪，日志分散在各台机器。解决：接入链路追踪，给每个请求打上 traceId，日志按 traceId 聚合；关键接口加黄金指标监控：QPS、延迟、错误率、饱和度。
6. 用压测和混沌工程验证架构：别等大促才后悔
架构设计得再好，没经过验证都是纸上谈兵。我一般会在上线前做两件事：全链路压测和混沌演练。全链路压测不是简单压一个接口，而是模拟真实用户行为，从登录、浏览、加购、下单到支付走完整条链路，观察每一层的瓶颈。压测数据要和生产隔离，但链路要一致，否则压出来的结果没有参考价值。
# 用 wrk 对下单接口做基础压测，带 Lua 脚本模拟参数 wrk -t4 -c200 -d60s --latency \ -s ./post_order.lua \ http://order-service/api/order/create-t4是 4 个线程，-c200是 200 个并发连接，-d60s压 60 秒，--latency输出延迟分布。Lua 脚本里动态生成用户 ID 和商品 ID，避免压测数据集中导致缓存命中率虚高。压测时重点看 P99 延迟和错误率，P99 超过 500ms 就要查原因，错误率超过 0.1% 就要停下来。
混沌演练是主动注入故障，比如随机杀掉一个库存服务实例、给数据库加延迟、模拟消息队列不可用，观察系统是否能自动恢复或降级。我习惯从影响最小的故障开始，逐步加大，每次演练前想好回滚方案。有一次演练中我发现订单服务在库存服务不可用时没有降级，直接抛异常给用户，后来加了本地库存快照和排队机制，用户体验好了很多。
验证架构还有一个容易被忽略的点：数据一致性校验。压测和演练之后，跑一遍对账任务，看看有没有产生脏数据。如果有，说明补偿逻辑有漏洞，必须修完再上线。这个习惯帮我避免了好几次大促后的数据修复噩梦。
希望帮到你。
本文还有配套的精品资源，点击获取
