瞧瞧別人家的接口重試，那叫一個優雅！
前言
記得五年前的一個深夜，某個電商平臺的訂單退款接口突發異常，因為銀行系統網絡抖動，退款請求連續失敗。
原本技術團隊只是想“好心重試幾次”，結果開發小哥寫的重試代碼竟瘋狂調用了銀行的退款接口 82次！
最終導致用戶賬戶重復退款，平臺損失過百萬。
老板在復盤會上質問：“接口重試這么基礎的事，為什么還能捅出大簍子？”
大家啞口無言，因為所有人都以為只要加個 for 循環，再睡幾秒就完事了……
這篇文章跟大家一起聊聊重試的7種常用方案，希望對你會有所幫助。
1.暴力輪回法
問題場景
某實習生寫的用戶注冊短信發送接口。
在一個while循環中，重復調用第三方的發短信接口給用戶發送短信。
代碼如下：
public void sendSms(String phone) {
int retry = 0;
while (retry < 5) { // 無腦循環
try {
smsClient.send(phone);
break;
} catch (Exception e) {
retry++;
Thread.sleep(1000); // 固定1秒睡眠
}
}
}事故現場
某次短信服務器出現了過載問題，導致所有請求都延遲了3秒。
這個暴力循環的代碼在 0.5秒內同時發起數萬次重試，直接打爆短信平臺，觸發了 熔斷封禁，連正常請求也被拒絕。
教訓
- ?? 不做延遲間隔調整：固定間隔導致重試請求集中爆發
- ?? 無視異常類型：非臨時性錯誤（如參數錯誤）也嘗試重試
- ?? 修復方案：加上隨機的重試間隔，并過濾不可重試的異常
2.Spring Retry
應用場景
Spring Retry適用于中小項目，通過注解快速實現基本重試和熔斷（如訂單狀態查詢接口）。
通過聲明@Retryable注解，來實現接口重試的功能。
配置示例
@Retryable(
value = {TimeoutException.class}, // 只重試超時異常
maxAttempts = 3,
backoff = @Backoff(delay = 1000, multiplier = 2) // 1秒→2秒→4秒
)
public boolean queryOrderStatus(String orderId) {
return httpClient.get("/order/" + orderId);
}
@Recover // 兜底回退方法
public boolean fallback() {
return false;
}優勢
- 聲明式注解：代碼簡潔，與業務邏輯解耦
- 指數退避：自動拉長重試間隔
- 熔斷集成：結合 @CircuitBreaker 可快速阻斷異常流量
3.Resilience4j
高階場景
對于有些需要自定義退避算法、熔斷策略和多層防護的大中型系統（如支付核心接口），我們可以使用 Resilience4j。
核心代碼如下：
// 1. 重試配置：指數退避 + 隨機抖動
RetryConfig retryConfig = RetryConfig.custom()
.maxAttempts(3)
.intervalFunction(IntervalFunction.ofExponentialRandomBackoff(
1000L, // 初始間隔1秒
2.0, // 指數倍數
0.3 // 隨機抖動系數
))
.retryOnException(e -> e instanceof TimeoutException)
.build();
// 2. 熔斷配置：錯誤率超50%時熔斷
CircuitBreakerConfig cbConfig = CircuitBreakerConfig.custom()
.slidingWindow(10, 10, CircuitBreakerConfig.SlidingWindowType.COUNT_BASED)
.failureRateThreshold(50)
.build();
// 組合使用
Retry retry = Retry.of("payment", retryConfig);
CircuitBreaker cb = CircuitBreaker.of("payment", cbConfig);
// 執行業務邏輯
Supplier<Boolean> supplier = () -> paymentService.pay();
Supplier<Boolean> decorated = Decorators.ofSupplier(supplier)
.withRetry(retry)
.withCircuitBreaker(cb)
.decorate();效果
某電商大廠上線此方案后，支付接口 超時率下降60% ，且熔斷觸發頻率降低近 90%
真正做到了“打不還手，罵不還口”。
4.MQ隊列
適用場景
高并發、允許延時的異步場景（如物流狀態同步）。
實現原理
- 首次請求失敗后，將消息投遞至 延時隊列
- 隊列根據預設的延時時間（如5秒、30秒、1分鐘）重試消費
- 若達到最大重試次數，則轉存至 死信隊列（人工處理）
RocketMQ代碼片段如下：
// 生產者發送延時消息
Message<String> message = new Message();
message.setBody("訂單數據");
message.setDelayTimeLevel(3); // RocketMQ預設的10秒延遲級別
rocketMQTemplate.send(message);
// 消費者重試
@RocketMQMessageListener(topic = "DELAY_TOPIC")
public class DelayConsumer {
@Override
public void handleMessage(Message message) {
try {
syncLogistics(message);
} catch (Exception e) {
// 重試次數 + 1，并重新發送到更高延遲級別
resendWithDelay(message, retryCount + 1);
}
}
}如何RocketMQ的消費者消費失敗，會自動發起重試。
5.定時任務
適用場景
對于有些不需要實時反饋，允許批量處理的任務（如文件導入）的業務場景，我們可以使用定時任務。
在這里以Quartz為例。
具體代碼如下：
@Scheduled(cron = "0 0/5 * * * ?") // 每5分鐘執行
public void retryFailedTasks() {
List<FailedTask> list = failedTaskDao.listUnprocessed(5); // 查失敗任務
list.forEach(task -> {
try {
retryTask(task);
task.markSuccess();
} catch (Exception e) {
task.incrRetryCount();
}
failedTaskDao.update(task);
});
}6.兩階段提交
適用場景
對于嚴格保證數據一致性的場景（如資金轉賬），我們可以使用兩階段提交機制。
關鍵實現
- 第一階段：記錄操作流水到數據庫（狀態為“進行中”）
- 第二階段：調用遠程接口，并根據結果更新流水狀態
- 定時補償：掃描超時的“進行中”流水重新提交
大致代碼如下：
@Transactional
public void transfer(TransferRequest req) {
// 1. 記錄流水
transferRecordDao.create(req, PENDING);
// 2. 調用銀行接口
boolean success = bankClient.transfer(req);
// 3. 更新流水狀態
transferRecordDao.updateStatus(req.getId(), success ? SUCCESS : FAILED);
// 4. 失敗轉異步重試
if (!success) {
mqTemplate.send("TRANSFER_RETRY_QUEUE", req);
}
}7.分布式鎖
應用場景
對于一些多服務實例、多線程環境的防重復提交（如秒殺）的業務場景，我們可以使用分布式鎖。
這里以Redis + Lua的分布式鎖為例。
代碼如下：
public boolean retryWithLock(String key, int maxRetry) {
String lockKey = "api_retry_lock:" + key;
for (int i = 0; i < maxRetry; i++) {
// 嘗試獲取分布式鎖
if (redis.setnx(lockKey, "1", 30, TimeUnit.SECONDS)) {
try {
return callApi();
} finally {
redis.delete(lockKey);
}
}
Thread.sleep(1000 * (i + 1)); // 等待釋放鎖
}
return false;
}總結
重試就像機房里的滅火器——永遠不希望用到它，但必須保證關鍵時刻能救命。
我們工作中選擇哪種方案？
別只看技術潮流，而要看業務的長矛和盾牌，需要哪種配合。
最后送大家一句話：系統穩定的秘訣，是永遠對重試保持敬畏。
