2. 订单生命周期：从下单到成交的完整流程、订单状态机、订单状态转换图

好，咱们今天聊聊订单的生命周期。说白了，就是一条订单从进入系统到最终被处理完，到底经历了什么。

我在纳斯达克做系统优化的时候，经常跟团队说一句话：“订单生命周期，就是撮合引擎的命脉”。你想想看，如果连订单怎么流转、状态怎么变都搞不清楚，那优化延迟、保证公平性就无从谈起。

2.1 订单的“一生”：从诞生到消亡

一条订单进入撮合引擎，大致会经历这么几个阶段：

1. 接收（Receive）：网络数据包到达，解析成内部订单结构。
2. 校验（Validate）：检查订单合法性（价格、数量、账户余额等）。
3. 路由（Route）：决定订单去哪个撮合队列。
4. 撮合（Match）：与对手方订单进行匹配。
5. 执行（Execute）：生成成交记录，更新订单状态。
6. 确认（Confirm）：向客户端发送确认消息。

嗯，这里要注意：不是所有订单都能走到撮合这一步。比如校验失败，订单直接就被拒了，生命周期到此结束。

2.2 订单状态机：状态的“交通规则”

订单状态机，说白了就是定义订单在什么情况下能变成什么状态。没有这个规则，系统就乱套了。

我在项目中遇到过一个问题：某个订单明明已经部分成交了，结果因为状态机设计有漏洞，又被重复撮合了一次。嗯，那次的后果很严重，直接导致了几百万美元的错单。

2.2.1 核心状态定义

状态	含义	说明
NEW	新订单	刚进入系统，尚未处理
ACCEPTED	已接受	校验通过，进入撮合队列
PARTIALLY_FILLED	部分成交	订单还有剩余数量未成交
FILLED	完全成交	订单全部数量已成交
CANCELLED	已撤销	用户主动取消
REJECTED	已拒绝	校验失败，或被系统强制拒绝
EXPIRED	已过期	订单超过有效时间

2.2.2 状态转换规则

状态转换不是随意的。我总结了几条核心规则：

• NEW → ACCEPTED：校验通过，这是最常见的路径。
• NEW → REJECTED：校验失败，直接拒绝。
• ACCEPTED → PARTIALLY_FILLED：撮合了一部分，但没完全成交。
• ACCEPTED → FILLED：一次撮合就全部成交了。
• PARTIALLY_FILLED → PARTIALLY_FILLED：多次撮合，每次成交一部分。
• PARTIALLY_FILLED → FILLED：最后一次撮合，剩余数量全部成交。
• ACCEPTED → CANCELLED：用户取消，但还没成交过。
• PARTIALLY_FILLED → CANCELLED：用户取消剩余部分。
• ACCEPTED → EXPIRED：订单超时。
• PARTIALLY_FILLED → EXPIRED：部分成交后超时。

2.3 订单状态转换图

下面这张图，是我用 SVG 画的订单状态转换图。你仔细看看，每个箭头都代表一次合法的状态变化。

2.4 订单生命周期的关键细节

有几个细节，我觉得值得单独拿出来说说：

2.4.1 订单的“不可逆”原则

一旦订单状态从 ACCEPTED 变成 PARTIALLY_FILLED，就永远不能回到 ACCEPTED。为什么？因为成交记录已经生成了，资金已经划转了。如果允许回退，那整个系统的账目就乱了。

我曾经见过一个系统，因为状态机设计不当，导致订单在 PARTIALLY_FILLED 和 ACCEPTED 之间来回跳转。结果呢？同一个订单被撮合了三次，每次都是不同的对手方。嗯，那次的复盘会开了整整两天。

2.4.2 订单的“原子性”操作

订单状态变更必须是原子性的。什么意思？就是状态变更和成交记录的生成，必须在一个事务里完成。不能出现“状态变了但成交记录没生成”或者“成交记录生成了但状态没变”的情况。

在低延迟系统中，我们通常使用无锁队列和 CAS（Compare-And-Swap）操作来实现这种原子性。代码示例：

// 伪代码：原子性订单状态变更
bool atomicUpdateOrderState(Order* order, OrderState newState) {
    // 使用 CAS 确保状态变更的原子性
    OrderState oldState = order->state.load();
    if (isValidTransition(oldState, newState)) {
        return order->state.compare_exchange_strong(oldState, newState);
    }
    return false;
}

2.4.3 订单的“超时”处理

订单超时是个容易被忽略的点。很多系统只处理了主动取消，却忘了处理超时。结果呢？大量“僵尸订单”堆积在队列里，占用了内存和 CPU 资源。

我建议的做法是：每个订单都带一个过期时间戳。撮合引擎在每次处理订单前，先检查时间戳。如果过期了，直接标记为 EXPIRED 状态，不再参与撮合。