作者:Lavender
來源:https://segmentfault.com/a/1190000015492260
1. 引子
公司前期改用quartz做任務調度,一日的調度量均在兩百萬次以上。隨着調度量的增加,突然開始出現job重複調度的情況,且沒有規律可循。網上也沒有說得較爲清楚的解決辦法,於是我們開始調試Quartz源碼,並最終找到了問題所在。
如果沒有耐性看完源碼解析,可以直接拉到文章最末,有直接簡單的解決辦法。
注:本文中使用的quartz版本爲2.3.0,且使用JDBC模式存儲Job。
2. 準備
首先,因爲本文是代碼級別的分析文章,因而需要提前瞭解Quartz的用途和用法,網上還是有很多不錯的文章,可以提前自行了解。
其次,在用法之外,我們還需要了解一些Quartz框架的基礎概念:
1)Quartz把觸發job,叫做fire。TRIGGER_STATE是當前trigger的狀態,PREV_FIRE_TIME是上一次觸發時間,NEXT_FIRE_TIME是下一次觸發時間,misfire是指這個job在某一時刻要觸發,卻因爲某些原因沒有觸發的情況。
2)Quartz在運行時,會起兩類線程(不止兩類),一類用於調度job的調度線程(單線程),一類是用於執行job具體業務的工作池。
3)Quartz自帶的表裏面,本文主要涉及以下3張表:
- triggers表。triggers表裏記錄了,某個trigger的PREV_FIRE_TIME(上次觸發時間),NEXT_FIRE_TIME(下一次觸發時間),TRIGGER_STATE(當前狀態)。雖未盡述,但是本文用到的只有這些。
- locks表。Quartz支持分佈式,也就是會存在多個線程同時搶佔相同資源的情況,而Quartz正是依賴這張表,處理這種狀況,至於如何做到,參見3.1。
- fired_triggers表,記錄正在觸發的triggers信息。
4)TRIGGER_STATE,也就是trigger的狀態,主要有以下幾類:
trigger的初始狀態是WAITING,處於WAITING狀態的trigger等待被觸發。調度線程會不停地掃triggers表,根據NEXT_FIRE_TIME提前拉取即將觸發的trigger,如果這個trigger被該調度線程拉取到,它的狀態就會變爲ACQUIRED。
因爲是提前拉取trigger,並未到達trigger真正的觸發時刻,所以調度線程會等到真正觸發的時刻,再將trigger狀態由ACQUIRED改爲EXECUTING。
如果這個trigger不再執行,就將狀態改爲COMPLETE,否則爲WAITING,開始新的週期。如果這個週期中的任何環節拋出異常,trigger的狀態會變成ERROR。如果手動暫停這個trigger,狀態會變成PAUSED。
3. 開始排查
3.1分佈式狀態下的數據訪問
前文提到,trigger的狀態儲存在數據庫,Quartz支持分佈式,所以如果起了多個quartz服務,會有多個調度線程來搶奪觸發同一個trigger。mysql在默認情況下執行select 語句,是不上鎖的,那麼如果同時有1個以上的調度線程搶到同一個trigger,是否會導致這個trigger重複調度呢?我們來看看,Quartz是如何解決這個問題的。
首先,我們先來看下JobStoreSupport
類的executeInNonManagedTXLock()
方法:
這個方法的官方介紹:
/**
*Execute the given callback having acquired the given lock.
*Depending on the JobStore,the surrounding transaction maybe
*assumed to be already present(managed).
*
*@param lockName The name of the lock to acquire,for example
*"TRIGGER_ACCESS".If null, then no lock is acquired ,but the
*lockCallback is still executed in a transaction.
*/
也就是說,傳入的callback方法在執行的過程中是攜帶了指定的鎖,並開啓了事務,註釋也提到,lockName就是指定的鎖的名字,如果lockName是空的,那麼callback方法的執行不在鎖的保護下,但依然在事務中。
這意味着,我們使用這個方法,不僅可以保證事務,還可以選擇保證,callback方法的線程安全。
接下來,我們來看一下executeInNonManagedTXLock(…)
中的obtainLock(conn,lockName)
方法,即搶鎖的過程。這個方法是在Semaphore
接口中定義的,Semaphore
接口通過鎖住線程或者資源,來保護資源不被其他線程修改,由於我們的調度信息是存在數據庫的,所以現在查看DBSemaphore.java
中obtainLock
方法的具體實現:
我們通過調試查看expandedSQL
和expandedInsertSQL
這兩個變量:
圖3-3可以看出,obtainLock
方法通過locks表的一個行鎖(lockName確定)來保證callback方法的事務和線程安全。拿到鎖後,obtainLock
方法將lockName
寫入threadlocal
。當然在releaseLock
的時候,會將lockName
從threadlocal
中刪除。
總而言之,executeInNonManagedTXLock()
方法,保證了在分佈式的情況,同一時刻,只有一個線程可以執行這個方法。
3.2 quartz的調度過程
QuartzSchedulerThread
是調度線程的具體實現,圖3-4 是這個線程run()
方法的主要內容,圖中只提到了正常的情況下,也就是流程中沒有出現異常的情況下的處理過程。由圖可以看出,調度流程主要分爲以下三步:
1)拉取待觸發trigger:
調度線程會一次性拉取距離現在,一定時間窗口內的,一定數量內的,即將觸發的trigger信息。那麼,時間窗口和數量信息如何確定呢,我們先來看一下,以下幾個參數:
idleWaitTime
: 默認30s,可通過配置屬性org.quartz.scheduler.idleWaitTime
設置。availThreadCount
:獲取可用(空閒)的工作線程數量,總會大於1,因爲該方法會一直阻塞,直到有工作線程空閒下來。maxBatchSize
:一次拉取trigger的最大數量,默認是1,可通過org.quartz.scheduler.batchTriggerAcquisitionMaxCount
改寫batchTimeWindow
:時間窗口調節參數,默認是0,可通過org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow
改寫misfireThreshold
: 超過這個時間還未觸發的trigger,被認爲發生了misfire,默認60s,可通過org.quartz.jobStore.misfireThreshold
設置。
調度線程一次會拉取NEXT_FIRE_TIME小於(now + idleWaitTime +batchTimeWindow
),大於(now - misfireThreshold
)的,min(availThreadCount,maxBatchSize)
個triggers,默認情況下,會拉取未來30s,過去60s之間還未fire的1個trigger。隨後將這些triggers的狀態由WAITING改爲ACQUIRED,並插入fired_triggers表。
2)觸發trigger:
首先,我們會檢查每個trigger的狀態是不是ACQUIRED,如果是,則將狀態改爲EXECUTING,然後更新trigger的NEXT_FIRE_TIME,如果這個trigger的NEXT_FIRE_TIME爲空,也就是未來不再觸發,就將其狀態改爲COMPLETE。如果trigger不允許併發執行(即Job的實現類標註了@DisallowConcurrentExecution
),則將狀態變爲BLOCKED,否則就將狀態改爲WAITING。
3)包裝trigger,丟給工作線程池:
遍歷triggers,如果其中某個trigger在第二步出錯,即返回值裏面有exception或者爲null,就會做一些triggers表,fired_triggers表的內容修正,跳過這個trigger,繼續檢查下一個。否則,則根據trigger信息實例化JobRunShell
(實現了Thread接口),同時依據JOB_CLASS_NAME
實例化Job
,隨後我們將JobRunShell
實例丟入工作線。
在JobRunShell
的run()
方法,Quartz會在執行job.execute()
的前後通知之前綁定的監聽器,如果job.execute()
執行的過程中有異常拋出,則執行結果jobExEx
會保存異常信息,反之如果沒有異常拋出,則jobExEx
爲null。然後根據jobExEx
的不同,得到不同的執行指令instCode
。
JobRunShell
將trigger信息,job信息和執行指令傳給triggeredJobComplete()
方法來完成最後的數據表更新操作。例如如果job執行過程有異常拋出,就將這個trigger狀態變爲ERROR,如果是BLOCKED狀態,就將其變爲WAITING等等,最後從fired_triggers表中刪除這個已經執行完成的trigger。注意,這些是在工作線程池異步完成。
3.3 排查問題
在前文,我們可以看到,Quartz的調度過程中有3次(可選的)上鎖行爲,爲什麼稱爲可選?因爲這三個步驟雖然在executeInNonManagedTXLock
方法的保護下,但executeInNonManagedTXLock
方法可以通過設置傳入參數lockName爲空,取消上鎖。在翻閱代碼時,我們看到第一步拉取待觸發的trigger時:
public List<OperableTrigger> acquireNextTriggers(final long noLaterThan, final int maxCount, final long timeWindow)throws JobPersistenceException {
String lockName;
//判斷是否需要上鎖
if (isAcquireTriggersWithinLock() || maxCount > 1) {
lockName = LOCK_TRIGGER_ACCESS;
} else {
lockName = null;
}
return executeInNonManagedTXLock(lockName,
new TransactionCallback<List<OperableTrigger>>(){
public List<OperableTrigger> execute(Connection conn) throws JobPersistenceException {
return acquireNextTrigger(conn, noLaterThan, maxCount, timeWindow);
}
}, new TransactionValidator<List<OperableTrigger>>() {
//省略
});
}
在加鎖之前對lockName做了一次判斷,而非像其他加鎖方法一樣,默認傳入的就是LOCK_TRIGGER_ACCESS:
public List<TriggerFiredResult> triggersFired(final List<OperableTrigger> triggers) throws JobPersistenceException {
//默認上鎖
return executeInNonManagedTXLock(LOCK_TRIGGER_ACCESS,
new TransactionCallback<List<TriggerFiredResult>>() {
//省略
},new TransactionValidator<List<TriggerFiredResult>>() {
//省略
});
}
通過調試發現isAcquireTriggersWithinLock()
的值是false
,因而導致傳入的lockName是null。我在代碼中加入日誌,可以更清楚的看到這個過程。
由圖3-5可以清楚看到,在拉取待觸發的trigger時,默認是不上鎖。如果這種默認配置有問題,豈不是會頻繁發生重複調度的問題?而事實上並沒有,原因在於Quartz默認採取樂觀鎖,也就是允許多個線程同時拉取同一個trigger。我們看一下Quartz在調度流程的第二步fire trigger的時候做了什麼,注意此時是上鎖狀態:
protected TriggerFiredBundle triggerFired(Connection conn, OperableTrigger trigger)
throws JobPersistenceException {
JobDetail job;
Calendar cal = null;
// Make sure trigger wasn't deleted, paused, or completed...
try { // if trigger was deleted, state will be STATE_DELETED
String state = getDelegate().selectTriggerState(conn,trigger.getKey());
if (!state.equals(STATE_ACQUIRED)) {
return null;
}
} catch (SQLException e) {
throw new JobPersistenceException("Couldn't select trigger state: "
+ e.getMessage(), e);
}
調度線程如果發現當前trigger的狀態不是ACQUIRED,也就是說,這個trigger被其他線程fire了,就會返回null。在3.2,我們提到,在調度流程的第三步,如果發現某個trigger第二步的返回值是null,就會跳過第三步,取消fire。在通常的情況下,樂觀鎖能保證不發生重複調度,但是難免發生ABA問題,我們看一下這是發生重複調度時的日誌:
在第一步時,也就是quartz在拉取到符合條件的triggers 到將他們的狀態由WAITING改爲ACQUIRED之間停頓了有超過9ms的時間,而另一臺服務器正是趁着這9ms的空檔完成了WAITING-->ACQUIRED-->EXECUTING-->WAITING(也就是一個完整的狀態變化週期)的全部過程,圖示參見圖3-6。
3.4 解決辦法
如何去解決這個問題呢?在配置文件加上org.quartz.jobStore.acquireTriggersWithinLock=true
,這樣,在調度流程的第一步,也就是拉取待即將觸發的triggers時,是上鎖的狀態,即不會同時存在多個線程拉取到相同的trigger的情況,也就避免的重複調度的危險。
3.5 心得
此次排查過程並非一帆風順,走過一些坑,也有一些非技術相關的體會:
1)學習是一個需要不斷打磨,修正的能力。就我個人而言,爲了學Quartz,剛開始去翻一個2.4MB大小的源碼是毫無頭緒,並且效率低下的,所以立刻轉換方向,先了解這個框架的運行模式,在做什麼,有哪些模塊,是怎麼做的,再找主線,翻相關的源碼。之後在一次次使用中,碰到問題再翻之前沒看的源碼,就越來越順利。
之前也聽過其他同事的學習方法,感覺並不完全適合自己,可能每個人狀態經驗不同,學習方法也稍有不同。在平時的學習中,需要去感受自己的學習效率,參考建議,嘗試,感受效果,改進,會越來越清晰自己適合什麼。這裏很感謝我的師父,用簡短的話先幫我捋順了調度流程,這樣我再看源碼就不那麼喫力了。
2)要質疑“經驗”和“理所應當”,慣性思維會矇住你的雙眼。在大規模的代碼中很容易被習慣迷惑,一開始,我們看到上鎖的那個方法的時候,認爲這個上鎖技巧很棒,這個方法就是爲了解決併發的問題,“應該”都上鎖了,上鎖了就不會有併發的問題了,怎麼可能幾次與數據庫的交互都上鎖,突然某一次不上鎖呢?直到看到拉取待觸發的trigger方法時,覺得有絲絲不對勁,打下日誌,才發現實際上是沒上鎖的。
3)日誌很重要。雖然我們可以調試,但是沒有日誌,我們是無法發現並證明,程序發生了ABA問題。
4)最重要的是,不要害怕問題,即使是Quartz這樣大型的框架,解決問題也不一定需要把2.4MB的源碼通通讀懂。只要有時間,問題都能解決,只是好的技巧能縮短這個時間,而我們需要在一次次實戰中磨練技巧。
近期熱文推薦:
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這纔是優雅的方式!!
覺得不錯,別忘了隨手點贊+轉發哦!