Quartz.NET 2.x 文件翻譯 - Lesson 10：Configuration, Resource Usage 和 SchedulerFactory

Quartz.NET 2.x 文件翻譯 - Lesson 10：Configuration, Resource Usage 和 SchedulerFactory 檢視官網英文原文

返回目錄

Quartz使用模組化的架構方式，從而使其執行，幾個元件組合在一起，幸運的是有些東西促成了這個組合。

Quartz工作前需要配置好以下主要元件：

1. ThreadPool
2. JobStore
3. DataSources (if necessary)
4. The Scheduler itself

ThreadPool在Quartz執行job任務的時候提供Threads支援，執行緒池執行緒越多，可以同時執行執行的job任務也就越多，但是過多的執行緒可能會使我們的系統變慢。通常來說對於Quartz而言，5個左右的執行緒就已經足夠使用了，因為一般情況下執行的job數少於100個，而且job的執行直接一般不是在同一時間，而且單一job的執行時間也不是很長。也有的時候我們需要10,15,50，甚至更多的執行緒來保證我們執行成千上萬的Trigger並在指定時間執行10-100個job任務。為我們的排程程式池的正確大小完全取決於我們使用的排程程式情況。這沒有固定的規則，我們除了儘量保持儘量小的執行緒數量，還需要保證有足夠的實際來執行我們的job任務。需要注意的是，如果一個Trigger觸發器需要執行了，但是沒有可用的空閒可用執行緒，Quartz就會鎖定（暫停）這個Trigger直到有可用執行緒進行處理，然後這個job任務就會被執行，這就會晚於我們制定的時間點。這樣也有可能導致misfire情況的發生，比如我們在scheduler配置的時候設定“misfire threshold”。

IThreadPool介面定義在Quartz.Spi名稱空間，我們也可以建立IThreadPool介面的實現。有一個執行緒池，叫做Quartz.Simpl.SimpleThreadPool，這個IThreadPool實現是一個固定不變的執行緒設定不增不減，不過即使這樣也是非常強大的，也比較容易測試，因為只要我們使用quartz，都會用到這個執行緒池。

JobStores 和 DataSrouces我們在第九章討論過了，事實上所有的JobStores都是實現了IJobStore介面，但是如果JobStores並不適用於我們的需求和業務，我們也可以自己做的jobstore。

最後，我們需要建立我們的Scheduler例項，但是要有JobStore 和 ThreadPool。

StdSchedulerFactory

StdSchedulerFactory是一個ISchedulerFactory介面的實現，它使用一組屬性（NameValueCollection）來建立和例項化Quartz Scheduler。屬性通常儲存在一個檔案並進行載入，但是也可以由我們的程式建立並傳遞給factory，只是要求在factory呼叫getScheduler()方法來建立一個scheduler，初始化scheduler（及其ThreadPool, JobStore 和 DataSources），然後返回其一個處理程式通過其公共介面。

有一些簡單的配置（包括屬性的描述）在Quartz資料夾的“docs/config”目錄下，我們可以參考Quartz的配置手冊進行處理。

DirectSchedulerFactory

DirectSchedulerFactory是另外一個SchedulerFactory例項，在我們想要程式化建立Scheduler例項的時候需要用到，一般在以下情況使用：
（1）我們需要知道quartz怎麼執行工作等我們需要深入的情況
（2）不允許進行宣告配置

Logging

Quartz.NET使用Common.Logging框架來滿足log需要，Quartz不會產生很多的log資訊，一般是在初始化過程產生log資訊，還有就是那些jog被執行的log資訊，為了保證我們程式的log產生，我們也需要先了解Commmon.Logging框架，具體可以參照Common.Logging的文件。

返回目錄

由龐順龍最後編輯於：3年前

內容均為作者獨立觀點，不代表八零IT人立場，如涉及侵權，請及時告知。