瞧瞧別人家的接口重試，那叫一個優雅！
作者：蘇三
這篇文章跟大家一起聊聊接口重試的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種方案，你將擁有讓系統“起死回生”的魔法！
責任編輯：姜華
來源：
蘇三說技術
