瞧瞧別人家的接口重試，那叫一個優雅！

作者：蘇三 2025-07-14 00:00:00

開發前端

這篇文章跟大家一起聊聊接口重試的8種常用方案，希望對你會有所幫助。?

2025年某電商平臺深夜故障，因重試策略不當導致銀行退款接口被調用82次，引發重復退款126萬元！

復盤發現：80%的開發者認為重試就是for循環+Thread.sleep()，卻忽略了重試風暴、冪等性缺失、資源雪崩等致命問題。

這篇文章跟大家一起聊聊接口重試的8種常用方案，希望對你會有所幫助。

一、重試機制的原因

1.為什么需要重試？

臨時性故障占比超70%，合理重試可將成功率提升至99%以上。

2.重試的三大陷阱

重試風暴：固定間隔重試引發請求洪峰（如萬次重試壓垮服務）
數據不一致：非冪等操作導致重復生效（如重復扣款）
鏈路阻塞：長時重試耗盡線程資源（如數據庫連接池枯竭）

二、基礎重試方案

1.暴力輪回法（青銅）

問題代碼：

// 危險！切勿直接用于生產！
public void sendSms(String phone) {
    int retry = 0;
    while (retry < 5) {
        try {
            smsClient.send(phone);
            break;
        } catch (Exception e) {
            retry++;
            Thread.sleep(1000); // 固定1秒間隔
        }
    }
}

事故案例：某平臺短信接口重試風暴，觸發第三方熔斷封禁。

優化方向：增加隨機抖動 + 異常過濾。

2.Spring Retry（黃金）

聲明式注解控制重試：

@Retryable(
    value = {TimeoutException.class}, // 僅重試超時異常
    maxAttempts = 3,
    backoff = @Backoff(delay = 1000, multiplier = 2) // 指數退避：1s→2s→4s
)
public boolean queryOrder(String orderId) {
    return httpClient.get("/order/" + orderId);
}

@Recover // 兜底降級
public boolean fallback(TimeoutException e) {
    return false; 
}

優勢：

注解驅動，業務零侵入
支持指數退避策略
無縫集成熔斷器@CircuitBreaker

三、高階重試方案

1.Resilience4j（白金）

應對高并發場景的重試+熔斷組合拳：

// 重試配置：指數退避+隨機抖動
RetryConfig retryConfig = RetryConfig.custom()
    .maxAttempts(3)
    .intervalFunction(IntervalFunction.ofExponentialRandomBackoff(
        1000L, 2.0, 0.3// 初始1s，指數倍率2，抖動率30%
    ))
    .retryOnException(e -> e instanceof TimeoutException)
    .build();

// 熔斷配置：錯誤率超50%觸發熔斷
CircuitBreakerConfig cbConfig = CircuitBreakerConfig.custom()
    .slidingWindow(10, 10, COUNT_BASED) 
    .failureRateThreshold(50)
    .build();

// 組合裝飾
Supplier<Boolean> supplier = () -> paymentService.pay();
Supplier<Boolean> decorated = Decorators.ofSupplier(supplier)
    .withRetry(Retry.of("payment", retryConfig))
    .withCircuitBreaker(CircuitBreaker.of("payment", cbConfig))
    .decorate();

效果：某支付系統接入后超時率下降60%，熔斷觸發率降低90%

2.Guava-Retrying（鉆石）

靈活定制復雜重試邏輯：

Retryer<Boolean> retryer = RetryerBuilder.<Boolean>newBuilder()
    .retryIfResult(Predicates.equalTo(false)) // 返回false重試
    .retryIfExceptionOfType(IOException.class)
    .withWaitStrategy(WaitStrategies.exponentialWait(1000, 30, TimeUnit.SECONDS))
    .withStopStrategy(StopStrategies.stopAfterAttempt(5))
    .build();

retryer.call(() -> uploadService.upload(file)); // 執行

核心能力：

支持結果/異常雙模式觸發
提供7種等待策略（隨機、指數、遞增等）
可監聽每次重試事件

四、分布式重試方案

1.MQ延時隊列（星耀Ⅰ）

適用場景：異步解耦的高并發系統（如物流狀態同步）

架構原理：

RocketMQ實現：

// 生產者發送延時消息
Message msg = new Message();
msg.setBody(orderData);
msg.setDelayTimeLevel(3); // RocketMQ預設10秒延遲
rocketMQTemplate.send(msg);

// 消費者
@RocketMQMessageListener(topic = "RETRY_TOPIC")
publicclass RetryConsumer {
    public void consume(Message msg) {
        try {
            process(msg);
        } catch (Exception e) {
            // 提升延遲級別重發
            msg.setDelayTimeLevel(5); 
            resend(msg);
        }
    }
}

優勢：

重試與業務邏輯解耦
天然支持梯度延時
死信隊列兜底人工處理

2.定時任務補償（星耀Ⅱ）

適用場景：允許延遲的批處理任務（如文件導入）

@Scheduled(cron = "0 0/5 * * * ?") // 每5分鐘執行
public void retryFailedTasks() {
    List<FailedTask> tasks = taskDao.findFailed(MAX_RETRY);
    tasks.forEach(task -> {
        if (retry(task)) {
            task.markSuccess();
        } else {
            task.incrRetryCount();
        }
        taskDao.update(task);
    });
}

關鍵點：

數據庫記錄失敗任務
低峰期批量處理
獨立線程池隔離資源

3.兩階段提交（王者Ⅰ）

金融級一致性保障（如轉賬）：

@Transactional
public void transfer(TransferRequest req) {
    // 階段1：持久化操作流水
    TransferRecord record = recordDao.create(req, PENDING);
    
    // 階段2：調用銀行接口
    boolean success = bankClient.transfer(req);
    
    // 更新狀態
    recordDao.updateStatus(record.getId(), success ? SUCCESS : FAILED);
    
    if (!success) {
        mqTemplate.send("TRANSFER_RETRY_QUEUE", req); // 觸發異步重試
    }
}

// 補償任務（掃描掛起流水）
@Scheduled(fixedRate = 30000)
public void compensate() {
    List<TransferRecord> pendings = recordDao.findPending(30);
    pendings.forEach(this::retryTransfer);
}

核心思想：操作前先留痕，任何失敗可追溯

4.分布式鎖重試（王者Ⅱ）

防重復提交終極方案（如秒殺）：

public boolean retryWithLock(String key, int maxRetry) {
    String lockKey = "RETRY_LOCK:" + key;
    for (int i = 0; i < maxRetry; i++) {
        if (redis.setIfAbsent(lockKey, "1", 30, SECONDS)) {
            try {
                return callApi(); // 持有鎖時執行
            } finally {
                redis.delete(lockKey);
            }
        }
        Thread.sleep(1000 * (i + 1)); // 等待鎖釋放
    }
    return false;
}

適用場景：

多實例部署環境
高競爭資源訪問
等冪性要求極高業務

五、響應式重試：Spring WebFlux方案

1.響應式重試操作符

Mono<String> remoteCall = Mono.fromCallable(() -> {
    if (Math.random() > 0.5) throw new RuntimeException("模擬失敗");
    return "Success";
});

remoteCall.retryWhen(Retry.backoff(3, Duration.ofSeconds(1))
          .doBeforeRetry(signal -> log.warn("第{}次重試", signal.totalRetries()))
          .subscribe();

策略支持：

指數退避：Retry.backoff(maxAttempts, firstBackoff)
隨機抖動：.jitter(0.5)
條件過濾：.filter(ex -> ex instanceof TimeoutException)

六、重試的避坑指南

1.必須實現的三大防護

防護類型	目的	實現方案
冪等性防護	防止重復生效	唯一ID+狀態機
重試風暴防護	避免洪峰沖擊	指數退避+隨機抖動
資源隔離	保護主鏈路資源	線程池隔離/熔斷器

2.經典踩坑案例

坑1：無限制重試→ 某系統因未設重試上限，線程池爆滿導致集群雪崩
解法：maxAttempts=3 + 熔斷降級
坑2：忽略錯誤類型→ 參數錯誤（4xx）被反復重試，放大無效流量
解法：retryOnException(e -> e instanceof TimeoutException)
坑3：上下文丟失→ 異步重試后丟失用戶會話信息
解法：重試前快照關鍵上下文（如userId、requestId）

七、方案選型參考圖

總結

敬畏每一次重試：重試不是暴力補救，而是精密流量控制。
面向失敗設計：假設網絡不可靠、服務會宕機、資源終將枯竭。
分層防御體系：

a.代碼層：冪等性 + 超時控制

b.框架層：退避策略 + 熔斷降級

c.架構層：異步解耦 + 持久化補償

沒有銀彈：秒殺場景用分布式鎖，支付系統用兩階段提交，IoT設備用MQTT重試機制。

正如分布式系統大師Leslie Lamport所言：“重試是分布式系統的成人禮”。

掌握這8種方案，你將擁有讓系統“起死回生”的魔法！

責任編輯：姜華來源：蘇三說技術