先說說 ax 是怎么來的。它不是拍腦袋造出來的輪子而是被一堆定時(shí)任務(wù)和失敗重試的問題逼出來的內(nèi)部項(xiàng)目。當(dāng)時(shí)我手上有一個(gè)數(shù)據(jù)平臺(tái)跑著大量同步、緩存刷新、報(bào)表生成、IoT 指令下發(fā)之類的活一開始全用 cron 頂著上了集群之后才發(fā)現(xiàn)cron 根本回答不了這幾個(gè)問題同一時(shí)刻到底該哪臺(tái)機(jī)器執(zhí)行機(jī)器掛了任務(wù)誰來接管執(zhí)行失敗了要不要重試、怎么重試ax 調(diào)度這個(gè)內(nèi)部代號(hào)指的就是為了解決這些問題而做的一套輕量調(diào)度內(nèi)核。這篇文章把我從需求梳理、模型選型、核心實(shí)現(xiàn)到踩坑排查的完整過程寫下來給正在考慮自研調(diào)度器、或者單純想搞懂調(diào)度底層原理的朋友一個(gè)參考。1. 為什么會(huì)出現(xiàn) ax 這個(gè)調(diào)度引擎先交代清楚項(xiàng)目從哪來這部分決定了后面所有設(shè)計(jì)決策不看背景直接看代碼容易產(chǎn)生為什么要做這么復(fù)雜的誤解。1.1 業(yè)務(wù)場(chǎng)景里定時(shí)任務(wù)到底缺什么在我們的業(yè)務(wù)里典型任務(wù)長這樣每天凌晨 2 點(diǎn)同步一次訂單數(shù)據(jù)到數(shù)倉每 5 分鐘刷新一次熱點(diǎn)商品的本地緩存每小時(shí)生成一份經(jīng)營報(bào)表每分鐘向一批智能設(shè)備下發(fā)控制指令。單機(jī)單實(shí)例的時(shí)候crontab完全夠用寫幾行配置、配個(gè)日志輪轉(zhuǎn)問題就結(jié)束了。但服務(wù)一上集群語義立刻變了。首先是重復(fù)執(zhí)行兩臺(tái)機(jī)器同時(shí)從配置中心拉到了同一批任務(wù)到了觸發(fā)時(shí)間各自執(zhí)行一遍緩存刷新這種冪等操作還好數(shù)據(jù)同步、訂單推送這種操作就會(huì)出現(xiàn)重復(fù)寫入嚴(yán)重時(shí)直接把對(duì)端系統(tǒng)打掛。其次是無人接管某臺(tái)機(jī)器宕機(jī)后它身上掛著的任務(wù)在它重啟之前永遠(yuǎn)不會(huì)再被觸發(fā)除非人工介入。再一個(gè)是失敗無補(bǔ)償任務(wù)執(zhí)行到一個(gè)中間步驟拋異常cron 只能記一行日志然后等下個(gè)周期但很多任務(wù)需要馬上重試、需要退避、需要告警。這些問題的本質(zhì)是時(shí)間觸發(fā)只是調(diào)度最表層的功能真正的調(diào)度是分布式環(huán)境下對(duì)任務(wù)歸屬、執(zhí)行狀態(tài)和失敗補(bǔ)償?shù)墓芾?。理解了這一點(diǎn)后面設(shè)計(jì)狀態(tài)機(jī)、冪等、分布式鎖的時(shí)候就不會(huì)覺得小題大做。1.2 為什么沒有直接套用現(xiàn)成的開源調(diào)度框架不少朋友聽到自研調(diào)度的第一反應(yīng)是有病吧XX 不香嗎。我承認(rèn)成熟框架功能全、社區(qū)大、文檔多但它解決不了我們的三個(gè)實(shí)際問題。第一是太重。我們有一部分服務(wù)要部署在邊緣節(jié)點(diǎn)上設(shè)備內(nèi)存很小平時(shí)只跑一個(gè)輕量 Agent塞進(jìn)一個(gè)完整調(diào)度框架的客戶端和依賴光依賴沖突就能折騰一整天。我們需要的是一個(gè)可以被裁剪的內(nèi)核邊緣節(jié)點(diǎn)只保留注冊(cè)、觸發(fā)、執(zhí)行、回報(bào)四條鏈路中心節(jié)點(diǎn)才啟用完整的重試、鎖、狀態(tài)機(jī)能力。第二是線程模型不透明。調(diào)度框架為了通用性線程池、隊(duì)列策略、鎖實(shí)現(xiàn)往往是黑盒。真到了線上任務(wù)積壓、延遲飆升的時(shí)候你只能去論壇翻 issue沒法直接通過代碼判斷瓶頸在哪。自研之后整個(gè)線程模型長什么樣我們心里有數(shù)出問題能直接看源碼定位。第三是學(xué)習(xí)成本。為了用好一個(gè)框架團(tuán)隊(duì)需要讀一遍它的架構(gòu)設(shè)計(jì)、配置項(xiàng)和故障排查手冊(cè)這成本遠(yuǎn)比寫一個(gè)夠用的調(diào)度內(nèi)核高。當(dāng)然這里不是勸大家都去自研而是說當(dāng)你的運(yùn)行環(huán)境、資源約束和現(xiàn)成框架的假設(shè)不一致時(shí)自研內(nèi)核是一個(gè)合理選項(xiàng)。ax 也不是一個(gè)完整平臺(tái)它只做調(diào)度引擎不做工作流編排邊界非?？酥啤?.3 命名由來與項(xiàng)目邊界ax 原來的全稱是 Agile eXecutor后來覺得這名字太正經(jīng)就干脆當(dāng)成一個(gè)內(nèi)部代號(hào)沿用下來。項(xiàng)目邊界從一開始就畫得很清楚只做時(shí)間觸發(fā) 狀態(tài)管理 失敗補(bǔ)償不做 DAG 編排、不做分布式事務(wù)、不做 Web 控制臺(tái)。這些能力留給上層業(yè)務(wù)按需搭建。這句話說起來輕巧實(shí)際上非常關(guān)鍵。很多自研項(xiàng)目死在順便把 XX 也做了上邊界一模糊就再也不可能輕量了。ax 的核心鏈路就五環(huán)注冊(cè)任務(wù)、等待觸發(fā)、投遞執(zhí)行、收集結(jié)果、失敗重試。其他一切都要圍繞這五環(huán)不許亂長功能。2. ax 的核心設(shè)計(jì)調(diào)度模型怎么選調(diào)度引擎的靈魂不在代碼而在模型。模型選錯(cuò)了后面每修一個(gè) bug 都是在給錯(cuò)誤決策補(bǔ)窟窿。2.1 調(diào)度模型對(duì)比輪詢、延遲隊(duì)列、時(shí)間輪我最早考慮過三種方案挨個(gè)說下取舍。第一種是數(shù)據(jù)庫輪詢。每隔固定時(shí)間掃描一張任務(wù)表把到期任務(wù)撈出來執(zhí)行。它的優(yōu)點(diǎn)是真的簡單任務(wù)定義、狀態(tài)天然落庫重啟不丟數(shù)據(jù)。缺點(diǎn)也很明顯掃描間隔決定了調(diào)度延遲下限間隔設(shè)置到 1 秒數(shù)據(jù)庫壓力就上來了而且每臺(tái)機(jī)器都掃同一個(gè)表還需要額外做分布式搶鎖把簡單問題復(fù)雜化。這種方案適合任務(wù)量小、秒級(jí)延遲完全無所謂的場(chǎng)景。第二種是延遲隊(duì)列。JDK 自帶的DelayQueue或者用 Redis 的 zset 按執(zhí)行時(shí)間戳排序再起一個(gè)線程不斷取隊(duì)首。延遲精度比數(shù)據(jù)庫輪詢高很多能做到毫秒級(jí)。但它有內(nèi)存或存儲(chǔ)開銷問題而且取出到投遞的過程仍然需要有人盯著隊(duì)首本質(zhì)上還是一個(gè)輪詢只是粒度變細(xì)了。第三種就是時(shí)間輪。它用環(huán)形數(shù)組模擬表盤指針每走一個(gè) tick就把當(dāng)前槽位上的任務(wù)批量取出來。插入和移除的時(shí)間復(fù)雜度都是 O(1)不依賴數(shù)據(jù)庫適合高頻、短延遲的場(chǎng)景。我用一個(gè)餐廳類比來理解它不采用時(shí)間輪的做法是傳菜員拿手機(jī)給每桌設(shè)一個(gè)倒計(jì)時(shí)菜越多越手忙腳亂時(shí)間輪相當(dāng)于把廚房出菜口做成一個(gè)旋轉(zhuǎn)轉(zhuǎn)盤每個(gè)菜做好放到對(duì)應(yīng)的格子轉(zhuǎn)盤轉(zhuǎn)一圈到口的菜自動(dòng)流出來傳菜員只要守著轉(zhuǎn)盤出口就行。ax 最終選了時(shí)間輪作為核心調(diào)度結(jié)構(gòu)但不是全盤取代延遲隊(duì)列——長時(shí)間任務(wù)組合了一個(gè)輔助線程來處理后面 2.2 節(jié)細(xì)講。2.2 時(shí)間輪的工作原理與選型原因時(shí)間輪的本質(zhì)是一個(gè)環(huán)形數(shù)組每個(gè)槽位代表一個(gè)時(shí)間單位槽位上掛著一個(gè)任務(wù)鏈表。假設(shè) tick 是 100 毫秒輪盤有 512 個(gè)槽那么轉(zhuǎn)一圈的時(shí)間是 51.2 秒。指針每一 tick 前進(jìn)一步把當(dāng)前槽位鏈表里的所有任務(wù)取出來逐個(gè)投遞給執(zhí)行線程池。這里有幾個(gè)點(diǎn)必須想清楚。第一任務(wù)延遲超過了輪盤一圈怎么辦兩種常見解決思路一是多級(jí)時(shí)間輪類似水表上的小數(shù)位低層轉(zhuǎn)一圈高層走一格二是記錄圈數(shù)任務(wù)進(jìn)槽位時(shí)帶上還需要轉(zhuǎn)幾圈每圈只做計(jì)數(shù)。ax 用的是更懶但更實(shí)用的方案51.2 秒以內(nèi)的任務(wù)直接進(jìn)時(shí)間輪超過 51.2 秒的定時(shí)任務(wù)放到一個(gè)獨(dú)立的優(yōu)先隊(duì)列里由一個(gè)周期線程負(fù)責(zé)到點(diǎn)后把任務(wù)換算成時(shí)間輪內(nèi)的絕對(duì)時(shí)間再注冊(cè)進(jìn)去。之所以這么設(shè)計(jì)是因?yàn)?90% 的業(yè)務(wù)任務(wù)周期都在分鐘級(jí)到小時(shí)級(jí)用單層時(shí)間輪處理短延遲用輔助隊(duì)列兜底長周期兩套配合代碼量最少心智負(fù)擔(dān)最小。第二個(gè)需要想清楚的是槽位沖突。多個(gè)任務(wù)到期時(shí)間可能落到同一個(gè) tick 里所以槽位上掛鏈表而不是單個(gè)節(jié)點(diǎn)。取出當(dāng)前槽位鏈表后必須先把整個(gè)鏈表摘下來再逐個(gè)執(zhí)行避免執(zhí)行過程中新加入的任務(wù)污染當(dāng)前批次。第三個(gè)是精度與性能的取舍。如果 tick 設(shè)到 10 毫秒理論上調(diào)度延遲更小但 CPU 成本明顯上升因?yàn)槊總€(gè) tick 都要做一次取鏈表、判空、加鎖空轉(zhuǎn)也是開銷。ax 最終定了 100 毫秒 tick實(shí)測(cè)下來覆蓋絕大多數(shù)業(yè)務(wù)沒問題。誰要是跑到秒級(jí)以下實(shí)時(shí)調(diào)度那是實(shí)時(shí)任務(wù)系統(tǒng)的活不該讓調(diào)度引擎硬扛。2.3 任務(wù)狀態(tài)機(jī)設(shè)計(jì)調(diào)度系統(tǒng)最怕狀態(tài)定義模糊。執(zhí)行到一半算不算失敗正在等待重試的任務(wù)被手動(dòng)取消是哪種狀態(tài)這些問題不提前定清楚后續(xù)寫分布式鎖和冪等一定會(huì)亂。ax 把任務(wù)實(shí)例的生命周期定義成下面這張表狀態(tài)含義觸發(fā)動(dòng)作PENDING已注冊(cè)等待觸發(fā)注冊(cè)時(shí)寫入TRIGGERED觸發(fā)時(shí)間到已投遞給執(zhí)行線程時(shí)間輪取出時(shí)寫入RUNNING執(zhí)行器正在執(zhí)行執(zhí)行器啟動(dòng)時(shí)寫入SUCCESS執(zhí)行成功執(zhí)行器回報(bào)時(shí)寫入FAILED執(zhí)行失敗不再重試重試次數(shù)耗盡時(shí)寫入RETRY_WAITING執(zhí)行失敗等待退避重試計(jì)算退避時(shí)間后從 RUNNING 轉(zhuǎn)入CANCELLED手動(dòng)取消取消接口調(diào)用時(shí)寫入每次狀態(tài)變更都會(huì)發(fā)布一個(gè)事件告警模塊訂閱FAILED和RETRY_WAITING監(jiān)控模塊訂閱RUNNING和SUCCESS做耗時(shí)統(tǒng)計(jì)。這里有個(gè)容易踩的坑RETRY_WAITING這個(gè)狀態(tài)必須單獨(dú)存在不能直接把任務(wù)丟回 PENDING否則你無法區(qū)分一個(gè)從沒執(zhí)行過的任務(wù)和一個(gè)失敗后準(zhǔn)備重跑的任務(wù)重試次數(shù)和退避時(shí)間的隔離也就無從談起。3. 核心實(shí)現(xiàn)時(shí)間輪、分發(fā)與執(zhí)行線程這一章直接拆源碼級(jí)別的實(shí)現(xiàn)思路。我不會(huì)貼完整工程但會(huì)把關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和執(zhí)行路徑講清楚照著寫一個(gè)最小可用版本不難。3.1 時(shí)間輪的數(shù)據(jù)結(jié)構(gòu)與推進(jìn)邏輯時(shí)間輪可以用一個(gè)類來表達(dá)核心就三塊數(shù)組槽位、當(dāng)前指針、tick 間隔。簡化版本長這樣public class TimingWheel { private final long tickDurationMs; // 每格時(shí)間固定 100ms private final int ticksPerWheel; // 格子數(shù)量固定 512 private final AtomicInteger currentTick; // 當(dāng)前指針位置 private final Node[] slots; // 環(huán)形數(shù)組 public TimingWheel(long tickDurationMs, int ticksPerWheel) { this.tickDurationMs tickDurationMs; this.ticksPerWheel ticksPerWheel; this.currentTick new AtomicInteger(0); this.slots new Node[ticksPerWheel]; } public void add(long deadlineMs, Task task) { long remainMs deadlineMs - System.currentTimeMillis(); if (remainMs 0) { // 已經(jīng)過期立即投遞 executor.submit(task); return; } int tickOffset (int) (remainMs / tickDurationMs); if (tickOffset ticksPerWheel) { // 超過一輪交給長周期隊(duì)列處理 longQueue.offer(new LongTermTask(deadlineMs, task)); return; } int targetIdx (currentTick.get() tickOffset) % ticksPerWheel; slots[targetIdx].add(task); } public void advance() { int idx currentTick.getAndIncrement() % ticksPerWheel; Node node slots[idx].drain(); while (node ! null) { executor.submit(node.task); node node.next; } } }注意幾個(gè)關(guān)鍵的取舍add里用的是System.currentTimeMillis()去算業(yè)務(wù)上的絕對(duì)到期時(shí)間但advance()的推進(jìn)節(jié)奏不能依賴它否則系統(tǒng)時(shí)鐘被 NTP 調(diào)整時(shí)可能出大問題這個(gè)坑我放到第 5 章細(xì)說。另外取出槽位鏈表用的是drain()不是getAndClear()含義是把當(dāng)前槽位鏈表整體摘下來交給執(zhí)行線程池同時(shí)立即允許新的任務(wù)重新掛到這個(gè)槽位。這樣避免了遍歷執(zhí)行完再還回去過程中的鎖持有可能阻塞調(diào)度線程的問題。3.2 調(diào)度線程與執(zhí)行線程的協(xié)作方式調(diào)度線程是純粹的時(shí)間驅(qū)動(dòng)者它由一個(gè)單線程調(diào)度器驅(qū)動(dòng)每隔 100ms 調(diào)用一次advance()。它的職責(zé)只有一個(gè)把到期的任務(wù)從槽位鏈表搬進(jìn)執(zhí)行線程池的隊(duì)列里絕不親自執(zhí)行任務(wù)。這里的原則是調(diào)度線程永遠(yuǎn)不能阻塞。很多調(diào)度框架延遲增高的原因就是不小心在調(diào)度線程里做了 IO、打了日志、或者同步等待執(zhí)行結(jié)果。ax 在這塊畫了死線調(diào)度線程里禁止拋出業(yè)務(wù)異常任務(wù)投遞動(dòng)作全部走 try-catch即使某個(gè)任務(wù)注冊(cè)時(shí)因?yàn)閰?shù)非法崩了也不能影響同一槽位里其他任務(wù)的投遞。執(zhí)行線程池用的配置我建議這么設(shè)核心線程數(shù)按 CPU 核數(shù)乘 2最大線程數(shù)按核心線程數(shù)的 2 倍隊(duì)列用有界隊(duì)列容量根據(jù)任務(wù)量壓測(cè)來定拒絕策略選CallerRunsPolicy。很多人會(huì)選AbortPolicy覺得任務(wù)太多寧可丟但調(diào)度場(chǎng)景下丟了意味著數(shù)據(jù)同步、緩存刷新、報(bào)表會(huì)缺一次后果比阻塞更嚴(yán)重。CallerRunsPolicy的意思是線程池滿了之后讓調(diào)度線程自己幫忙跑任務(wù)雖然調(diào)度線程會(huì)被拖住短暫時(shí)間但至少任務(wù)不會(huì)丟用微量的延遲換任務(wù)可靠性值得。3.3 重試、冪等與分布式鎖任務(wù)接口我強(qiáng)烈建議返回Result(code, message)而不是裸拋異常。背后的原因很簡單拋異常只能表達(dá)失敗了表達(dá)不了這是可以重試的失敗還是這是業(yè)務(wù)上確定失敗的失敗。比如第三方接口明確返回參數(shù)不合法你再重試一百次也沒用返回 503 超時(shí)重試就有意義。所以任務(wù)結(jié)果至少要帶兩個(gè)字段retryable和message。重試退避我選了指數(shù)退避加噪聲long backoff baseMs * (1L (attempt - 1)) RandomUtils.nextLong(0, 1000);為什么加噪聲因?yàn)槿绻麕资畟€(gè)失敗任務(wù)剛好同時(shí)進(jìn)入重試隊(duì)列第一次退避后它們又會(huì)同時(shí)醒來產(chǎn)生的不是重試而是二次流量高峰。加一個(gè) 0 到 1 秒的隨機(jī)量可以有效打散這批請(qǐng)求。分布式鎖是自研調(diào)度繞不開的一道坎。ax 用的是 Redis setnx 實(shí)現(xiàn)的租約鎖拿到鎖的節(jié)點(diǎn)才允許執(zhí)行任務(wù)。最核心的注意點(diǎn)是鎖必須帶租約時(shí)間租約期間執(zhí)行者必須主動(dòng)續(xù)期。否則出現(xiàn)任務(wù)執(zhí)行耗時(shí)超過租約鎖過期被其他節(jié)點(diǎn)拿走兩個(gè)節(jié)點(diǎn)同時(shí)執(zhí)行同一個(gè)任務(wù)的場(chǎng)景你根本查不出是哪臺(tái)機(jī)器干了兩遍。這個(gè)坑的完整排查過程我放到 5.3 節(jié)。此外每個(gè)任務(wù)實(shí)例生成一個(gè)全局唯一executionId執(zhí)行器寫數(shù)據(jù)時(shí)把這個(gè) ID 落到數(shù)據(jù)庫唯一索引。即便鎖機(jī)制真的出了某種極端問題數(shù)據(jù)庫也會(huì)兜住最后一層防線。分布式系統(tǒng)沒有單點(diǎn)保障必須層層設(shè)防。4. 實(shí)操搭一個(gè)最小可用的 ax 調(diào)度核心講完原理給一套可以直接參考落地的骨架代碼。目標(biāo)是讓讀者看完能跑起一個(gè)最小調(diào)度器并掛上一個(gè)真實(shí)任務(wù)。4.1 核心接口與代碼骨架三個(gè)核心接口缺一不可public interface Job { Result execute(JobContext ctx); } public class JobContext { private String jobName; private String executionId; private long triggerAt; // 以及需要的配置項(xiàng)、日志句柄等 }任務(wù)注冊(cè)請(qǐng)求的定義public class ScheduleRequest { private String jobName; private long triggerAtMs; // 首次觸發(fā)時(shí)間 private long intervalMs; // 周期0 表示單次任務(wù) private int maxRetries; // 最大重試次數(shù) private long retryBaseMs; // 退避基準(zhǔn)時(shí)間 private Job job; // 實(shí)際執(zhí)行邏輯 }這里我把 Job 直接塞進(jìn)請(qǐng)求里是為了演示方便生產(chǎn)環(huán)境建議改為jobName - Job 實(shí)例的注冊(cè)表調(diào)度請(qǐng)求只帶名字和參數(shù)。4.2 注冊(cè)、啟動(dòng)、關(guān)閉流程啟動(dòng)流程三步走初始化時(shí)間輪、初始化執(zhí)行線程池、啟動(dòng)調(diào)度線程。public class AxScheduler { private TimingWheel wheel; private ExecutorService executor; private ScheduledExecutorService scheduler; private MapString, Job jobRegistry; public void start() { wheel new TimingWheel(100, 512); executor new ThreadPoolExecutor( coreSize, maxSize, 60, TimeUnit.SECONDS, new ArrayBlockingQueue(queueSize), new CallerRunsPolicy() ); scheduler.scheduleAtFixedRate(wheel::advance, 0, 100, TimeUnit.MILLISECONDS); } public void register(String name, Job job) { jobRegistry.put(name, job); } public void schedule(ScheduleRequest req) { wheel.add(req.triggerAtMs, () - { JobContext ctx new JobContext(req.jobName, genExecutionId()); // 執(zhí)行前的分布式鎖檢查、狀態(tài)流轉(zhuǎn)觸發(fā) jobRegistry.get(req.jobName).execute(ctx); }); } public void shutdown() { // 第一步停止調(diào)度線程不再產(chǎn)生新觸發(fā) // 第二步等待執(zhí)行中任務(wù)完成帶超時(shí) // 第三步關(guān)閉執(zhí)行線程池 } }關(guān)閉流程是很多人忽視的重災(zāi)區(qū)。直接調(diào)executor.shutdownNow()雖然快但會(huì)把執(zhí)行到一半的數(shù)據(jù)同步任務(wù)硬生生掐斷。ax 的優(yōu)雅關(guān)閉順序是先停調(diào)度線程避免新任務(wù)進(jìn)入再給執(zhí)行線程池一個(gè)寬限期讓它把已投遞的任務(wù)執(zhí)行完寬限期過了還賴著不走的才強(qiáng)制關(guān)閉。同樣的思路要應(yīng)用到長周期輔助線程和狀態(tài)上報(bào)鏈路上。4.3 完整示例緩存預(yù)熱任務(wù)每天凌晨 2 點(diǎn)把熱點(diǎn)商品信息從 MySQL 加載到本地緩存這個(gè)任務(wù)非常適合拿來示范jobRegistry.register(hot-cache-warmup, (ctx) - { ListString hotIds queryHotIdsFromDB(); for (String id : hotIds) { ProductInfo info queryProduct(id); cache.put(product: id, info); } log.info(cache warmup done, count{}, hotIds.size()); return Result.success(); });注冊(cè)調(diào)度請(qǐng)求時(shí)可以這樣寫ScheduleRequest req new ScheduleRequest(); req.jobName hot-cache-warmup; req.triggerAtMs nextTriggerAt(2, 0); // 下一個(gè)凌晨 2 點(diǎn) req.intervalMs 24 * 60 * 60 * 1000L; // 每天一次 req.maxRetries 3; req.retryBaseMs 1000; scheduler.schedule(req);掛上去之后立刻觀察三個(gè)點(diǎn)第一任務(wù)觸發(fā)時(shí)間是否穩(wěn)定在監(jiān)控上畫一條實(shí)際執(zhí)行時(shí)間 - 預(yù)計(jì)算執(zhí)行時(shí)間的差曲線第二執(zhí)行耗時(shí)是否平穩(wěn)突然的耗時(shí)尖峰往往意味著依賴的下游慢了第三失敗重試日志是否正確進(jìn)入RETRY_WAITING狀態(tài)而不是直接消失。這三個(gè)監(jiān)控點(diǎn)如果都正常這個(gè)調(diào)度器就可以開始承接更多任務(wù)了。5. 常見問題與排查技巧實(shí)錄這一章是踩坑實(shí)錄全部來自實(shí)際運(yùn)行中遇到的故障和排查過程按問題出現(xiàn)概率排序。5.1 時(shí)鐘回?fù)芤l(fā)任務(wù)延遲最隱蔽的問題沒有之一?，F(xiàn)象是某天任務(wù)大面積延遲每個(gè)任務(wù)都慢幾十到幾百毫秒偶爾慢到秒級(jí)。第一反應(yīng)查線程池沒滿查時(shí)間輪指針看起來在走。后來才發(fā)現(xiàn)是宿主機(jī)系統(tǒng)時(shí)間被 NTP 服務(wù)往回?fù)芰艘幌聦?dǎo)致所有基于System.currentTimeMillis()的剩余時(shí)間計(jì)算全部錯(cuò)亂。排查過程不算難對(duì)比宿主機(jī)日志里的時(shí)間源和任務(wù)延遲曲線就能發(fā)現(xiàn)。解決方案分兩層第一所有業(yè)務(wù)觸發(fā)時(shí)間計(jì)算仍以墻上時(shí)鐘為準(zhǔn)這是語義需要第二時(shí)間輪推進(jìn)節(jié)奏改用System.nanoTime()計(jì)算 delta它不受系統(tǒng)時(shí)鐘調(diào)整影響保證單調(diào)遞增。這樣即便墻上時(shí)鐘跳了調(diào)度線程本身不會(huì)亂走頂多觸發(fā)時(shí)間整體偏差一次下個(gè)周期自動(dòng)糾正。我還順手加了一個(gè)啟動(dòng)檢查如果時(shí)間輪指針發(fā)生回跳立即告警并自動(dòng)復(fù)位到當(dāng)前時(shí)間對(duì)應(yīng)的槽位。5.2 線程池飽和與任務(wù)堆積第二個(gè)高頻問題是執(zhí)行線程池被占滿表現(xiàn)是任務(wù)延遲開始累積越積越多直達(dá) 10 分鐘以上甚至幾個(gè)小時(shí)。排查的時(shí)候不要先看 CPUCPU 高反而可能是執(zhí)行線程在空轉(zhuǎn)等待下游 IO。正確的排查順序是先看線程池活躍線程數(shù)是否長期等于最大線程數(shù)再看隊(duì)列大小是否持續(xù)增長最后看任務(wù)的執(zhí)行耗時(shí)分布有沒有明顯右移。ax 在這個(gè)問題上加了兩個(gè)保險(xiǎn)。一是執(zhí)行耗時(shí)自動(dòng)打點(diǎn)超過 P95 閾值就記一條慢任務(wù)日志定位是哪個(gè)任務(wù)在拖累整體二是支持對(duì)單個(gè) Job 單獨(dú)配置并發(fā)上限避免某個(gè)慢任務(wù)無限占用公共線程池。這里我再強(qiáng)調(diào)一次CallerRunsPolicy一旦線程池滿了調(diào)度線程被迫幫忙執(zhí)行任務(wù)會(huì)反過來拖慢時(shí)間輪推進(jìn)但這是主動(dòng)選擇的可靠優(yōu)先策略寧可慢不可丟。5.3 分布式重復(fù)執(zhí)行第三次踩坑是在一個(gè)報(bào)表任務(wù)上。這個(gè)任務(wù)平常 2 秒跑完鎖租約設(shè)的 5 秒一直相安無事。某天上游數(shù)據(jù)量暴增任務(wù)執(zhí)行耗時(shí)漲到 8 秒鎖在第 5 秒過期另一個(gè)調(diào)度節(jié)點(diǎn)立刻以任務(wù)無人執(zhí)行為由搶鎖再跑了一遍于是兩份報(bào)表同時(shí)生成下游對(duì)賬對(duì)不上。這個(gè)案例暴露了兩個(gè)問題第一租約不夠長當(dāng)時(shí)只按平時(shí)耗時(shí)的 2.5 倍設(shè)置沒預(yù)留出足夠的波動(dòng)空間第二沒有續(xù)租機(jī)制執(zhí)行者持有鎖期間不會(huì)主動(dòng)給鎖續(xù)期一旦超時(shí)只能眼睜睜被搶。修復(fù)措施是雙重保險(xiǎn)執(zhí)行線程內(nèi)部起一個(gè)租約續(xù)期守護(hù)線程每過租約時(shí)長的一半就續(xù)一次同時(shí)執(zhí)行器寫庫時(shí)帶上executionId唯一索引即使將來鎖機(jī)制再有閃失數(shù)據(jù)庫也會(huì)拒絕第二條重復(fù)寫。這個(gè)案例被團(tuán)隊(duì)當(dāng)作反面教材之后所有任務(wù)上線前都要做一次鎖租約、任務(wù)耗時(shí)的推演。5.4 精度與性能的取舍最后聊一個(gè)不算 bug 的取舍。一開始把 tick 設(shè)成 50ms任務(wù)延遲是低了但 CPU 占用比 100ms 時(shí)高了不少。原因很簡單每個(gè) tick 都要做一次數(shù)組定位、鏈表摘取、并發(fā)安全處理即使大部分槽位是空的這些操作的成本省不掉。后來做了個(gè)對(duì)比壓測(cè)同一批任務(wù)在 50ms tick 和 100ms tick 下的調(diào)度延遲差別大約只有幾十毫秒但 CPU 開銷差了近一倍。于是我默默把 tick 調(diào)回 100ms并且只有一個(gè)特殊業(yè)務(wù)對(duì)觸發(fā)時(shí)間精度要求 20ms 以內(nèi)的實(shí)時(shí)指令下發(fā)單獨(dú)開了一個(gè)細(xì)粒度輪盤跟主輪盤隔離互不干擾。這個(gè)案例說明調(diào)度精度不是一個(gè)可以無限優(yōu)化的指標(biāo)想清楚了業(yè)務(wù)真實(shí)需求再定參數(shù)比盲目調(diào)小 tick 更值得。最后給一點(diǎn)實(shí)際建議。如果你也想寫一個(gè)類似的調(diào)度器不要把精力全花在時(shí)間輪算法上那只是入口。真正決定這個(gè)項(xiàng)目能不能扛住生產(chǎn)壓力的是三件事狀態(tài)一致性、冪等控制、失敗補(bǔ)償。ax 走到今天我自己估算至少有 70% 的調(diào)試時(shí)間都花在任務(wù)到底算成功沒有、到底該不該再執(zhí)行一次這類問題上剩下的才是時(shí)間推算、性能調(diào)優(yōu)和監(jiān)控告警。把這些底子打牢再談?wù){(diào)度精度才有意義。