Java CompletableFuture 超时重试如何避免重复扣款：幂等键、任务状态与告警闭环

支付接口交给异步任务后，最危险的情况不是明确返回失败，而是请求已经发出，Java 这边却先收到了超时。此时再把同一笔订单原样重试，渠道可能已经扣款成功，最终就会出现“用户付了一次，系统记了两次”的事故。

稳妥的做法是把“提交”和“确认”拆开：每笔支付先生成不可变的幂等键，任务状态落库，超时只进入查询或延迟重试，不直接判定为失败。只有渠道结果和本地状态都核对完成，业务订单才允许进入已支付。

先把支付任务拆成可核对的状态

先定义一张简单的 payment_task 表。关键字段不是“最后一次异常信息”，而是能回答三件事：这笔业务是谁发起的、渠道请求走到哪一步、下一次检查应该在什么时候发生。

数据库层面给 order_no 和 idempotency_key 加唯一约束。这样即使消息重复到达，第二次插入也只能拿到已有任务，不能创建第二个扣款流程。

幂等键先固定，再把提交动作包进异步链

幂等键建议由业务订单号和支付场景组成，例如 pay:order:202607260001。它不是每次尝试的流水号，而是“这笔业务”的身份证。重试、查询和人工补偿都必须带同一个值。

String key = "pay:order:" + orderNo;

PaymentTask task = taskRepository.findOrCreate(orderNo, key);
if (task.isTerminal()) {
    return CompletableFuture.completedFuture(task.result());
}

return CompletableFuture
        .supplyAsync(() -> channel.submit(orderNo, key, amount))
        .orTimeout(3, TimeUnit.SECONDS)
        .thenCompose(reply -> resultService.confirm(task, reply))
        .exceptionally(error -> retryService.markUnknown(task, error));

这里的重点有两个。第一，findOrCreate 必须在事务内完成，拿到的任务状态要能被后续重试复用。第二，orTimeout 只负责结束本次等待，不能把任务直接改成支付失败；因为渠道的网络请求可能已经落地。

超时之后只做两件事：标记未知，安排下一次核对

收到超时异常时，把任务从 PROCESSING 改为 UNKNOWN，记录错误类型和 next_check_at。下一轮先调用渠道查询接口，只有明确得到“未支付”时才允许再次提交；若得到“已支付”，直接补齐本地订单。

延迟间隔可以采用 1 分钟、5 分钟、15 分钟三档，并设置最大检查次数。示例中的调度器只负责捞取到期任务，真正的状态变更仍由数据库条件更新保护：

List due = taskRepository.findDue("UNKNOWN", Instant.now());
for (PaymentTask task : due) {
    if (!taskRepository.claim(task.id(), task.retryCount())) {
        continue;
    }
    CompletableFuture
        .supplyAsync(() -> channel.query(task.orderNo(), task.idempotencyKey()))
        .completeOnTimeout(QueryReply.unknown(), 3, TimeUnit.SECONDS)
        .thenAccept(reply -> retryService.applyQueryResult(task, reply));
}

claim 可以用 update ... where id = ? and retry_count = ? 实现。返回 0 行说明别的节点已经抢到，当前线程不要继续处理。这个小条件能挡住多实例部署时的重复查询。

门禁要放在结果确认处，而不是只看异常

一条实用的门禁顺序是：先查本地终态，再查渠道结果，最后才决定是否允许重新提交。任何一个环节拿不到确定结果，都保留 UNKNOWN，并把原始渠道流水号、响应摘要和重试次数写入审计记录。

• SUCCESS：渠道明确成功，本地订单从未支付改为已支付，操作必须幂等。
• 未支付：渠道明确没有扣款，且任务未超过上限，才可再次提交。
• UNKNOWN：网络超时、渠道处理中或响应无法解析，进入下一次核对。
• MANUAL：超过检查上限或金额、订单状态不一致，停止自动动作并通知人工。

不要用 exceptionally 的返回值直接覆盖业务状态。它适合把异常转换成一个可继续传递的结果，但支付状态必须由状态机方法统一修改，否则某个异步分支很容易把“查询失败”误写成“支付失败”。

失败处理要能停下来，也要让人看见

超过 3 次仍是 UNKNOWN 时，任务转为 MANUAL，同时发送包含订单号、幂等键、最近一次渠道流水号和建议动作的告警。告警里不要放完整银行卡号或用户敏感信息，保留后台可检索的任务 ID 即可。

人工处理完成后，不建议直接改订单表。可以提供一个“复核通过”动作，先写入复核记录，再由同一个状态转换服务把任务和订单一起更新。这样之后查审计日志，能看见是谁、依据什么结果做了收口。

一段最小验证清单

1. 同一个 order_no 并发提交两次，确认只生成一个幂等键。
2. 让渠道在请求落地后故意延迟响应，确认本地进入 UNKNOWN 而不是失败。
3. 让查询第一次超时、第二次返回成功，确认不会再次发起扣款。
4. 让查询连续超过上限，确认状态进入 MANUAL 且告警只发送一次。
5. 重复消费同一条重试消息，确认 claim 条件能挡住第二个处理节点。

常见问题

CompletableFuture 超时后能不能直接重试？

不能直接把原提交动作重跑。先查询渠道结果；只有明确未支付并且幂等键仍对应同一订单时，才进入下一次提交。

幂等键应该每次重试都变吗？

不应该。幂等键描述的是同一笔业务，重试只增加检查次数或尝试记录，不能换掉业务幂等键。

为什么还要保留 UNKNOWN 状态？

因为超时只说明本地没有按时收到结果。保留未知状态，才能把“查询确认”和“重新提交”区分开。

什么时候应该停止自动重试？

达到次数上限、金额与渠道结果不一致、或渠道返回无法解释的状态时，应转人工复核，并停止自动扣款动作。

小结

Java 异步支付流程的安全边界，不在于把超时设置得多短，而在于有没有把一次提交、结果查询、重试和人工复核串成可验证的状态链。CompletableFuture 负责组合等待过程，幂等键和状态表负责约束业务动作，告警则负责把无法自动判断的部分交给人。