Java高并发下防止订单重复提交的完整方案与实践

一、问题背景：为什么“insert 前先 select”挡不住重复提交

在订单系统的日常开发中，很多团队习惯在保存订单前做一次查询：先根据订单号、外部流水号或业务唯一标识判断是否已经存在，如果存在则不再插入。这种做法的好处是逻辑简单、实现成本低，也是很多早期系统采用的标准做法。

但问题在于，这种“先查后插”的模式存在天然的竞态窗口。尤其是在高并发、网络重试、用户重复点击、定时任务重放等场景下，两个甚至多个请求可能在极短时间内同时进入判断逻辑。例如：

• 请求 A 查询到订单不存在，准备插入；
• 请求 B 在请求 A 提交事务前也查询到订单不存在；
• 请求 A 插入成功；
• 请求 B 随后也插入成功，于是产生两条相同订单。

在数据库事务隔离级别为“读已提交”或更低时，这种现象尤其明显。核心原因在于“查”和“插”并不是原子操作，程序无法只靠一次普通查询来阻止另一个并发的插入。

因此，面对“3 毫秒内同一订单提交两次”的情况，不能依赖单纯的“insert 前先 select”，必须从更深层的幂等性与并发控制角度设计防护机制。

二、理解重复提交：它不仅是“重复点击”

重复提交的来源通常可以归纳为以下几类：

1. 用户侧重复操作

用户点击“提交订单”按钮后，因页面没有及时响应而再次点击，导致前端发出多个相同请求。

2. 网络层重试

客户端在请求超时后自动重试。虽然第一次请求可能已到达服务端并成功写入，但客户端无法感知，于是重新发送。

3. 网关或负载均衡重放

部分中间层组件在超时或失败时可能会重新转发请求，造成同一业务请求在服务端被处理多次。

4. 消息重复投递

在异步下单链路中，消息队列可能因消费失败、重新入队等原因重复投递同一条下单消息。

5. 定时补偿或人工重跑

对账、修数、补单等操作若缺少幂等控制，也可能触发同一订单的再次生成。

可以看出，重复提交不是单点问题，而是分布式系统中“至少一次投递”的典型副作用。要解决它，需要从写入模型、唯一性约束和状态判断等多方面入手。

三、设计目标：把“多次请求”变成“一次生效”

解决重复提交的关键，不是简单拒绝第二次请求，而是保证“重复请求不会产生新的副作用”。这个目标通常被称为“幂等”。

在订单场景下，幂等可以细化为三个层次：

1. 同一业务单号只产生一条订单记录；
2. 多次请求返回的结果一致或可识别；
3. 在并发情况下仍然保持上述保证。

比如，订单号是系统生成的唯一标识，即使有两个线程同时提交同一订单号，也只会有一条成功，另一条被拒绝或返回已存在信息。

四、常见防重复提交机制

1. 前端防抖与按钮禁用

最直接的做法是在前端控制交互：

• 点击提交后立即禁用按钮；
• 设置倒计时，例如 3 秒内不可再次点击；
• 使用遮罩层或 loading 状态阻止重复操作。

这类措施能有效减少用户侧重复点击，但不能作为最终防线。因为用户仍可通过刷新页面、发送脚本请求等方式绕过前端控制。

示例逻辑：

let submitting = false;
function submitOrder() {
  if (submitting) {
    return;
  }
  submitting = true;
  document.getElementById("btn-submit").disabled = true;
  callOrderApi().finally(() => {
    submitting = false;
    document.getElementById("btn-submit").disabled = false;
  });
}

前端限制属于交互层防护，是降低重复请求频率的第一道闸门。

2. 数据库唯一索引约束

在数据库层面，通过唯一索引保证关键字段不能重复。以订单表为例：

• 若业务要求“同一外部流水号只能有一条订单”，则可在 out_trade_no 上建唯一索引；
• 若同一用户同一秒只能下一次单，可对 user_id + biz_date + seq 建立联合唯一索引；
• 若能使用系统生成的全局唯一订单号，则订单号本身就是主键或唯一索引。

示例 DDL：

ALTER TABLE `order` 
ADD UNIQUE KEY `uk_out_trade_no` (`out_trade_no`);

当重复插入时，数据库会抛出唯一键冲突，应用捕获后即可认为订单已存在。这种机制天然支持并发，因为唯一性检查由数据库在执行插入时完成，具备原子性。

但唯一索引也有局限：并非所有业务都能设计出明确的唯一字段；若订单状态允许部分重复或取消后重新创建，唯一索引会限制业务灵活性。

3. 先插入占位记录，再进行状态流转

针对“先查后插”的缺陷，一种有效做法是改变写入顺序：先执行插入，再处理业务逻辑。具体流程如下：

1. 收到请求后，立即以唯一业务标识插入“处理中”状态的订单；
2. 如果插入成功，继续执行后续业务；
3. 如果插入失败并命中唯一索引，说明请求已存在，返回已处理或处理中。

这种方式将“是否已存在”的判断交给了数据库唯一约束，而不是应用程序的查询逻辑，从而避免并发下的数据竞态。

4. 幂等表 / 去重表

如果订单主表不适合直接建唯一索引，可以引入一张独立的幂等表：

字段	含义
id	主键
request_key	业务幂等键，如外部流水号
status	请求处理状态
create_time	创建时间

处理流程如下：

1. 收到请求后，先向幂等表插入一条记录，request_key 为幂等键；
2. 插入成功则继续处理业务；
3. 插入失败则根据 status 判断是否已经处理完成；
4. 如果上一次处理失败，可允许再次重试或转人工介入。

这种方式将业务表与幂等控制解耦，适用于复杂业务、多系统交互、异步处理等场景，也便于记录请求源头、次数和执行结果。

5. 分布式锁

在应用层使用分布式锁，将“判断是否存在 + 插入订单”这一段逻辑串行化。常见的实现方式包括：

• 基于数据库行锁；
• 基于缓存系统实现分布式锁；
• 基于分布式协调服务实现临时节点锁。

以基于缓存系统的分布式锁为例：

String lockKey = "order:lock:" + outTradeNo;
boolean locked = cache.tryLock(lockKey, 10, TimeUnit.SECONDS);
if (!locked) {
    return Result.fail("订单处理中，请勿重复提交");
}
try {
    // 查询是否存在
    // 不存在则插入订单
} finally {
    cache.unlock(lockKey);
}

分布式锁能够有效降低并发冲突，但需要注意几点：

• 锁的粒度应尽量小，避免影响无关请求；
• 必须设置超时时间，防止异常情况导致死锁；
• 解锁时需要校验持有者，避免误删他人锁。

6. 令牌机制（Token）

令牌机制主要用于防止短时间窗口内的重复提交，通常参与前端页面交互与后端校验：

1. 用户进入下单页时，服务端生成一个唯一 token；
2. 页面提交订单时携带该 token；
3. 服务端校验 token 是否存在且未被使用；
4. 校验通过后，立即标记该 token 已使用，再执行下单逻辑。

示意流程：

String token = request.getToken();
boolean consumed = cache.consumeToken(token);
if (!consumed) {
    return Result.fail("请勿重复提交");
}
// 继续执行下单逻辑

令牌机制的优点是轻量、易接入，缺点是一次性 token 管理需要配合页面生命周期，且通常依赖缓存服务来保证消费动作的原子性。

五、并发场景下的组合方案

实际项目中，单一方案往往难以覆盖所有情况，更常见的是组合使用多种机制。例如：

• 前端按钮禁用 + 令牌机制：控制普通用户重复点击；
• 唯一索引 + 先插占位记录：应对并发写入与消息重放；
• 幂等表 + 状态机：管理异步处理与失败重试；
• 分布式锁：用于短时间内的临界区保护，避免重复创建。

一个比较稳健的订单落库链路可以设计如下：

1. 前端生成并携带 token，提交订单；
2. 服务端消费 token，拦截明显重复提交；
3. 根据外部流水号查幂等表，确定请求是否已处理；
4. 尝试以“处理中”状态插入订单；
5. 若插入成功，执行业务处理并更新订单状态；
6. 若插入失败，读取已有订单并返回固定结果。

这种多层设计将防护重心后置到数据库与幂等控制上，而不是依赖某一次查询。

六、注意事项

1. 幂等键设计必须明确

没有明确的幂等键，就无法判断“重复”是否成立。通常使用订单号、外部流水号、业务编码 + 时间片等作为幂等依据。

2. 唯一索引一旦建立，调整成本较高

生产环境中，唯一索引会直接影响写入性能，并且对历史数据有约束。因此需在上线前做好数据校验与清理。

3. 幂等不等于拒绝所有重复请求

在某些业务中，重复请求应返回第一次处理的结果，而不是简单报错。接口设计时需明确重复提交的返回契约。

4. 异步链路更需幂等

消息重复投递、任务重跑等场景中，服务端通常没有用户 token 或前端拦截可用，此时唯一索引与幂等表几乎是唯一可靠手段。

5. 测试要覆盖并发场景

重复提交的验证不能只靠手工模拟，应通过压测或并发测试，模拟 3 毫秒内多个请求同时进入接口的情况。

七、结语

防止订单重复提交并不是一个简单的前端按钮问题，而是一个涉及接口设计、数据模型、并发控制、缓存与消息处理的系统工程。“先 select 再 insert”在低并发时可用，但面对真正的并发场景，仍然需要借助数据库唯一约束、幂等表、分布式锁等手段建立可靠防线。

核心原则可以归纳为一句话：让数据库或基础设施去保证“只成功一次”，而不是依赖应用层的查询判断。 当重复请求无法避免时，系统必须有能力识别、拦截或将其转化为无副作用的请求。