Producer 调用#

代码路径：duolaimall-order/order-service/src/main/java/com/cskaoyan/mall/order/controller/OrderController.java

1
baseProducer.sendDelayMessage(
2
        MqTopicConst.DELAY_ORDER_TOPIC,
3
        orderId,
4
        7);

通用 Producer 会：

代码路径：duolaimall-common/common-mq/src/main/java/com/cskaoyan/mall/mq/producer/BaseProducer.java

1
String jsonMessage = JSON.toJSONString(messageBody);
2
Message message = new Message(
3
        topicName,
4
        jsonMessage.getBytes(Charset.forName("utf-8")));
5

6
message.setDelayTimeLevel(delayLevel);
7
SendResult sendResult = mqProducer.send(message);
8

9
if (sendResult == null || sendResult.getSendStatus() == null) return false;
10

11
if (sendResult != null) {
12
    SendStatus sendStatus = sendResult.getSendStatus();
13
    if (sendStatus.equals(SendStatus.SEND_OK)) {
14
        log.info("延迟消息发送成功，topic:{}, message:{}", topicName, jsonMessage);
15
        return true;
16
    } else {
17
        return false;
18
    }
19
}

当前 Controller 没有检查 Boolean 返回值。消息发送失败时，订单仍会成功返回给客户端。

三套时间并不一致#

代码已确认：

• 订单 expireTime：当前时间加 1 分钟；
• 实际发送 delayLevel = 7：RocketMQ 内置级别约 3 分钟；
• 代码中另有“30 分钟”注释或常量设计痕迹，但当前调用未使用。

所以不能说“订单会在 expireTime 到达时自动准确关闭”。

Consumer 当前没有自动启动#

代码路径：duolaimall-order/order-service/src/main/java/com/cskaoyan/mall/order/mq/DelayOrderConsumer.java

1
@Component
2
public class DelayOrderConsumer {
3

4
    @Autowired
5
    OrderService orderService;
6

7
    // @PostConstruct
8
    public void init() throws MQClientException {
9
        DefaultMQPushConsumer consumer =
10
                new DefaultMQPushConsumer(
11
                        "delay-order-group");
12

13
        // 省略注册中心配置和订阅
14
        consumer.setMessageListener(
15
                new MessageListenerConcurrently() {
16
            @Override
17
            public ConsumeConcurrentlyStatus consumeMessage(
18
                    List<MessageExt> msgs,
19
                    ConsumeConcurrentlyContext context) {
20
                Long orderId = JSON.parseObject(
21
                        new String(msgs.get(0).getBody()),
22
                        Long.class);
23

24
                orderService.execExpiredOrder(orderId);
25
                return ConsumeConcurrentlyStatus
26
                        .CONSUME_SUCCESS;
27
            }
28
        });
29

30
        consumer.start();
31
    }
32
}

因为 @PostConstruct 已注释，Spring 创建组件时不会自动调用 init()。虽然监听代码和 start() 存在，当前进程不会自动注册这个消费者。

订单状态#

代码枚举还包含发货、评价和支付失败等状态，但本文链路没有展开它们。

库存任务状态#

DEDUCTED 在 lockStock 成功分支只表示增加了 stock_locked，并非实际出库扣减；多仓拆分代码还会在锁库前把子工作单暂置为该状态，因此判断最终结果必须结合调用阶段。

为什么不能只看本地 UNPAID#

支付发生在超时边界时可能出现：

1. 用户已经在支付宝支付成功；
2. 支付宝回调因网络延迟尚未到达；
3. 订单库仍是 UNPAID；
4. 延迟消费者此时执行。

若直接关单，就会出现“钱已付、订单却关闭”。当前 execExpiredOrder 因此会查询本地支付流水和支付宝状态。

当前静态流程#

1
OrderInfo orderInfo =
2
        orderInfoMapper.selectById(orderId);
3

4
if (!OrderStatus.UNPAID.name()
5
        .equals(orderInfo.getOrderStatus())) {
6
    return;
7
}
8

9
String outTradeNo =
10
        orderInfo.getOutTradeNo();
11

12
PaymentInfoDTO paymentInfo =
13
        payApiClient
14
                .getPaymentInfoDTOByOutTradeNo(
15
                        outTradeNo);
16

17
if (paymentInfo == null) {
18
    orderInfo.setOrderStatus(
19
            OrderStatus.CLOSED.name());
20
    orderInfoMapper.updateById(orderInfo);
21
    return;
22
}

如果有本地支付流水，再主动查询支付宝：

1
Result alipayInfo =
2
        payApiClient.getAlipayInfo(outTradeNo);
3

4
Map<String, String> result =
5
        (Map<String, String>) alipayInfo.getData();
6

7
String subCode = result.get("subCode");
8
String tradeStatus =
9
        result.get("tradeStatus");
10

11
if ("TRADE_SUCCESS".equals(tradeStatus)) {
12
    return;
13
}

其他状态会尝试关闭订单、关闭本地支付流水或关闭支付宝交易。

当前超时闭环仍未生效#

即使业务方法存在，也有以下代码事实：

1. 延迟 Consumer 的 @PostConstruct 被注释；
2. 订单过期时间与延迟级别不一致；
3. 发送结果没有检查；
4. 支付服务本地 updatePaymentStatus 为空；
5. WAIT_BUYER_PAY 分支判断 "null".equals(subCode)，真实空值是否匹配存在疑问；
6. 订单关闭和支付成功都没有条件状态迁移，存在竞态。

因此只能说“代码设计了延迟关单判断”，不能说“未支付订单会被可靠自动关闭”。

事务地图#

1
提交前 Feign 库存预查          不在订单事务
2
提交前 Feign 实时核价          不在订单事务
3
saveOrderInfo 主表 + 明细       普通订单入口：本地事务
4
删除购物车                     订单事务提交后
5
发送延迟消息                   订单事务提交后
6
支付服务更新支付流水           支付服务独立提交
7
订单状态改 PAID                订单服务独立提交
8
仓储任务与库存锁定             仓储本地事务意图，存在自调用代理风险
9
多仓子订单保存                 跨多次本地写，整体非原子

重复提交#

普通订单接口没有交易码或请求幂等键。客户端超时重试可能：

• 生成新的雪花 outTradeNo；
• 保存另一张内容相同的订单；
• 再次删除购物车；
• 再发送一条延迟消息。

重复支付通知#

订单 successPay 没有条件更新，仓储 saveWareOrderTask 的返回值又被忽略。若支付通知在“订单已处理但响应丢失”后重试，可能再次进入库存锁定。

库存并发#

正确的目标应是：

1
开始事务
2
  -> 按稳定顺序 SELECT ... FOR UPDATE
3
  -> 检查所有明细
4
  -> 更新所有 stock_locked
5
提交事务

当前 SQL 具备行锁和更新能力，但事务注解是否通过代理生效需要修正或运行证据。多个订单按不同 SKU 顺序加锁时，也可能产生数据库死锁并需要重试策略。

跨服务失败#

OpenFeign 只告诉当前调用“成功或失败”，不能让之前已提交的服务自动回滚。跨服务需要幂等、可靠事件、补偿或状态扫描，不能依赖一个 @Transactional 注解。

正常单仓订单#

1
POST /order/auth/submitOrder
2
Content-Type: application/json
3
userId: <Gateway 写入>
4

5
{
6
  "consignee": "<收货人>",
7
  "deliveryAddress": "<地址>",
8
  "orderDetailList": [
9
    {
10
      "skuId": 101,
11
      "skuName": "<商品>",
12
      "orderPrice": 99.00,
13
      "skuNum": 2
14
    }
15
  ]
16
}

推演：

1. 仓储总可用库存通过；
2. 商品实时价与请求价 equals；
3. 保存 UNPAID 主表和明细；
4. 删除购物车 SKU；
5. 发送延迟消息；
6. 支付成功后创建单仓工作单；
7. 指定仓库行锁检查通过；
8. stock_locked += 2；
9. 订单变成 WAIT_DELEVER。

价格变化#

库存预查可能已通过，但实时价不同：

• 通知购物车刷新价格；
• 不保存订单；
• 返回“价格发生变动”。

预查通过、支付后库存不足#

两个用户都在预查时看到库存充足。支付后最终行锁阶段，其中一个先锁定库存，另一个再计算可用库存不足：

• 库存任务变 OUT_OF_STOCK；
• 订单变 STOCK_EXCEPTION；
• 当前代码未展示退款或人工处理闭环。

订单保存成功、消息发送失败#

Controller 忽略 Producer 返回值，仍返回订单 ID。由于消费者本身也未自动启动，这张未支付订单不会因当前延迟链自动关闭。

空明细提交#

当前代码会遍历空集合，然后在构造 tradeBody 时访问第 0 条明细，可能抛异常。没有看到统一的空订单参数校验。

亮点#

1. 确认页由订单服务聚合地址与已选商品；
2. 提交前同时复核库存和实时价格；
3. 订单主表和明细在普通下单入口使用本地事务；
4. 库存预查和最终行锁检查分层；
5. 多仓 SKU 可以转换为父子订单和分仓工作单；
6. 最终库存 SQL 使用 stock - stock_locked；
7. 超时逻辑意识到支付回调延迟竞态，不是简单看到 UNPAID 就关单。

真实取舍#

• 同步 Feign 易理解，但下单依赖多个服务同时可用；
• 先落订单再删购物车避免误删，但会留下购物车残留；
• 支付后再锁库存降低未支付占用，但可能出现付款后库存异常；
• 行锁可以保护数据库行，但吞吐、锁顺序和事务代理必须正确；
• 延迟消息适合超时任务，但需要消费者、时长和补偿一起闭环。

下单入口#

• 由服务端按 SKU 重新构建商品快照；
• 校验数量范围、上下架状态和地址归属；
• 使用一次性交易码或客户端请求号建立唯一约束；
• 价格使用 compareTo；
• 对空明细和重复 SKU 做明确校验。

订单与购物车#

一种方案：

1
本地事务保存订单
2
  -> 同事务写 order_created_outbox
3
  -> 提交后可靠发布
4
  -> cart-service 幂等消费删除 SKU
5
  -> 延迟关单消息由 outbox 保证投递

库存处理#

• 把库存选择和锁定放入一个明确的仓储事务入口；
• 避免同类自调用，或通过独立 Bean 进入事务代理；
• 为 order_id / 工作单业务号建立唯一约束；
• 使用稳定 SKU 顺序加锁并对死锁重试；
• 订单取消释放 stock_locked；
• 发货时把锁定量转为实际扣减量；
• 库存异常要有退款或人工补偿链。

状态机#

订单状态更新使用条件：

1
-- 改进示例，不是当前 Mapper
2
UPDATE order_info
3
SET order_status = 'PAID'
4
WHERE id = ?
5
  AND order_status = 'UNPAID';

仓储任务也用“待处理 → 已锁定/库存不足”的条件迁移，重复请求读取已有结果，而不是再次执行库存写入。

超时关闭#

• 统一订单 expireTime、支付宝过期时间和消息延迟；
• 确保消费者随应用启动；
• 关单前查询支付平台；
• 修正空值判断；
• 支付成功与关单使用条件状态竞争；
• 建立延迟消息丢失扫描和库存释放补偿。