代购订单状态机：从赔付近两千到零事故的架构演进
# 代购订单状态机：从赔付近两千到零事故的架构演进
本文适合日均订单超过50单、正在被物流状态不同步折磨的代购团队阅读。如果你只关注业务逻辑，可以跳过代码部分，但建议读完问题背景——这个坑几乎所有代购系统都会踩。
问题背景：双11的惨痛教训
双11期间，我的团队因为订单状态错乱发错三单，赔付近两千元。问题根源很简单：**订单状态没有因果关系**。客户下单后，系统把“已支付”和“已发货”之间的所有状态都当作独立标签，结果物流API回调延迟时，仓库看到“已支付”就直接发货，而实际订单还在采购环节。
代购系统的订单状态机，最核心的问题不是状态定义，而是**状态转换的边界条件**。比如“已支付→已采购”这个转换，如果采购失败，状态应该回滚到“已支付”还是进入“采购异常”？被动等待物流API回调时，代购承担全部丢件风险——这个风险在日均订单超过100单时，几乎每周都会遇到。
状态机设计：从枚举到有限状态自动机
传统方案是用一个状态字段存枚举值，代码里写if-else判断。这在订单量小时没问题，但一旦涉及采购、仓储、物流三个环节的异步回调，状态就会乱。
我们最终采用了**有限状态自动机（FSA）** 模型，核心是三个要素：当前状态、允许的转换、转换时的副作用。
```php
class OrderStateMachine
{
private static array $transitions = [
'pending' => ['paid', 'cancelled'],
'paid' => ['purchasing', 'refunding'],
'purchasing' => ['purchased', 'purchase_failed'],
'purchased' => ['warehousing', 'returning'],
'warehousing' => ['warehoused', 'damaged'],
'warehoused' => ['shipping', 'pending_return'],
'shipping' => ['shipped', 'lost'],
'shipped' => ['delivered', 'returning'],
];
private static array $sideEffects = [
'paid' => ['createPurchaseOrder', 'deductInventory'],
'purchased' => ['notifyWarehouse', 'updateCost'],
'shipped' => ['sendTrackingEmail', 'updateFreight'],
];
public static function transition(Order $order, string $targetState): bool
{
$currentState = $order->getState();
if (!isset(self::$transitions[$currentState])) {
throw new InvalidStateException("Unknown state: {$currentState}");
}
if (!in_array($targetState, self::$transitions[$currentState])) {
throw new InvalidTransitionException(
"Cannot transition from {$currentState} to {$targetState}"
);
}
// 执行副作用
if (isset(self::$sideEffects[$targetState])) {
foreach (self::$sideEffects[$targetState] as $effect) {
if (!method_exists($order, $effect)) {
throw new SideEffectException("Missing handler: {$effect}");
}
$order->$effect();
}
}
$order->setState($targetState);
$order->setStateChangedAt(time());
return true;
}
}
```
这个设计解决了两个核心问题：**非法转换被拦截**（比如“pending”不能直接到“shipped”），**副作用可追溯**（每个状态转换都有对应的业务操作）。
幂等性陷阱：回滚场景的边界问题
状态机设计中最容易被忽视的是**幂等性**。比如物流API回调“已签收”时，如果回调了两次，第二次调用应该直接返回成功，而不是再次执行副作用。
```php
class IdempotentTransition
{
private Redis $redis;
private int $lockTtl = 30; // 秒
public function execute(Order $order, string $targetState, string $idempotentKey): bool
{
// 检查是否已处理
$processed = $this->redis->get("transition:{$idempotentKey}");
if ($processed === 'done') {
return true; // 幂等返回
}
// 分布式锁，防止并发
$lockKey = "lock:order:{$order->getId()}";
$lock = $this->redis->setnx($lockKey, time() + $this->lockTtl);
if (!$lock) {
throw new ConcurrentException("Order is being processed");
}
try {
$result = OrderStateMachine::transition($order, $targetState);
// 标记已处理
$this->redis->set("transition:{$idempotentKey}", 'done', $this->lockTtl);
return $result;
} finally {
$this->redis->del($lockKey);
}
}
}
```
这个方案的trade-off是：**锁粒度影响并发**。如果订单量很大（比如日均1000+），30秒的锁可能导致其他操作排队。我们的优化是：只对“状态回滚”场景加锁，正常流转不加锁——因为正常流转的幂等性由业务键保证，不需要锁。
类似的幂等边界问题，在涉及汇率的场景同样存在。比如订单支付时汇率波动，如果支付回调重试，系统可能用不同汇率重新计算，导致金额不一致。这个问题的处理，我们下篇详细展开。
生产环境注意事项
状态机上线后，我们遇到了一个意想不到的问题：**状态码归一化**。不同物流商返回的状态码完全不一致——EMS的“已签收”是“SIGNED”，中通的“已签收”是“3”，圆通的“已签收”是“签收”。我们设计了一个统一映射表，配合**未知状态码告警机制**，及时发现映射表缺口。
```php
class LogisticsStatusMapper
{
private static array $mapping = [
'EMS' => ['SIGNED' => 'delivered', 'TRANSIT' => 'shipping'],
'中通' => ['3' => 'delivered', '2' => 'shipping'],
'圆通' => ['签收' => 'delivered', '运输中' => 'shipping'],
];
public static function map(string $carrier, string $rawStatus): string
{
if (!isset(self::$mapping[$carrier][$rawStatus])) {
// 告警：未知状态码
Alert::warning("Unknown status: {$carrier} -> {$rawStatus}");
return 'unknown';
}
return self::$mapping[$carrier][$rawStatus];
}
}
```
另一个优化是**状态停滞检测**。我们写了一个定时任务，只查状态停滞超过8小时且尚未超时的订单，避免扫全表。这个优化让数据库负载下降了约40%。
总结
状态机设计的核心不是状态定义，而是**状态转换的边界条件和幂等性**。双11赔付近两千的教训让我们明白：好的订单管理不是“多功能”，而是“关键时刻不掉链子”。这个方案在日均200单的场景下运行了半年，零事故。但要注意，如果订单量超过日均500单，锁粒度需要重新评估。
回到开头的场景，日均订单超过50单的团队，这个状态机设计能有效避免物流状态不同步导致的赔付问题。关于支付回调的幂等性处理，我们下篇详细展开——那是一个更复杂的场景，涉及汇率锁定、多次回调、退款冲正等问题。
---
搞了十年后端架构，做过韩国跨境商城（多平台商品搜索、中韩双语、韩币结算）和 betteryoyo 海外华人代购代运系统。欢迎交流探讨。