高并发下单如何做到不超卖、不丢单？Spring Boot 4 + Redis + RabbitMQ + Vue 3 订单异步处理与库存削峰实战含 Lua 原子库存预扣、Outbox 可靠消息、幂

摘要

秒杀、限量抢购和大促下单真正难的不是“把请求接住”，而是同时保证库存不被扣成负数、重复请求不生成重复订单、消息故障不丢单、取消或超时后库存能够准确归还。本文从一个 Java + Vue 的订单项目出发，给出一条可以落地的异步下单链路：请求入口只做必要校验和 Redis 原子预扣，订单与 Outbox 在同一个 MySQL 本地事务中提交，消息由独立 Publisher 可靠投递到 RabbitMQ，消费者通过数据库唯一约束与消费记录保证幂等，失败消息进入有限重试与死信链路，最终由补偿任务收口。全文同时给出数据模型、核心代码、状态机、异常场景和验证方法。

技术组件

本文基线

说明

JDK

25 LTS（21 LTS 也可）

JDK 25 是当前 LTS；Spring Boot 4.1 可运行在 Java 17～26

Spring Boot

4.1.x

当前稳定主线；如果项目仍在 3.5.x，本文设计思路不变

Redis

8.6

用于热点库存、请求幂等和短期状态；关键库存操作使用 Lua 原子脚本

RabbitMQ

4.3.x

使用 Publisher Confirm、手动 ACK、有限重试与 DLQ；生产可考虑 Quorum Queue

MySQL

8.4 LTS

保存订单、库存、流水、消费记录和 Outbox，作为持久业务事实来源

Vue

3.5+

下单后展示 PROCESSING，并通过轮询、SSE 或 WebSocket 更新状态

先说结论

高并发订单系统的关键不是“Redis + MQ”这两个名词，而是把每一个失败窗口都设计清楚：Redis 已扣但数据库失败怎么办？数据库成功但消息没发出去怎么办？消息重复投递怎么办？消费者事务回滚但消息已经 ACK 怎么办？订单超时释放库存被重复执行怎么办？只要这些问题没有闭环，系统在正常演示时可能完全没问题，一到网络抖动、进程重启或流量洪峰就会暴露数据不一致。

削峰的本质

消息队列并不会凭空提高数据库的极限吞吐量。它真正做的是把“瞬间必须处理完的 5000 个请求”改造成“入口先快速确认、后端按可承受速度持续处理的 5000 个任务”。系统因此从不可控的并发争抢，变成可观测、可限速、可扩容的队列积压。

业务不变量

系统必须保证

主要手段

库存不超卖

任何时刻都不能因为并发把可售库存扣成负数

Redis Lua 原子预扣 + MySQL 条件更新

请求幂等

同一个 requestId 重试多次只能得到一个业务结果

request_id 唯一索引 + Redis 请求标记

消息不静默丢失

订单事务成功后，消息最终应可被重新投递

Outbox + Publisher Confirm + RETRY 状态

消费可重复

消息重复到达不会重复创建订单或重复扣库存

event_id / order_no 唯一约束 + consume_log

补偿只执行一次

取消、超时、死信等路径重复触发也不能多加库存

stock_flow 业务唯一键 + 条件更新

状态不可逆乱跳

已支付订单不能被超时任务改成已取消

状态机 + WHERE status = ? 条件更新

为什么不是“先发 MQ，再写订单”？

因为“消息发送”和“MySQL 事务提交”属于两个独立系统。没有分布式事务时，两者之间永远存在失败窗口。Outbox 的做法是先在同一个数据库事务里保存业务数据和“待发送事件”，再由后台可靠投递。即使应用在事务提交后立即崩溃，Outbox 记录仍然存在，重启后可以继续发送。

表

关键字段

关键约束 / 作用

order_info

order_no, request_id, user_id, product_id, quantity, status

order_no、request_id 唯一；保存 PROCESSING / WAITING_PAY / PAID 等状态

stock

product_id, available, locked, version

product_id 唯一；available >= 0；条件更新避免负库存

stock_flow

flow_no, biz_type, biz_no, product_id, quantity

(biz_type,biz_no) 唯一；扣减、确认、释放都有可追踪业务流水

mq_outbox

event_id, aggregate_id, payload, status, retry_count, next_retry_at

event_id 唯一；NEW / SENDING / SENT / RETRY / DEAD

mq_consume_log

event_id, consumer_name, consumed_at

(event_id,consumer_name) 唯一；消费者幂等

order_item

order_no, product_id, quantity, price_snapshot

保存下单时的商品快照，避免后续商品改价影响历史订单

CREATE TABLE order_info (
    id            BIGINT PRIMARY KEY AUTO_INCREMENT,
    order_no      VARCHAR(40)  NOT NULL,
    request_id    VARCHAR(64)  NOT NULL,
    user_id       BIGINT       NOT NULL,
    product_id    BIGINT       NOT NULL,
    quantity      INT          NOT NULL,
    status        VARCHAR(20)  NOT NULL,
    created_at    DATETIME(3)  NOT NULL,
    updated_at    DATETIME(3)  NOT NULL,
    UNIQUE KEY uk_order_no(order_no),
    UNIQUE KEY uk_request_id(request_id),
    KEY idx_user_created(user_id, created_at),
    KEY idx_status_created(status, created_at)
);

CREATE TABLE mq_outbox (
    id             BIGINT PRIMARY KEY AUTO_INCREMENT,
    event_id       VARCHAR(64) NOT NULL,
    aggregate_id   VARCHAR(40) NOT NULL,
    event_type     VARCHAR(50) NOT NULL,
    payload        JSON        NOT NULL,
    status         VARCHAR(16) NOT NULL,
    retry_count    INT         NOT NULL DEFAULT 0,
    next_retry_at  DATETIME(3) NULL,
    created_at     DATETIME(3) NOT NULL,
    updated_at     DATETIME(3) NOT NULL,
    UNIQUE KEY uk_event_id(event_id),
    KEY idx_outbox_retry(status, next_retry_at)
);

public record CreateOrderRequest(
        @NotNull Long productId,
        @NotNull @Min(1) Integer quantity,
        @NotBlank String requestId
) {}

public record CreateOrderResponse(
        String orderNo,
        String requestId,
        String status
) {}

@PostMapping("/api/orders")
public ResponseEntity<CreateOrderResponse> create(
        @AuthenticationPrincipal LoginUser user,
        @Valid @RequestBody CreateOrderRequest request) {

    CreateOrderResponse response = orderApplicationService.create(user.id(), request);
    return ResponseEntity.accepted().body(response);
}

— KEYS[1] = stock:{productId}:available
— KEYS[2] = stock:{productId}:req:{requestId}
— ARGV[1] = quantity
— ARGV[2] = orderNo
— ARGV[3] = ttlSeconds

local qty = tonumber(ARGV[1])
if not qty or qty <= 0 then
    return -1
end

if redis.call('EXISTS', KEYS[2]) == 1 then
    return 2
end

local stock = tonumber(redis.call('GET', KEYS[1]) or '-1')
if stock < qty then
    return 0
end

redis.call('DECRBY', KEYS[1], qty)
redis.call('SET', KEYS[2], ARGV[2], 'EX', tonumber(ARGV[3]))
return 1

@Service
@RequiredArgsConstructor
public class RedisStockService {
    private final StringRedisTemplate redisTemplate;
    private final DefaultRedisScript<Long> reserveScript;

    public ReserveResult reserve(Long productId, int quantity,
                                 String requestId, String orderNo) {
        String tag = "{" + productId + "}";
        String stockKey = "stock:" + tag + ":available";
        String reqKey = "stock:" + tag + ":req:" + requestId;

        Long result = redisTemplate.execute(
                reserveScript,
                List.of(stockKey, reqKey),
                String.valueOf(quantity), orderNo, "1800");

        return ReserveResult.from(result);
    }
}

Redis Cluster 注意点

Lua 脚本同时操作多个 key 时，Redis Cluster 要求相关 key 位于同一 hash slot。示例通过 {productId} hash tag 让同一商品的库存键和请求键落到同一个 slot。这个细节在单机 Redis 上看不出问题，迁移到 Cluster 后却很关键。

@Service
@RequiredArgsConstructor
public class OrderApplicationService {
    private final RedisStockService redisStockService;
    private final OrderTxService orderTxService;
    private final StockCompensationService compensationService;

    public CreateOrderResponse create(Long userId, CreateOrderRequest req) {
        OrderInfo old = orderTxService.findByRequestId(req.requestId());
        if (old != null) {
            return new CreateOrderResponse(old.getOrderNo(), req.requestId(), old.getStatus());
        }

        String orderNo = OrderNoGenerator.next(userId);
        ReserveResult reserve = redisStockService.reserve(
                req.productId(), req.quantity(), req.requestId(), orderNo);

        if (reserve == ReserveResult.OUT_OF_STOCK) {
            throw new BusinessException("STOCK_NOT_ENOUGH");
        }
        if (reserve == ReserveResult.DUPLICATE) {
            OrderInfo duplicated = orderTxService.requireByRequestId(req.requestId());
            return new CreateOrderResponse(duplicated.getOrderNo(), req.requestId(), duplicated.getStatus());
        }

        try {
            orderTxService.createProcessingOrderAndOutbox(userId, req, orderNo);
        } catch (RuntimeException ex) {
            compensationService.releaseReservationOnce(orderNo, req.productId(), req.quantity());
            throw ex;
        }

        return new CreateOrderResponse(orderNo, req.requestId(), "PROCESSING");
    }
}

@Service
@RequiredArgsConstructor
public class OrderTxService {
    private final OrderMapper orderMapper;
    private final OutboxMapper outboxMapper;

    @Transactional
    public void createProcessingOrderAndOutbox(
            Long userId, CreateOrderRequest req, String orderNo) {

        orderMapper.insertProcessing(orderNo, req.requestId(), userId,
                req.productId(), req.quantity());

        OrderCreatedEvent event = OrderCreatedEvent.of(orderNo, req);
        outboxMapper.insertNew(event.eventId(), orderNo,
                "ORDER_CREATED", Jsons.write(event));
    }
}

Outbox 不是“绝对只发送一次”

Publisher 可能在 RabbitMQ 已确认消息后、还没来得及把 Outbox 更新成 SENT 时崩溃。重启后同一事件可能再次发送。因此正确目标是“至少一次投递 + 消费端幂等”，而不是依赖一个不存在的端到端 exactly-once 幻想。

@Scheduled(fixedDelay = 500)
public void publishPending() {
    List<OutboxEvent> events = outboxMapper.lockNextBatch(100);
    for (OutboxEvent event : events) {
        try {
            CorrelationData cd = new CorrelationData(event.getEventId());
            rabbitTemplate.convertAndSend(
                    "order.exchange", "order.created", event.getPayload(), cd);
            // ConfirmCallback 中根据 eventId 更新 SENT / RETRY
        } catch (Exception ex) {
            outboxMapper.markRetry(event.getEventId(), retryAt(event));
        }
    }
}

@Component
@RequiredArgsConstructor
public class OrderConsumer {
    private final OrderMessageTxService txService;

    @RabbitListener(queues = "order.create.queue", ackMode = "MANUAL")
    public void consume(OrderCreatedEvent event,
                        Channel channel, Message message) throws IOException {
        long tag = message.getMessageProperties().getDeliveryTag();
        try {
            txService.process(event);   // 返回时数据库事务已经提交
            channel.basicAck(tag, false);
        } catch (RetryableBusinessException ex) {
            channel.basicNack(tag, false, false); // 交给重试/DLX，不要无限原队列 requeue
        } catch (Exception ex) {
            channel.basicNack(tag, false, false);
        }
    }
}

@Service
@RequiredArgsConstructor
public class OrderMessageTxService {
    private final ConsumeLogMapper consumeLogMapper;
    private final OrderMapper orderMapper;
    private final StockMapper stockMapper;
    private final StockFlowMapper stockFlowMapper;

    @Transactional
    public void process(OrderCreatedEvent event) {
        // 唯一键 (event_id, consumer_name) 是最终幂等屏障
        if (!consumeLogMapper.tryInsert(event.eventId(), "order-create-consumer")) {
            return;
        }

        OrderInfo order = orderMapper.lockByOrderNo(event.orderNo());
        if (order == null || !"PROCESSING".equals(order.getStatus())) {
            return;
        }

        int changed = stockMapper.lockStock(
                event.productId(), event.quantity());
        if (changed != 1) {
            throw new BusinessException("DB_STOCK_NOT_ENOUGH");
        }

        stockFlowMapper.insertOnce(
                "LOCK", event.orderNo(), event.productId(), event.quantity());
        orderMapper.markWaitingPay(event.orderNo());
    }
}

UPDATE stock
SET available = available – #{quantity},
    locked    = locked + #{quantity},
    version   = version + 1,
    updated_at = NOW(3)
WHERE product_id = #{productId}
  AND available >= #{quantity};

为什么还要数据库条件扣减？

Redis 是高并发入口的第一道库存闸门，但数据库仍应保留 available >= quantity 的条件更新。它既能防止缓存异常、人工修复或数据漂移把数据库扣成负数，也让持久层自己具备最基本的业务约束。

动作

Redis

MySQL

幂等依据

预扣 RESERVE

DECRBY available

暂不改或只记订单 PROCESSING

requestId / orderNo

锁定 LOCK

保持预扣结果

available -= qty; locked += qty

eventId + stock_flow

支付确认 CONFIRM

通常不再改可售库存

locked -= qty，进入已售语义

paymentNo / orderNo

取消释放 RELEASE

INCRBY available

available += qty; locked -= qty

(RELEASE, orderNo) 唯一

人工校正 ADJUST

按修复结果同步

写调整流水后修改

repairNo

UPDATE order_info
SET status = 'CANCELLED', updated_at = NOW(3)
WHERE order_no = #{orderNo}
  AND status = 'WAITING_PAY';

@Transactional
public void closeAndRelease(String orderNo) {
    OrderInfo order = orderMapper.findByOrderNo(orderNo);
    if (order == null) return;

    int closed = orderMapper.closeIfWaiting(orderNo);
    if (closed != 1) return; // 已支付、已取消或被其他任务处理

    // 数据库唯一键确保同一订单 RELEASE 只插入一次
    boolean first = stockFlowMapper.tryInsertRelease(
            orderNo, order.getProductId(), order.getQuantity());
    if (!first) return;

    stockMapper.releaseLocked(order.getProductId(), order.getQuantity());
    redisStockService.release(order.getProductId(), order.getQuantity(), orderNo);
}

const submitting = ref(false)
const order = ref(null)

async function submitOrder(productId, quantity) {
  if (submitting.value) return
  submitting.value = true

  const requestId = crypto.randomUUID()
  try {
    const { data } = await api.post('/api/orders', {
      productId,
      quantity,
      requestId
    })

    order.value = data
    await pollStatus(data.orderNo)
  } finally {
    submitting.value = false
  }
}

async function pollStatus(orderNo) {
  for (let i = 0; i < 30; i++) {
    const { data } = await api.get(`/api/orders/${orderNo}`)
    order.value = data

    if (['WAITING_PAY', 'PAID', 'CANCELLED', 'FAILED'].includes(data.status)) {
      return
    }
    await new Promise(resolve => setTimeout(resolve, Math.min(500 + i * 150, 2000)))
  }
}

重试时不要换 requestId

网络超时并不代表后端一定没收到请求。前端如果每次超时都生成新的 requestId 再提交，就可能把一次用户操作变成多次合法订单请求。正确做法是把 requestId 与这次“业务意图”绑定，在用户明确发起一笔新订单之前都复用它。

异常场景

可能后果

处理方式

Redis 预扣成功，MySQL 事务失败

缓存少库存、数据库无订单

即时幂等释放 + 预扣超时对账兜底

MySQL 已提交，应用发送 MQ 前崩溃

订单停在 PROCESSING

Outbox NEW 记录重启后继续投递

MQ 已 Confirm，Outbox 未标 SENT 就崩溃

同一事件可能再次发送

消费者 eventId 幂等，重复消息安全返回

消费者业务成功但 ACK 丢失

消息重新投递

consume_log / 业务唯一键挡住重复处理

消费者 ACK 成功但 DB 提交失败

消息永久丢失

禁止 ACK 早于事务提交；事务 Service 返回后再 ACK

消费者异常无限 requeue

热点消息持续打满消费者

有限重试 + DLQ + 告警，区分可重试/不可重试异常

支付回调与超时任务并发

已支付订单被取消

状态条件更新，WAITING_PAY 只能被一个动作成功迁移

库存释放任务重复执行

库存被多加

数据库 stock_flow 唯一键 + 条件更新

Redis 与 MySQL 库存长期漂移

可售量与持久库存不一致

定时对账：订单/库存流水汇总与缓存比对，生成修复任务

测试

操作

必须满足的断言

并发抢库存

初始库存 100，同时提交 1000 个不同 requestId

成功锁定数量 <= 100；Redis 与 DB 均不出现负库存

同请求重复提交

同一 requestId 并发提交 20～50 次

最终只有一个 order_no；request_id 唯一索引无重复数据

Broker 不可用

下单时停止 RabbitMQ，恢复后再观察

订单仍在 PROCESSING；Outbox 进入 RETRY；Broker 恢复后最终送达

消费者宕机

处理到一半强制停止消费者

消息可重新投递；重启后不会重复扣库存/重复建明细

支付与超时竞态

同一订单同时触发支付回调和关闭任务

最终只能是 PAID 或 CANCELLED 之一，不能来回跳

重复补偿

对同一 orderNo 连续执行释放 10 次

stock_flow 只有一条 RELEASE；库存只增加一次

@Test
void sameRequestShouldCreateOnlyOneOrder() throws Exception {
    String requestId = UUID.randomUUID().toString();
    int concurrent = 30;

    List<Future<CreateOrderResponse>> futures = IntStream.range(0, concurrent)
            .mapToObj(i -> pool.submit(() -> service.create(
                    10001L,
                    new CreateOrderRequest(20001L, 1, requestId))))
            .toList();

    Set<String> orderNos = new HashSet<>();
    for (Future<CreateOrderResponse> f : futures) {
        orderNos.add(f.get().orderNo());
    }

    assertEquals(1, orderNos.size());
    assertEquals(1, orderMapper.countByRequestId(requestId));
}

建议记录的核心指标

订单接口 P95/P99、Redis Lua 延迟、库存不足比例、Outbox NEW/RETRY 数量、RabbitMQ ready/unacked、消费失败率、DLQ 增长、PROCESSING 超时数量、库存对账差异数。只有能看到这些指标，削峰系统才算“可运维”，而不只是“能跑”。

场景

当前方案是否合适

进一步建议

普通电商大促 / 秒杀

合适

加强限流、热点隔离、Quorum Queue、自动扩容与库存对账

库存跨多个仓库分配

需要扩展

引入仓库维度 reservation，避免一个全局 stock 数字掩盖履约约束

一个订单包含大量 SKU

需要扩展

批量库存预占、失败回滚和跨 SKU 原子性需要单独设计

支付强一致资金账

只可作为订单外围架构

账务要使用独立不可变流水、严格对账和支付机构幂等号

亿级事件流与长期重放

RabbitMQ 未必是最优

可评估 Kafka/Pulsar；但库存幂等与业务补偿原则仍相同

单体小项目、访问量很低

可能过度设计

优先数据库条件更新 + 唯一索引，等真实瓶颈出现再引入 MQ

一句话概括整套设计

Redis 负责快，消息队列负责缓冲，MySQL 负责留下最终证据；唯一键负责幂等，状态机负责顺序，Outbox 负责不丢消息，补偿与对账负责把异常最终收口。