金宇澄做电商后端这几年，如果让我说哪个模块压力最大、坑最多，订单中心排第二，没人敢排第一。用户点一下“立即下单”，背后牵扯的链路远比表面看到的要复杂：库存、优惠、地址、支付、物流，几乎每个上游系统都在等订单结果。这一课我们就专门聊订单中心的高并发下单与分布式事务，适合刚接手电商后端、想搞清楚交易链路的小白，也适合已经在做架构设计、需要判断方案边界的开发者。下面内容全部围绕真实落地场景展开，希望你看完能直接拿这套思路去复盘自己的订单系统。
1. 订单中心是交易链路的“总线”：为什么它最难做
1.1 一张订单状态机怎么画才不返工
订单模块最典型的死亡陷阱，不是代码写错了，而是需求没想清楚就急着建表。很多人一上来就把 order_status 字段设计成几个枚举，以为“待支付、已支付、已发货、已完成、已取消”就是全部真相。结果上线后产品提了个“退款中”或“售后处理中”，你才发现状态根本没法表达。
我的习惯是先画完整的状态机，再写表结构。订单状态从用户视角看确实只有几个大状态，但在系统内部，每个大状态都要能派生出分支。比如“已支付”之后可能进入“已支付待发货”，支付渠道回调成功但库存扣减失败的订单，状态不能直接变成“已完成”，它必须停留在某个待补偿状态，等后台任务继续处理。
具体怎么写状态机？我会把所有可能的状态列成一张表，然后为每个状态标注“允许进入的动作”和“允许迁移到的目标状态”。比如：
CREATED可以接收支付回调，迁移到PAID；PAID可以接收发货动作，迁移到SHIPPED；CREATED也可以接收用户取消，迁移到CANCELLED；REFUNDING只能迁移到REFUNDED或CLOSED。
这张状态迁移表不仅要写在文档里，还要在代码里用状态机组件或枚举校验去强制约束。否则你今天允许“已取消”跳到“已发货”，明天就可能出现给取消订单发货的事故。
注意：状态机文档一定要和表结构字段同步维护。很多团队的状态机画了十来个状态，表里却只有一个
status字段，导致状态机的迁移动作根本没落地。正确的做法是字段至少包含status和sub_status，必要时再加refund_status、ship_status这样独立的子状态字段，宁可先多拆，也不要后面再去迁移数据。
1.2 订单中心该管什么，不该管什么
订单中心很容易被做成一个大杂烩，什么业务都往里塞。我以前见过一个订单服务，里面居然混着优惠券核销、积分扣除、发票开票逻辑，结果下单链路越来越长，随便一次发布都胆战心惊。
我的建议是订单中心只负责订单本身的生命周期管理：创建订单、维护状态、订单查询、订单快照。库存够不够、价格怎么算、优惠怎么分摊，这些业务规则尽量下沉到各自的领域服务里。订单中心对外暴露接口时，只传递必要的下单参数，比如商品ID、数量、地址ID、优惠券ID，而不是去替别人做计算。
这样做的好处有两个。第一，隔离故障：库存中心挂了，订单中心还能继续承接下单请求，只是最终会有一部分订单因为库存不足被拒绝；第二，方便演进：订单服务如果天天跟着营销规则变，那它永远没办法独立扩容。
当然，“订单中心不该管”不等于“下单链路不需要整体设计”。在这里会把库存中心、支付中心、优惠中心当成外部依赖，订单中心要做的是定义清晰的接口契约和超时策略，这是后面高并发和分布式事务讨论的前提。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 高并发下单：流量怎么进、库存怎么扣、并发怎么压
2.1 入口处的限流、熔断和参数校验
先泼一盆冷水：很多系统并不是被真实流量打垮的，而是被无效请求打垮的。大促期间，用户手速再快也不可能一秒钟提交几百次，真正的高并发里有大量重复提交、脚本刷单、恶意压测。所以高并发下单的第一道防线，不是数据库，而是接口入口。
参数校验是第一步，但这几乎是所有团队都会偷懒的一环。商品ID是否存在、购买数量是否超过限购、收货地址是否合法、下单时间是否在活动窗口内，这些校验如果等请求打到数据库再判断，数据库就会被无效 SQL 拖死。我的习惯是把所有静态校验放在 Controller 或网关层，用一个独立的 OrderCreateChecker 去执行，校验不通过直接返回，不再往下走。
第二步是限流。QPS 如果远高于系统处理能力，与其硬扛，不如主动丢弃一部分流量。订单接口的限流策略不能用全局限流，因为不同时间段、不同 SKU 的热度差异太大。建议针对用户ID做令牌桶限流，再针对活动维度做总配额控制，比如某个秒杀活动只放一万单，超过之后直接提示“活动太火爆”。
第三步是防重。用户重复点击下单按钮，或者支付回调超时后用户又手动提交一次，这些场景会在数据库产生重复订单。入口阶段就生成 request_id 或幂等键，系统对同一个幂等键只处理一次，这样比在数据库层面靠唯一索引去兜底更省资源。
2.2 库存扣减：数据库悲观锁、乐观锁还是Redis Lua
库存扣减是高并发下单里最容易出事的地方，核心要回答的一个问题，就是“怎么保证库存不会被减成负数”。
最简单也最容易被喷的方案就是数据库悲观锁，select * from stock where sku_id = ? for update。这个方案在并发量不大的时候没问题，锁住一行数据，扣减完再提交事务。但一旦秒杀流量进来，同一 SKU 的行锁竞争会非常激烈，数据库连接被大量占用，整个系统吞吐量直线下降。
乐观锁是改进方案，update stock set quantity = quantity - ? where sku_id = ? and quantity >= ?。这里数据库本身会锁行，但锁持有的时间极短，因为它只要更新一行，更新成功后返回影响行数，影响行数为0就说明库存不够。这个方案在库存量充足时效果很好，但库存剩最后几个时，大量请求会因为 quantity >= ? 判断失败而重试，用户体验会很差。
纯内存扣减也有隐患，比如直接把库存放在 Redis 的某个 key 里，用 decrby 操作。看似简单，但跨商品事务、超卖后的订单对账、库存恢复都很难处理。我的做法是用 Redis Lua 脚本做预扣，然后把真实扣减落到数据库。
核心思路是：
- 请求进来先走 Redis Lua，判断剩余库存是否足够，如果足够就
decrby预占库存； - 返回扣减成功后，再执行数据库扣减；
- 数据库扣减失败或订单取消时，异步补偿 Redis 库存。
Lua 脚本能保证原子性，而且 Redis 单线程模型保证了脚本执行期间不会被其他命令打断。下面这个脚本是基础版本：
lua复制local key = KEYS[1]
local quantity = tonumber(ARGV[1])
local stock = tonumber(redis.call('get', key) or '0')
if stock >= quantity then
redis.call('decrby', key, quantity)
return 1
end
return 0
数据库扣减也不能只用一条简单的 update，因为分布式系统里 Redis 扣减和数据库扣减不是同一个事务。我会在订单主表里记录“预占库存流水”，订单支付成功后才把预占变成实际消耗，订单取消则恢复库存。这一步的语义要非常清楚，否则后面会出现“Redis库存扣了100，数据库库存扣了80”这种对不上的情况。
2.3 压测口径：别拿假并发数据骗自己
很多人做压测时只关心 QPS，压到 1000 就以为系统没问题，其实这是被测试工具骗了。压测要贴近真实场景，不能只压一个接口，要把下单链路上下游都带上，至少包括库存查询、优惠计算、订单写入、支付回调模拟这几段。
我记得有一次做压测，单接口 QPS 能到两千，但串起来完整下单流程后，数据库连接池很快就满了。原因很简单，单接口压测只测了一个服务里的一个方法，真实链路里每个环节都要连接数据库，事务持续时间一长，连接不释放，吞吐量自然骤降。
压测更重要的是设置合理的并发模型。不能用一个“永远只有100个用户轮流请求”的脚本模拟秒杀，也不能拿一万个线程去怼一个根本不会热门的接口。要模拟真实用户行为：一部分用户在下单，一部分用户在支付，一部分用户在查询订单，比例要按线上监控里的数据来。
压测完不要只盯平均响应时间，要看TP99和错误率。订单接口的 TP99 如果超过一秒，用户就会明显感觉到卡顿，而 TP99 不达标很可能意味着某个下游系统存在长尾延迟。压测时至少把 TP50、TP95、TP99 三条线都打出来，然后逐个环节去优化。
3. 分布式事务：先分清一致性，再选方案
3.1 为什么本地事务撑不住跨库调用
下单不是只操作订单库一张表那么简单。订单服务要调库存服务扣库存，要调账户服务锁余额或创建支付单，这时本地事务已经无能为力。一个事务只能在一个数据库连接里生效，一旦你跨了服务、跨了数据源，@Transactional 管不了另外那个库。
很多人刚接触分布式事务时会觉得：既然本地事务不行，那就用分布式事务中间件强行保证全局一致性。但分布式事务是有代价的，它会把原本独立的服务强行拉到一个全局协调流程里，延迟增加、吞吐下降、排障困难。
所以选型之前必须想清楚一个问题：这个业务场景到底需要强一致还是最终一致。
支付扣款和订单状态之间的关联，通常可以接受最终一致。用户看到订单显示“已支付”，支付回调异步写入，中间差几秒完全没问题。但如果是账户扣款和余额增加，这种涉及资金变动的场景，就必须保证最终一致且不能出错，而且这个“最终”通常要求尽量短。
3.2 可靠消息最终一致性：主流方案
电商下单最实用、也最容易维护的分布式事务方案，其实是可靠消息最终一致性。核心思想很简单：订单服务和库存服务之间通过消息中间件解耦，订单服务先写业务数据，再发一条消息；库存服务消费这个消息去扣库存。
但“先写业务数据，再发消息”听起来简单，做起来全是坑。订单表的 order_no 已经 insert 了，消息发送失败怎么办？订单回滚了，消息却已经发出去了怎么办？所以可靠消息方案里最经典的落地方式是本地消息表。
具体步骤是：
- 在订单库建一张
message表，包含消息ID、关联业务ID、消息内容、状态字段； - 创建订单时，同一事务里同时写入订单记录和一条状态为
PENDING的消息记录； - 提交事务后，单独用一个发送组件从消息表取出
PENDING记录，发送到消息队列； - 发送成功后，把消息表里的状态改成
SENT； - 定时任务扫描长时间停留在
PENDING或状态变更异常的消息，重新发送。
这里有两个最容易忽略的细节。第一，消息表和订单表必须在同一个数据库里，这样才能保证“订单创建”和“消息落库”在同一个事务里要么都成功，要么都失败。如果消息表放在另一个库，那又变成了跨库分布式事务，问题没有解决。第二，消费者一定要做幂等，因为定时任务重发会造成消息重复投递，库存服务如果扣了两次库存，后果很严重。
幂等设计可以在消费端用消息ID做唯一约束，库存表的 deduct_record 里存 message_id，插入时遇到唯一键冲突就说明已经处理过，直接返回成功。
这个方案的优点是可读性强，每个环节都能查日志、查表、查消息，随便一个初中级开发者都能维护。缺点是需要额外维护一个消息表和定时任务，消息量很大时定时扫描会有压力，但这可以通过分批拉取、本地内存队列等方式缓解。
3.3 TCC与Saga：什么时候该上重方案
可靠消息能覆盖大部分场景，但有些业务必须在一个全局事务里看到中间状态，这时消息方案就不够用了。比如库存服务和订单服务之间如果希望“预留库存”和“创建订单”严格同步，就要考虑 TCC 或 Saga。
TCC 分为 Try、Confirm、Cancel 三个阶段。拿下单来说，Try 阶段把库存冻结、把订单预创建；Confirm 阶段把冻结资源转为实际扣减、把订单置为有效；Cancel 阶段把冻结资源释放、把订单作废。这个方案的优点是控制粒度细，适合资金和库存类场景，缺点是需要业务方为每个资源实现三套逻辑，开发量很大，而且 Try 和 Confirm 之间的状态维护很麻烦。
Saga 则是一种长事务模式，把一个大事务拆成一系列子事务，每个子事务有对应的补偿动作。比如“创建订单成功，扣库存失败”，就去执行创建订单的补偿动作——把订单取消。Saga 的优点是灵活性高，适合链路很长且不允许长时间锁资源的场景，缺点是补偿逻辑容易漏，而且没有自动隔离性，如果其他事务在中间步骤读取到未完成的数据，会读到不一致状态。
坦率地讲，多数电商订单场景根本没有必要上 TCC，用可靠消息最终一致性就足够。TCC 真正的用武之地是账户余额扣减、积分冻结、优惠券锁定这类敏感资源操作，而这些模块通常也不应该和订单模块强耦合。架构选型不是越复杂越好，而是越匹配越好。
4. 可落地的下单链路：状态流转、幂等设计与对账兜底
4.1 代码骨架：从Controller到Service再到事务边界
一个相对规范的订单创建接口，我习惯拆成三个层：入口校验层、业务编排层、资源操作层。
入口校验层只做参数格式和基础业务校验，比如商品是否存在、用户是否存在、数量是否超过限购。这些校验不要访问主库，可以先走缓存，缓存没有再看主库。业务编排层负责组装整个下单流程：先预扣库存，再计算价格和优惠，然后写入订单主表，最后发消息通知库存服务和支付服务。资源操作层负责和具体数据源交互，比如调用库存表的 update、写入订单表、写入本地消息表。
事务边界一定要控制在资源操作层内。很多人喜欢在 Service 方法上直接加 @Transactional，然后在这个事务里调用远程库存服务，这是绝对需要避免的。远程调用耗时不可控，这会让数据库事务长时间挂起，连接池耗尽不说，一旦远程调失败，本地事务回滚会让远程已经执行的扣减对不上账。
正确的做法是，本地事务只包裹“写订单表+写本地消息表”这两个动作，库存扣减在事务外做，消费消息异步做。整体流程可以用伪代码描述：
java复制@Transactional(rollbackFor = Exception.class)
public void createOrder(OrderCreateCommand cmd) {
// 校验幂等键，防止重复下单
checkIdempotent(cmd.getRequestId());
// 写入订单主表和订单明细
orderDao.insert(buildOrder(cmd));
orderDetailDao.insert(buildOrderDetails(cmd));
// 写入本地消息表，同一个事务
messageDao.insert(buildLocalMessage(cmd.getRequestId(), cmd));
}
库存预扣在调用 createOrder 之前完成，如果预扣失败直接返回；消息表里的记录由后台发送组件轮询发出，消费者拿到消息后做实际库存扣减。
4.2 本地消息表与定时任务怎么配合
本地消息表不是只建一张表就完了，发送逻辑和重试逻辑才是重点。
发送组件可以用一个后台线程池不断扫描 PENDING 状态的消息，扫描频率不要太高，1秒一次就够，否则会给数据库增加没必要的查询压力。每次扫描取固定条数，比如500条，然后逐条发送。发送成功更新状态为 SENT，发送失败不更新状态，下轮继续扫。
但只靠定时扫描有一个问题：内存里缓存了待发送消息，系统宕机后消息就丢了。所以要设计一个“二次确认”机制。发送组件从消息表取出消息后，先把状态改成 SENDING，发送成功再改成 SENT。如果系统在 SENDING 状态下重启，定时任务可以扫描到长时间停留在 SENDING 的记录，重新发一次。消费者收到重复消息后，因为消息ID唯一约束的存在，天然做了幂等。
对账兜底也要跟上。每隔一段时间，比如五分钟，对比本地消息表里 SENT 状态的消息和消费者那边的处理记录，发现漏处理的消息就重新投递。这一步看似冗余，但分布式环境下靠定时任务和日志恢复数据是常态，没有对账兜底的方案本质上都是赌运气。
4.3 状态机与回滚：怎么把异常订单拉回正轨
下单完成后，订单状态不会固定在“已创建”。支付成功、支付超时、库存扣减失败、用户取消，这些动作都会触发状态流转。为了让状态不乱跳，我会在每个状态节点记录“到达时间”和“操作人”，并在状态变更时写 order_status_log 表。这张日志表看起来占空间，但在排查线上问题时，它可以非常清楚地还原订单从创建到完成的全过程。
状态回滚是我特别想强调的点。分布式事务里，订单主表、库存、支付三个模块各自有各自的事务，不可能做到真正的原子回滚。那么订单中心能做的就是：发现异常状态后，执行“补偿动作”。比如订单创建成功但预扣库存失败，订单状态会被补偿为 CANCELLED，同时发一条恢复库存的消息；支付回调成功但订单状态停留在 CREATED，补偿动作就是先把订单改为 PAID，再触发发货。
补偿动作必须有独立的重试机制，不能用主流程里的异常捕获去处理，否则主流程重试一次就重复执行一次补偿。我会把补偿动作做成消息驱动的：订单写一个 RETRY_COMPENSATION 状态，由后台任务扫描这个状态，然后根据不同的失败原因执行不同的补偿逻辑。
5. 我踩过的坑：库存、重复支付、消息与死锁
5.1 库存超卖排查实录
我参与的一个模拟项目曾出现过一次经典超卖事故。当时库存扣减用的 Redis 预扣，数据库扣减在订单事务里，但 Redis 预扣成功后数据库扣减失败，异常被主流程吞掉，只回滚了订单，没恢复 Redis 库存。结果数据库库存还挺多，Redis 库存已经变成负数了，后续请求全部无法下单。
排查时才发现问题的根源不是代码写错，而是没有定义清楚“预占库存”和“实际扣减”的边界。后来我们加了一个库存流水表，每次扣减都产生一条流水记录，流水状态分为 RESERVED、DEDUCTED、RECOVERED，定时任务扫描长时间停留在 RESERVED 的流水，对比订单状态后决定继续扣减还是恢复库存。
注意：库存扣减的自检逻辑要尽早做。不要把“Redis库存、数据库库存、流水记录”三个数据完全独立维护，它们之间要有对账任务，哪怕每天跑一次，也能尽早发现数据漂移，避免大促时临时救火。
5.2 重复支付和订单状态乱跳
用户先点了一次支付，支付回调超时，用户又点了一次支付，这两笔支付都成功了，但订单只支付一次金额，多余的款项就挂在账上。这是重复支付最常见的场景。
解决重复支付，首先对支付请求做幂等，同一个订单号只允许生成一个支付单；其次，支付回调处理也要幂等，订单表里加一个 pay_status 字段，回调时先查状态，如果已经是 PAID 就把重复回调当作成功处理，不再修改订单金额。
另一个困扰我的问题是订单状态乱跳。有一次线上出现“已取消”订单变成了“已发货”，排查原因是状态更新 SQL 直接用了 update order set status = ? where order_id = ?，没有在 where 条件里带上当前状态。本来应该是 where order_id = ? and status = 'PAID'，这样并发场景下只有一个更新能成功，另一个会更新 0 行，触发重复操作保护。
所以从那次之后，订单状态更新 SQL 一律带上旧状态条件，如果更新行数为 0，说明有人抢先改了订单状态，执行后续排查而不是直接覆盖。
5.3 消息丢失、重复投递与空补偿
消息方案看起来简单，实际跑起来还会遇到两类问题：消息丢失和重复投递。消息丢失往往发生在发送消息的中间件宕机、消息队列未持久化、消费者手动确认异常这些环节。重复投递则是因为消费端处理时业务操作成功了，但还没来得及提交确认，服务就重启了，消息会被再次投递。
这两类问题我都是用同一套策略解决的：消费端必须做到“收到消息先查幂等表，处理过就返回成功，没处理过才执行业务逻辑”。幂等表最好用消息ID做唯一键，再加一个业务主键，比如 order_no，双重保障。
空补偿是另一个隐蔽问题。举个例子，TCC 的 Try 阶段执行成功，但全局事务还没进入 Confirm，协调者就挂了。恢复时系统认为事务需要 Cancel，于是执行 Cancel 操作。但这时候 Try 阶段已经恢复成功了，Cancel 再去释放冻结资源就会报错，或者反过来，Try 阶段根本没执行成功，补偿却执行了。TCC 的空补偿本质上是幂等和状态管理没做好，解决方案是在资源操作接口里记录事务日志，每次 Try、Confirm、Cancel 都先检查事务日志标识，避免重复操作。
6. 订单中心的后续演进与团队落地建议
6.1 从集中式到分库分表，订单主键怎么设计
日订单量上到千万级之后，单库单表基本撑不住。订单表必须分库分表，而且分片键的选择会直接影响查询效率。
订单查询最常见的条件就是“查某个用户的订单列表”，所以分片键用 user_id 是合理选择。但有一个坑：如果分片键是 user_id，你就没法直接通过 order_id 查订单，因为 order_id 没有分片信息。解决方案是在 order_id 里嵌入用户ID的分片编号，比如前几位表示用户ID对应的分片号。
除了分片键，订单表的归档也很重要。超过一定时间范围的订单基本不会再被修改，可以按月份归档到独立的归档库，减少热表数据量。归档时要把订单主表、订单明细表、操作日志表一起归档，不能只归档主表。
6.2 团队落地建议与个人体会
订单中心是高并发和分布式事务最集中的战场，不管方案设计得多严密，线上总会遇到新问题。我给团队的建议只有几条：把状态机画清楚再动手写代码；把本地消息表和定时任务当成标配，而不是临时插件；把订单状态操作日志完整保留，方便事故复盘；每次上线前至少做一次完整链路压测，不要只压单接口。
我个人在实践中最深的体会是：高并发下单和分布式事务都不是靠中间件或框架解决的，而是靠清晰的业务边界、合理的状态设计、齐备的日志和对账兜底解决的。不要迷信某款分布式事务中间件，不要盲目把事务范围铺得过大，更不要在没摸清业务一致性需求前就引入复杂方案。把每一环的数据都落到表里，把每一次失败都设计好补偿路径，这个系统才能在大促流量下站得住。