Java Spring Retry 如何避免异常重试导致消息重复处理

Java 消费消息时，真正容易重复的不是 @Retryable 这几个注解，而是“业务已经成功，消费者却没来得及确认”这一小段窗口。消息队列随后再次投递，重试方法就可能再次扣库存、写订单或调用支付接口。可靠的做法是把两件事拆开：Spring Retry 只负责处理临时故障；消息幂等则依靠稳定的 messageId、持久化去重记录和唯一约束完成。

先用唯一消息 ID 抢占一次处理资格，再让本地业务写入和去重状态在同一事务内提交；跨出本地事务的 HTTP、支付或通知调用，必须把这个 ID 作为幂等键传给下游，不能只依赖重试次数。

先把重试范围收窄到临时故障

网络超时、连接池暂时耗尽、下游返回 503，适合短暂退避后再试；参数校验失败、订单不存在、权限不足则不应重试。下面的代理类只包住外部调用，避免把“领取消息”和“真正产生副作用”的所有步骤无差别重复。

@Service
public class PaymentGatewayRetry {

    @Retryable(
        retryFor = TemporaryGatewayException.class,
        noRetryFor = InvalidPaymentException.class,
        maxAttempts = 3,
        backoff = @Backoff(delay = 500, multiplier = 2.0, maxDelay = 3000)
    )
    public void charge(PaymentCommand command) {
        // 把稳定的 messageId 作为下游幂等键，而不是每次生成随机请求号
        gateway.charge(command.messageId(), command.amount());
    }

    @Recover
    public void recover(TemporaryGatewayException ex, PaymentCommand command) {
        // 耗尽重试后交给失败状态或死信流程，不能静默当成成功
        throw new PaymentNeedsRecovery(command.messageId(), ex);
    }
}

配置类需要开启 Spring Retry，并且调用必须经过 Spring 代理；同一个类里用 this.charge() 的自调用不会经过代理。生产代码还应限制重试异常类型，给每次尝试带上 messageId 日志，方便把同一消息的多次投递串起来。

用唯一消息 ID 在副作用前挡住重复投递

去重记录至少要有 message_id、处理状态和更新时间，并对消息 ID 建立唯一索引。第一次投递插入 PROCESSING，后续投递遇到唯一键冲突就读取状态：已经是 DONE 直接返回；仍是 PROCESSING 则按租约判断是否由异常实例接管。

CREATE TABLE inbox_message (
    message_id VARCHAR(128) PRIMARY KEY,
    status VARCHAR(16) NOT NULL,
    updated_at TIMESTAMP NOT NULL
);
-- 主键保证同一个 messageId 只能占到一份处理资格

如果业务写入和 inbox 表在同一个数据库，推荐把“插入去重记录、更新订单、标记 DONE”放在同一个事务里。业务异常会一起回滚，消息可以再次交给消费者；事务成功提交后即使确认动作丢失，下一次投递也会看到 DONE，不会重复扣款。

本地事务和外部服务要分开设计

数据库事务不能自动覆盖支付网关、短信服务或另一个微服务。若先成功调用外部服务，再因本地提交失败而抛出异常，Spring Retry 可能再次调用外部服务。因此下游接口应接收同一个幂等键，并在服务端按键返回第一次结果。

@Transactional
public void handle(OrderMessage message) {
    // 唯一索引竞争失败说明消息已被其他投递处理
    if (!inboxRepository.start(message.messageId())) {
        return;
    }

    // 本地订单变更和 DONE 标记一起提交；异常时一起回滚
    orderRepository.reserve(message.orderId(), message.quantity());
    paymentGatewayRetry.charge(
        new PaymentCommand(message.messageId(), message.amount())
    );
    inboxRepository.markDone(message.messageId());
}

如果外部调用不支持幂等键，不能靠“把 maxAttempts 调小”解决重复问题。可以改成 outbox：事务内只写订单和待发送事件，由独立投递器带着 messageId 发送；或者让下游先落一张带唯一键的请求表，再异步执行实际动作。

耗尽重试后要留下可恢复的失败证据

@Recover 不应该只打印一行日志然后返回成功。应保存最后异常、尝试次数、下一步处理人或死信地址，并让消费者根据失败结果决定确认消息还是进入 DLT。恢复任务重放时继续使用原始 messageId，这样即使人工重复点击，也仍受同一条幂等规则保护。

上线前可以按这张清单演练：第一次处理在提交后模拟确认失败；第二次投递确认唯一键被命中；临时 503 能按退避重试；参数异常只执行一次；外部调用超时后查看下游是否按幂等键返回原结果；最后检查 FAILED 消息能否安全重放。

Java Spring Retry 避免消息重复处理常见问题

@Retryable 会自动保证消息只执行一次吗？

不会。它只决定某个方法遇到指定异常时如何再次调用；消息重复投递仍要由持久化唯一键、事务或下游幂等接口处理。

为什么重试后数据库里还是出现两条业务记录？

通常是业务表没有唯一业务键，或去重记录与业务写入不在同一事务。先让 message_id 或业务流水号有唯一约束，再检查提交和确认之间的异常窗口。

PROCESSING 一直不结束怎么办？

给处理记录增加更新时间或租约期限。超过期限后只能由一个实例抢占，并记录接管原因；不要让每个重复消费者都直接重新执行。

外部 HTTP 接口没有幂等参数怎么办？

优先推动下游增加幂等键；短期可用 outbox、请求去重表或人工补偿队列隔离调用。仅靠 Spring Retry 无法证明外部副作用没有发生。