坑爹!Quartz 重複調度問題,你遇到過麼?

作者:Lavender
來源:https://segmentfault.com/a/1190000015492260

1. 引子

公司前期改用quartz做任務調度,一日的調度量均在兩百萬次以上。隨着調度量的增加,突然開始出現job重複調度的情況,且沒有規律可循。網上也沒有說得較爲清楚的解決辦法,於是我們開始調試Quartz源碼,並最終找到了問題所在。

如果沒有耐性看完源碼解析,可以直接拉到文章最末,有直接簡單的解決辦法。
注:本文中使用的quartz版本爲2.3.0,且使用JDBC模式存儲Job。

2. 準備

首先,因爲本文是代碼級別的分析文章,因而需要提前瞭解Quartz的用途和用法,網上還是有很多不錯的文章,可以提前自行了解。

其次,在用法之外,我們還需要了解一些Quartz框架的基礎概念:

1)Quartz把觸發job,叫做fireTRIGGER_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的狀態,主要有以下幾類:
圖2-1 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()方法:

圖3-1 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.javaobtainLock方法的具體實現:

圖3-2 obtainLock方法具體實現

我們通過調試查看expandedSQLexpandedInsertSQL這兩個變量:

圖3-3 expandedSQL和expandedInsertSQL的具體內容

圖3-3可以看出,obtainLock方法通過locks表的一個行鎖(lockName確定)來保證callback方法的事務和線程安全。拿到鎖後,obtainLock方法將lockName寫入threadlocal。當然在releaseLock的時候,會將lockNamethreadlocal中刪除。

總而言之,executeInNonManagedTXLock()方法,保證了在分佈式的情況,同一時刻,只有一個線程可以執行這個方法。

3.2 quartz的調度過程

圖3-4 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實例丟入工作線。

JobRunShellrun()方法,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 調度日誌

由圖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問題,我們看一下這是發生重複調度時的日誌:

圖3-5 重複調度的日誌

在第一步時,也就是quartz在拉取到符合條件的triggers 到將他們的狀態由WAITING改爲ACQUIRED之間停頓了有超過9ms的時間,而另一臺服務器正是趁着這9ms的空檔完成了WAITING-->ACQUIRED-->EXECUTING-->WAITING(也就是一個完整的狀態變化週期)的全部過程,圖示參見圖3-6。

圖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最新版)

2.勁爆!Java 協程要來了。。。

3.Spring Boot 2.x 教程,太全了!

4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這纔是優雅的方式!!

5.《Java開發手冊(嵩山版)》最新發布,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章