一、交易核心 - 高并发订单的生成与落地
1.1 引言：为什么“收单”是系统的生命线
在电商体系中，交易是核心，而订单是起点。一个高效、稳定的收单系统，决定了平台的承载能力与用户体验。在高并发场景（如秒杀、大促）下，系统的挑战早已超越传统的“增删改查”，转向对性能极限、数据一致性与弹性扩展的全面考验。本章将解析如何通过微服务拆分与架构优化，构建一个能从容应对瞬时流量洪峰的订单处理系统。
1.2 架构总览：微服务拆分与职责边界
微服务架构的核心价值在于解耦、弹性伸缩与容错。在订单处理流程中，系统通常被拆分为以下核心服务，每个服务各司其职：
- 订单中心：流程的指挥官，负责接收请求、协调各方服务、生成和管理订单生命周期，是状态机的维护者。
- 商品中心：资源的守护者，负责管理商品信息和库存，并实现高并发下的库存一致性。
- 促销中心：规则的计算器，负责计算各种活动优惠与优惠券金额。
- 支付中心：资金的通道，聚合支付渠道并处理支付请求与回调。
1.3 核心流程深度解析：一幅图看懂订单的一生
下面的序列图展示了订单从创建到支付成功的完整生命周期。流程中融入了预占库存、异步处理与最终一致性等核心设计思想。
1.4 决战高并发：三大核心设计哲学
序列图背后的设计体现了现代高并发系统的三大核心理念：性能优先、一致性保证与可用性平衡。系统架构的目标是让三者在高压场景中保持动态稳定。
1.4.1 库存一致性：防止超卖的核心机制
库存是电商的生命线，防止超卖是最关键的一环。
挑战：在高并发下，多个请求同时读取、计算和更新库存，极易导致超卖。
解决方案：使用 Redis Lua 脚本 + 分层库存模型。
- 预占库存：用户下单时，通过 Redis 执行 Lua 脚本原子性地预占库存，将库存从“可售库存”池移至“预占库存”池。
- 异步实扣：订单创建成功后，通过消息队列异步完成数据库层面的库存扣减，实现业务响应与持久化解耦。
- 超时回滚：订单超时未支付时，系统释放预占库存，避免资源长期占用。
这一设计的关键在于“预占而非实扣”，为支付环节的不确定性提供缓冲，使性能与稳定性兼得。
1.4.2 异步化与最终一致性：用时间换空间
异步化是提升系统吞吐量的核心手段。
核心思想是将必须即时响应的关键操作（如库存预占）与可延后的次要操作（如日志写入、通知发送）分离。
通过消息队列（MQ）实现异步处理，系统在完成核心逻辑后立即响应用户，而非等待所有环节结束，从而实现削峰与解耦。
这种“软状态”设计允许系统在暂时不一致的状态下仍能维持整体可用性，是 BASE 理论的典型实践。
1.4.3 幂等性设计：高可用的安全底线
在分布式系统中，请求重试是常态。幂等性设计确保多次重复请求的结果与一次执行一致。
常见做法是为每个请求分配全局唯一的请求 ID（例如雪花算法生成），系统在处理前校验该 ID 是否已存在，从而防止重复执行。
幂等性不仅是技术规范，更是一种面向失败的系统思维，为系统提供了容错与安全保障。
1.5 数据模型设计精要：支撑高并发的基石
清晰、稳定的数据模型是支撑高并发系统的基础。它需要既准确反映业务逻辑，又能为性能与事务提供保障。以下 ER 图展示了核心实体的关系：
orders bigint order_id PK 主订单ID bigint user_id FK 用户ID decimal total_amount 订单总金额 decimal pay_amount 实付金额 tinyint status 订单状态 datetime create_time 创建时间 shop_order bigint sub_order_id PK 子订单ID bigint order_id FK 主订单ID bigint shop_id FK 店铺ID decimal sub_total_amount 子订单金额 tinyint status 子订单状态 shop_order_item bigint item_id PK 订单商品项ID bigint sub_order_id FK 子订单ID bigint sku_id FK 商品SKU ID varchar product_name
《高并发电商架构设计与落地：从微服务拆分到全链路优化》 是转载文章，点击查看原文。
