网约车业务里最容易出诡异 bug 的地方，往往不是高并发链路，而是订单状态。三马代驾早期的订单服务里，状态判断散落在十几个 service 中，"司机取消之后支付回调又把单改成已支付"这种问题每隔几周就冒出来一次。后来我们把状态流转收敛成一台显式的状态机，超时关闭交给延迟消息队列，线上再也没有出现过状态错乱的工单。

这篇讲清楚三件事：状态怎么定义、流转怎么卡死、超时怎么可靠关闭。代码来自三马代驾线上订单服务。

public enum OrderStatus {
    CREATED(0),   // 已创建
    ACCEPTED(1),  // 司机接单
    ARRIVED(2),   // 司机到达
    STARTED(3),   // 行程中
    FINISHED(4),  // 完单待支付
    PAID(5),      // 已支付
    CANCELED(6),  // 已取消
    CLOSED(7);    // 超时关闭
}

枚举一旦上线就不再随意增删，新增状态必须评审。三马代驾刻意控制状态数量：像"司机接单后乘客主动取消"这类细分场景，不单独造状态，而是在 CANCELED 上挂 cancelType 字段记录原因。

状态每多一个，流转关系就多乘一个维度

，能用字段表达的就不要用状态表达。

所有状态变更必须经过同一个入口，白名单写死在常量里：

private static final Map<OrderStatus, Set<OrderStatus>> ALLOW = Map.of(
    CREATED,  Set.of(ACCEPTED, CANCELED, CLOSED),
    ACCEPTED, Set.of(ARRIVED, STARTED, CANCELED),
    ARRIVED,  Set.of(STARTED, CANCELED),
    STARTED,  Set.of(FINISHED, CANCELED),
    FINISHED, Set.of(PAID),
    PAID,     Set.of(),
    CANCELED, Set.of(),
    CLOSED,   Set.of()
);

@Transactional(rollbackFor = Exception.class)
public void changeStatus(Long orderId, OrderStatus expect, OrderStatus target) {
    if (!ALLOW.get(expect).contains(target)) {
        throw new OrderStateException("非法流转 " + expect + "->" + target);
    }
    int rows = orderMapper.casUpdate(orderId, expect, target);
    if (rows == 0) {
        throw new OrderStateException("状态已被并发修改，order=" + orderId);
    }
    publisher.publish(new OrderStatusEvent(orderId, expect, target));
}

把乐观锁放进 where 条件，是这套设计最关键的一行

：超时关单和司机接单同时到达数据库时，只有一条能改成功，另一条 rows=0 直接失败，不可能出现"关了单又被人接走"。

事件发布放在事务提交之后（用 Spring 的 TransactionAfterCommit），下游的推送、计费、结算都只订阅事件，不允许任何人直接 update 订单状态。

三、超时关闭：延迟消息 + 幂等消费

下单成功立刻投一条延迟 60 秒的消息，到期由消费者执行关单：

// 下单时投递
rabbitTemplate.convertAndSend("exchange.delay", "order.close",
        String.valueOf(orderId),
        m -> { m.getMessageProperties().setDelayLong(60_000); return m; });

@RabbitListener(queues = "queue.order.close")
public void onCloseOrder(String orderIdStr) {
    Long orderId = Long.valueOf(orderIdStr);
    OrderStatus now = orderMapper.getStatus(orderId);
    if (now != CREATED) {
        return; // 已接单/已取消，直接丢弃
    }
    try {
        orderService.changeStatus(orderId, CREATED, CLOSED);
        dispatchService.recallDispatch(orderId);
    } catch (OrderStateException e) {
        log.info("关单时状态已变化，忽略 orderId={}", orderId);
    }
}

我们评估过 Redis keyspace 通知做超时，放弃了：通知不保证送达，丢了就是永久卡单。轮询扫描也试过，高峰期对订单表的压力肉眼可见。

延迟消息在精度和运维成本之间是最平衡的解

四、取消不是终点，是一串动作

状态只是骨架，取消后的退券、退预约费、信用分扣减挂在事件监听里按 cancelType 分派：

@OrderEventListener(status = CANCELED)
public void onCancel(OrderStatusEvent e) {
    CancelRecord r = cancelRecordMapper.getByOrder(e.getOrderId());
    if (PASSENGER_CANCEL == r.getType()) {
        couponService.returnCoupon(e.getOrderId());
        refundService.refundFee(e.getOrderId());
    } else if (DRIVER_CANCEL == r.getType()) {
        driverScoreService.deduct(r.getDriverId(), 5);
        dispatchService.priorityRecall(e.getOrderId());
    }
}

集中在一个监听器里，改规则只改一处，排查也只需看一条事件链路。

状态少一点、流转写成白名单、更新一律 CAS、超时交给延迟消息并允许它失败

。状态机保证不产生脏流转，延迟队列保证该关的单一定会被关，两者各司其职，订单系统才能在无人值守的夜里安稳跑下去。

三马代驾实战：订单状态机 + 延迟队列，把超时关单做可靠

后端

架构设计

网约车订单状态机设计：收敛为8个状态枚举，通过流转白名单+SQL层CAS乐观锁防止并发状态错乱，超时关闭采用延迟消息队列并保证幂等消费。取消动作通过事件监听分派处理，监控存量、接单耗时、超时关闭率三个核心指标，实现订单状态零错乱。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

三马代驾实战：订单状态机 + 延迟队列，把超时关单做可靠

三马代驾实战：订单状态机 + 延迟队列，把超时关单做可靠

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐