在 618 大促的技術(shù)戰(zhàn)場(chǎng)上，每一行代碼、每一個(gè)配置都影響著一線的實(shí)實(shí)在在的業(yè)務(wù)。一次看似平常的發(fā)版，卻意外暴露了我們系統(tǒng)中的定時(shí)任務(wù)管理短板，這促使我們深入剖析分布式任務(wù)調(diào)度中異常重試機(jī)制的技術(shù)細(xì)節(jié)，并最終將其轉(zhuǎn)化為守護(hù)系統(tǒng)穩(wěn)定性的堅(jiān)固防線。?

一、異常事件回溯：隱藏在發(fā)版背后的定時(shí)炸彈?

發(fā)版次日，業(yè)務(wù)部門反饋商家未收到門店收貨明細(xì)郵件，導(dǎo)致門店收貨業(yè)務(wù)收到影響。技術(shù)團(tuán)隊(duì)迅速啟動(dòng)應(yīng)急流程，通過(guò)全鏈路日志追蹤和系統(tǒng)狀態(tài)分析，發(fā)現(xiàn)了問(wèn)題的根源是：發(fā)版過(guò)程中，由于服務(wù)重啟，中斷了定時(shí)任務(wù)進(jìn)程，正在執(zhí)行的郵件發(fā)送任務(wù)被意外終止。而該任務(wù)在管理平臺(tái)上并未配置任何重試策略，業(yè)務(wù)代碼上也沒(méi)有進(jìn)行相關(guān)的檢測(cè)和重試，這就導(dǎo)致任務(wù)失敗后無(wú)法自動(dòng)恢復(fù)執(zhí)行，也未被及時(shí)感知到，進(jìn)而引發(fā)業(yè)務(wù)阻斷。?

為解決燃眉之急，研發(fā)人員立即登錄任務(wù)管理平臺(tái)，手工觸發(fā)郵件發(fā)送任務(wù)，確保業(yè)務(wù)及時(shí)恢復(fù)。但這次事件給我們敲響了警鐘：在分布式任務(wù)調(diào)度場(chǎng)景下，面對(duì)網(wǎng)絡(luò)抖動(dòng)、進(jìn)程異常終止等場(chǎng)景，異常重試機(jī)制是保障業(yè)務(wù)可靠性的關(guān)鍵。?

二、重試策略設(shè)計(jì)：從理論到代碼的深度解析?

2.1 驗(yàn)證EasyJob的重試策略

在復(fù)盤問(wèn)題的過(guò)程中，我們發(fā)現(xiàn)了EasyJob分布式任務(wù)是具有重試策略的，只是默認(rèn)不開啟，而不是默認(rèn)開啟。

該策略以三個(gè)核心參數(shù)為基礎(chǔ)：首次重試間隔時(shí)間 F、重試間隔乘數(shù) M 和最大重試次數(shù) C。

通過(guò)這三個(gè)參數(shù)的組合，我們可以靈活控制任務(wù)重試節(jié)奏，平衡系統(tǒng)負(fù)載與任務(wù)恢復(fù)效率。?

例如：配置t=10s, M=2, C=10，則間隔時(shí)間依次是：

驗(yàn)證日志：

21:45:29.990 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 開始執(zhí)行發(fā)送郵件任務(wù)
21:45:40.204 [main-schedule-worker-pool-1-thread-2] INFO  cn.jdl.tech_and_data.EmailSendingTask - 開始執(zhí)行發(fā)送郵件任務(wù)
21:46:00.674 [main-schedule-worker-pool-1-thread-3] INFO  cn.jdl.tech_and_data.EmailSendingTask - 開始執(zhí)行發(fā)送郵件任務(wù)
21:46:41.749 [main-schedule-worker-pool-1-thread-4] INFO  cn.jdl.tech_and_data.EmailSendingTask - 開始執(zhí)行發(fā)送郵件任務(wù)
21:48:02.398 [main-schedule-worker-pool-1-thread-5] INFO  cn.jdl.tech_and_data.EmailSendingTask - 開始執(zhí)行發(fā)送郵件任務(wù)
21:50:43.008 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 開始執(zhí)行發(fā)送郵件任務(wù)

與上面計(jì)算的一致。

驗(yàn)證方案：

1、實(shí)現(xiàn)接口：com.wangyin.schedule.client.job.ScheduleFlowTask，并設(shè)置任務(wù)返回失?。?/p>

2、創(chuàng)建CRON觸發(fā)器

3、設(shè)置自動(dòng)重試參數(shù)

4、暫停任務(wù)并手工觸發(fā)一次

2.2 實(shí)現(xiàn)一個(gè)簡(jiǎn)單的重試策略

根據(jù)上述策略，簡(jiǎn)單實(shí)現(xiàn)了一個(gè)靈活可配置的任務(wù)重試機(jī)制。

public class TaskRetryExecutor {
    @Getter
    private final ScheduledExecutorService executor = newScheduledThreadPool(10);
    private final long firstRetryInterval;
    private final int intervalMultiplier;
    private final int maxRetryCount;

    public TaskRetryExecutor(long firstRetryInterval, int intervalMultiplier, int maxRetryCount) {
        this.firstRetryInterval = firstRetryInterval;
        this.intervalMultiplier = intervalMultiplier;
        this.maxRetryCount = maxRetryCount;
    }

    public void submitRetryableTask(Runnable task) {
        executeWithRetry(task, 1);
    }

    private void executeWithRetry(Runnable task, int currentRetryCount) {
        executor.schedule(() -> {
            try {
                task.run();
                log.info("任務(wù)在第{}次嘗試時(shí)成功執(zhí)行", currentRetryCount);
            } catch (Exception e) {
                log.error("任務(wù)在第{}次嘗試時(shí)執(zhí)行失敗", currentRetryCount, e);
                if (currentRetryCount <= maxRetryCount) {
                    long delay = calculateRetryDelay(currentRetryCount);
                    log.info("計(jì)劃在{}毫秒后進(jìn)行第{}次重試", delay, currentRetryCount);
                    executeWithRetry(task, currentRetryCount + 1);
                } else {
                    log.error("超過(guò)最大重試次數(shù)。任務(wù)執(zhí)行最終失敗。");
                }
            }
        }, currentRetryCount == 1 ? 0 : calculateRetryDelay(currentRetryCount), TimeUnit.MILLISECONDS);
    }

    public long calculateRetryDelay(int retryCount) {
        if (retryCount == 1) {
            return firstRetryInterval;
        } else if (retryCount > 1 && retryCount <= maxRetryCount) {
            long previousDelay = calculateRetryDelay(retryCount - 1);
            return previousDelay * intervalMultiplier;
        }
        return -1; // 超出最大重試次數(shù)，返回錯(cuò)誤標(biāo)識(shí)
    }
}

?在上述代碼中：

1.TaskRetryExecutor類封裝了任務(wù)重試的核心邏輯。構(gòu)造函數(shù)接收三個(gè)關(guān)鍵參數(shù)：firstRetryInterval、intervalMultiplier和maxRetryCount，用于配置重試策略，對(duì)應(yīng)于EasyJob的F、M、C參數(shù)。

2.submitRetryableTask方法接收一個(gè)可執(zhí)行任務(wù)，并啟動(dòng)重試流程。它調(diào)用executeWithRetry方法，初始重試次數(shù)為1。

3.executeWithRetry方法是重試邏輯的核心。它使用ScheduledExecutorService來(lái)調(diào)度任務(wù)執(zhí)行：

?如果任務(wù)執(zhí)行成功，記錄成功日志。

??如果任務(wù)執(zhí)行失敗且未超過(guò)最大重試次數(shù)，計(jì)算下一次重試的延遲時(shí)間，并遞歸調(diào)用自身進(jìn)行重試。

??如果超過(guò)最大重試次數(shù)，記錄最終失敗日志。

4.calculateRetryDelay方法實(shí)現(xiàn)了重試間隔的計(jì)算規(guī)則：

?第一次重試使用firstRetryInterval。

?之后的重試間隔是前一次間隔乘以intervalMultiplier。

?如果超出最大重試次數(shù)，返回-1表示錯(cuò)誤。

通過(guò)這種設(shè)計(jì)，我們實(shí)現(xiàn)了一個(gè)可復(fù)用、可配置的任務(wù)重試機(jī)制。它能夠根據(jù)配置的參數(shù)自動(dòng)調(diào)整重試間隔，在任務(wù)失敗時(shí)進(jìn)行有策略的重試，同時(shí)避免無(wú)限重試導(dǎo)致的資源浪費(fèi)。

詳細(xì)代碼可在以下Git倉(cāng)庫(kù)中找到：git@coding.jd.com:newJavaEngineerOrientation/TaskRetryStrategies.git

2.3 重試策略的理論分析

2.3.1 EasyJob對(duì)乘數(shù)和最大重試次數(shù)的限制

在對(duì)EasyJob也進(jìn)行了重試的驗(yàn)證中發(fā)現(xiàn)：

1.每次重做的乘數(shù)取值范圍是[1,8]，可以是具有一位小數(shù)位的浮點(diǎn)數(shù)，比如3.5，

2.最多重做次數(shù)是[1,16]間的整數(shù)，第一次重試的間隔沒(méi)有限制，單位是秒。

2.3.2 梯度分析

通過(guò)上面的驗(yàn)證和重試相關(guān)概念的定義，可以得到：第n次重試的間隔時(shí)間=第一次間隔時(shí)間*乘數(shù)^(n-1)，即：

其中：

對(duì)乘數(shù)M的梯度：

對(duì)重試次數(shù)n的梯度：

詳細(xì)推導(dǎo)： http://xingyun.jd.com/codingRoot/newJavaEngineerOrientation/TaskRetryStrategies/blob/master/src/main/resources/%E5%85%AC%E5%BC%8F%E6%8E%A8%E5%AF%BC.md

從下圖可以看出，重試次數(shù)n較大時(shí)（比如8），乘數(shù) M 的細(xì)微變化都會(huì)導(dǎo)致，任務(wù)的間隔時(shí)間發(fā)生劇烈變化，因此n超過(guò)8之后，M基本不可調(diào)。

同樣的，從下圖可以看到，乘數(shù)M較大時(shí)（比如4），n的細(xì)微變化也會(huì)導(dǎo)致任務(wù)的間隔時(shí)間爆發(fā)式的增加。

1、乘數(shù)在1.5-4 的合理性

過(guò)小乘數(shù) (<1.5) 的問(wèn)題：

當(dāng)乘數(shù) = 1.2，重試 10 次的間隔時(shí)間是：1次:1, 2次:1.2, 3次:1.44, ..., 10次:5.16，

10 次重試總間隔僅 5 倍，接近固定間隔，可能導(dǎo)致 "驚群效應(yīng)"（大量請(qǐng)求同時(shí)重試）。

過(guò)大乘數(shù) (>4) 的問(wèn)題

當(dāng)乘數(shù) = 8，重試 5 次的間隔時(shí)間：1次:1, 2次:8, 3次:64, 4次:512, 5次:4096

5 次重試后間隔已超 1 小時(shí)（假設(shè)初始間隔時(shí)間是最小的1s，4096s>1小時(shí)），可能導(dǎo)致請(qǐng)求長(zhǎng)時(shí)間等待，用戶體驗(yàn)差。

因此，乘數(shù) = 1.5-4 在 "退避效率" 和 "資源消耗" 間取得平衡，一般取乘數(shù)= 2 （標(biāo)準(zhǔn)指數(shù)退避）。

行業(yè)實(shí)踐：AWS SDK 默認(rèn)乘數(shù) = 2，Google gRPC 重試策略推薦乘數(shù) = 1.5-3，多數(shù) HTTP 客戶端庫(kù) (如 requests) 默認(rèn)乘數(shù) = 2。

2、最大重試次數(shù)3-10的合理性

假設(shè)單次重試成功概率為P（比如網(wǎng)絡(luò)/服務(wù)臨時(shí)故障，重試成功概率通常較高），重試 n次至少成功 1 次的概率為：

當(dāng) p=0.5，（單次重試 50% 成功概率）：

n=3 時(shí)，成功概率 =1?(0.5)^3=87.5%

n=5 時(shí)，成功概率 =1?(0.5)^5=96.875%

n=10 時(shí)，成功概率 =1?(0.5)^10≈99.9%

實(shí)際場(chǎng)景中，臨時(shí)故障的單次成功概率遠(yuǎn)高于 50%（比如網(wǎng)絡(luò)抖動(dòng)重試成功概率可能達(dá) 80%）

若 p=0.8，n=3時(shí)成功概率已達(dá) 1?0.2^3=99.2%幾乎覆蓋所有臨時(shí)故障。

因此，3 - 10 次重試，能以極高概率（99%+）覆蓋“臨時(shí)故障”場(chǎng)景，再增加次數(shù)對(duì)成功概率提升極有限（邊際效應(yīng)遞減）。

因?yàn)橐阎娜蝿?wù)延遲時(shí)間的公式是：

，

n從1到C進(jìn)行累加得到總耗時(shí):

，

根據(jù)等比數(shù)列求和公式可以得到：

令 M=2（常用乘數(shù)），F(xiàn)=1 秒（最小可能值）：

n=3時(shí)，T=（2^3-1）/（2-1）=7秒

n=5時(shí)，T=(2^5-1)/(2-1)=31秒

n=10時(shí)，T=2^10-1=1023秒≈17分鐘

n=13時(shí)，T=2^13-1≈2.3小時(shí)

n=15時(shí)，T=2^15-1≈9.1小時(shí)

當(dāng)n超過(guò)10后，每次增加都會(huì)導(dǎo)致總耗時(shí)急劇增長(zhǎng)，很容易超過(guò)業(yè)務(wù)的容忍上限（具體業(yè)務(wù)具體分析），也可能因?yàn)橹卦囘^(guò)多，導(dǎo)致被調(diào)用的系統(tǒng)壓力增加，甚至造成系統(tǒng)崩潰。

故：3 - 10 次重試可將總耗時(shí)控制在“業(yè)務(wù)可接受范圍”（幾秒到十幾分鐘），同時(shí)避免資源過(guò)載。

行業(yè)實(shí)踐：Kafka 消費(fèi)者重試：默認(rèn) 10 次、Redis 客戶端重試：默認(rèn) 5 次、Hadoop 任務(wù)重試：默認(rèn) 3-5 次、RFC 建議：RFC 6582（HTTP 重試）建議：3-5 次重試。

3、最佳實(shí)踐速查表

三、經(jīng)驗(yàn)沉淀：異常重試機(jī)制的設(shè)計(jì)原則?

通過(guò)這次實(shí)踐和對(duì)行業(yè)方案的研究，我們總結(jié)出異常重試機(jī)制設(shè)計(jì)的四大核心原則：?

1.動(dòng)態(tài)適應(yīng)性原則：重試策略應(yīng)支持參數(shù)化配置，根據(jù)業(yè)務(wù)場(chǎng)景和系統(tǒng)負(fù)載動(dòng)態(tài)調(diào)整重試間隔和次數(shù)，避免 “一刀切” 的重試策略對(duì)系統(tǒng)造成沖擊。?

2.冪等性保障原則：確保任務(wù)在多次重試過(guò)程中不會(huì)產(chǎn)生重復(fù)數(shù)據(jù)或副作用，通過(guò)唯一標(biāo)識(shí)、狀態(tài)機(jī)等技術(shù)手段，實(shí)現(xiàn)任務(wù)的冪等執(zhí)行。?

3.故障隔離原則：將重試邏輯與業(yè)務(wù)邏輯分離，通過(guò)消息隊(duì)列、異步調(diào)度等方式，降低重試操作對(duì)主線程的影響，避免因重試失敗導(dǎo)致系統(tǒng)整體崩潰。?

4.可觀測(cè)性原則：建立完善的監(jiān)控和告警體系，實(shí)時(shí)追蹤任務(wù)重試狀態(tài)，在達(dá)到最大重試次數(shù)時(shí)及時(shí)發(fā)出告警，便于運(yùn)維人員快速定位和解決問(wèn)題。?

四、結(jié)語(yǔ)：以技術(shù)沉淀筑牢大促防線?

這次線上異常事件，猶如一面鏡子，讓我們清晰地看到了系統(tǒng)中的潛在風(fēng)險(xiǎn)，也為我們提供了一次寶貴的技術(shù)提升機(jī)會(huì)。通過(guò)對(duì)異常重試機(jī)制的深入研究和實(shí)踐，我們不僅解決了當(dāng)前問(wèn)題，更將這些經(jīng)驗(yàn)轉(zhuǎn)化為團(tuán)隊(duì)的技術(shù)資產(chǎn)。在未來(lái)的 618 大促及其他關(guān)鍵業(yè)務(wù)場(chǎng)景中，我們將以更完善的技術(shù)方案、更嚴(yán)謹(jǐn)?shù)脑O(shè)計(jì)原則，守護(hù)系統(tǒng)的穩(wěn)定運(yùn)行，為業(yè)務(wù)發(fā)展提供堅(jiān)實(shí)的技術(shù)保障。

?審核編輯 黃宇