一個著名的任務調度系統(tǒng)是怎么設計的？
實習生張大胖
這是個代碼寫得很爛的電商系統(tǒng)，只要運行一段時間，服務器就會出現(xiàn)Out Of Memory。
別人都忙得四腳朝天，于是實習生張大胖被抓了壯丁去研究為什么會出現(xiàn)OOM。
剛入行的張大胖技術水平一般，“裝模作樣”地看代碼，研究日志，請教老員工，一個星期過去了，還是一無所獲。
周一例行的項目會議上， 大家似乎要看張大胖的笑話了，沒想到他卻提了一個歪招：“這個OOM問題非常復雜，一時半會兒也解決不了，要不我們定時重啟服務器怎么樣？”
一臉嚴肅的項目經(jīng)理老梁點點頭：“以目前的情況看，也只能如此了。但是不能讓服務中斷，這樣吧，公司有兩臺服務器，一臺在凌晨1點重啟， 另外一臺在凌晨2點重啟。”
得到了領導的首肯，張大胖趕緊行動，周末他其實已經(jīng)做了準備，研究了Linux上的crontab，它的格式是這樣樣子：
每天凌晨一點重啟系統(tǒng)，可以這么寫：
0 1 * * * restart.sh
（碼農翻身注：這里只是個簡單的例子， 實際上crontab及其靈活）
這個OOM的問題被張大胖靈機一動給解決了，或者說，被臨時隱藏了。
crontab達人的煩惱
大家知道張大胖擅長crontab， 都把一些定時的任務扔給他去做： 什么定時統(tǒng)計報表，定時同步數(shù)據(jù)，定時刪除表中的無效訂單...... 等等。
張大胖整天面對的就是crontab和腳本，都快要吐了。
不僅如此，同事們還經(jīng)常提出一些“變態(tài)”的需求：
“大胖，那個定時任務運行得怎么樣了？”
“大胖，我想把那個定時任務給停掉。”
“大胖，那個定時任務今晚別運行?。?rdquo;
“......”
張大胖真是煩死了，他心想，要是提供個界面讓大家使用就好了， 可是crontab似乎并不支持。
要不自己開發(fā)一個？
有一次張大胖偶然發(fā)現(xiàn)了JDK中的Timer類，似乎也是做這些定時任務的， 不由地眼前一亮，但是仔細研究以后就發(fā)現(xiàn)，JDK的Timer還是太簡單了，做點簡單的定時任務還行， 對于復雜的情況，尤其是復雜的時間策略，還是力不從心。
另起爐灶
看來自己需要從頭設計了，張大胖想到了公眾號碼農翻身的一篇文章《一個著名的日志系統(tǒng)是怎么設計出來的？》， 小張用“正交”的原則設計出了Logger, Appender, Formatter這些類。
我也可以使用同樣的原則啊，小張能行，我憑什么不行？
說干就干，先想想需求，非常簡單，不就是定時地執(zhí)行任務嘛！
“任務”應該是正交中的一個“維度”，我可以抽象出一個接口叫做Task ， 嗯，還是叫做Job吧。
對使用者來說，他需要提供一個實現(xiàn)類出來，在實現(xiàn)類中描述要做什么事情，比如：生成報表，復制數(shù)據(jù)......
“定時”該怎么處理？ 定時，定時觸發(fā)，干脆叫做Trigger吧。
這個Trigger 可以指定什么時間開始，時間間隔，運行多少次， 能覆蓋大部分需求了。
可是張大胖轉念一想，如果有人要求類似日歷的重復間隔該怎么處理？ 比如每月的第一天運行，或者每周的最后一天運行，該怎么辦？ crontab特別適合描述這種情況，對，可以搞一個類似于crontab的Trigger。
看來Trigger最好也是個接口，我來提供幾個默認的實現(xiàn)，比如SimpleTrigger，CronTrigger，用戶還可以擴展，這樣就靈活了。
Job和Trigger也是正交的關系， 兩者可以互不影響，可以獨立擴展，真是不錯， 張大胖不僅得意起來，這設計也很簡單嘛！
但是怎么把這兩個家伙結合起來？
必須得有個“大管家”才行，這個大管家應該可以接受Job， 然后按照各種Trigger去運行，嗯，叫做調度器Scheduler應該不錯。
張大胖畫了個草圖，來展示三者之間的關系：
設計得差不多了，可以進入開發(fā)階段了， 因為是自己要寫一個類似于框架的東西，讓別人去使用，張大胖開發(fā)起來非常有激情，即使是利用晚上和周末的時間來寫代碼，也是像打了雞血一樣，根本不覺得累。
一個月過去了，第一版新鮮出爐。
這個版本不僅有核心的API像Job, Trigger, Scheduler ，張大胖還專門開發(fā)了一個界面，用來展示定時任務的進展，例如什么時間運行，運行了幾次，失敗了幾次......等等。
張大胖把它叫做“大胖定時任務調度系統(tǒng)”。
持久化
他興奮地拿去讓項目經(jīng)理老梁看， 可是老梁并不感冒，面無表情地說：“你這個小軟件有啥用啊。”
張大胖被潑了一盆冷水，依然熱情滿滿地推銷：“用了我的這個定時調度系統(tǒng)，任何人都可以輕松地啟動，停止任務， 咱們項目中所有的定時任務一目了然。 大家就不用找我來手工調整了。”
老梁開玩笑地說：“奧，那你的實習工作就可以結束了，哈哈。”
正巧CTO Bill經(jīng)過，他饒有興趣地看了一會，提了一個問題：“假設你這個大胖調度系統(tǒng)在運行的時候，機器突然間Down掉了，怎么處理？”
張大胖一臉懵逼：“什么怎么處理，重啟機器唄。”
Bill 說： “之前的任務還能接著運行嗎，比如說一個任務需要運行100次，在機器down掉之前運行了90次，重啟后能不能從第91次運行？”
張大胖有點發(fā)窘，不好意思地撓撓頭：“這一點我還真沒考慮到，我現(xiàn)在都是在內存中記錄運行的情況，看來得做持久化了。”
Bill 聽到持久化這個詞，知道張大胖已經(jīng)Get到了，他說，你把這個持久化實現(xiàn)了，到時候直接向我匯報。
得到了CTO的賞識，張大胖不敢怠慢，趕緊進行新的設計， 他抽象了一個叫做JobStore的接口，表示Job的存儲，像什么Job，Trigger， Job運行情況都存儲在其中。
下面有兩個實現(xiàn)，分別對應內存存儲和數(shù)據(jù)庫存儲。
雖然SQL是標準的，但是不同的數(shù)據(jù)庫還是有細微的差異， 張大胖覺得得把這些差異給封裝起來， 他又提取了一個接口叫做DriverDelegate， 屏蔽了數(shù)據(jù)庫細節(jié)，讓DbJobStore使用。
他還提供了一個缺省的實現(xiàn)StdJDBCDelegate，如果那些數(shù)據(jù)庫還有獨特的實現(xiàn)，那就寫個子類就行了。
高可用
“大胖定時任務調度系統(tǒng) 2.0” 開發(fā)完成以后，張大胖仔細地想了一遍，似乎沒有什么漏洞了，決定正式向CTO Bill去匯報。
Bill 親切地詢問了張大胖加班加點設計和開發(fā)的情況，對他這種不計較個人得失，一心一意為公司謀福利的精神表示了高度的贊賞。
張大胖受寵若驚。
Bill話鋒一轉：“我們的系統(tǒng)最近用戶越來越多，老板特別提出了高可用的需求，系統(tǒng)的各個組件也得達到高可用！”
“高可用？ 拿我的定時調度系統(tǒng)來說，就是說可以部署在多個機器上，一個down掉了，其他的還可以運行，對吧？” 張大胖一點就透。
Bill 贊許地點點頭：“你想好怎么去實現(xiàn)了嗎？”
“很簡單啊，把定時調度系統(tǒng)部署到多個機器上，形成幾個備份就行了！”
張大胖還在白板上畫了這么一個圖：
“那同一個時刻，有多少個Scheduler 在運行？” Bill 終于拋出了重磅炸彈。
張大胖現(xiàn)在明白Bill的疑問了了，三個實例都在運行，那一個Job就有可能運行多次，這肯定是不行的！
他說道：“要不讓三個實例A,B,C都去訪問同一個數(shù)據(jù)庫吧！”
Bill說：“那三個實例訪問同一份數(shù)據(jù)，肯定會出現(xiàn)沖突，互相覆蓋，那就亂套了！”
其實，實例A，實例B，實例C組成一個類似集群的東西，但是同一時刻，一個Job只能在一個實例上運行。
比如Job X 從凌晨1點開始，每隔1小時運行一次，那1:00 的時候Job X可能在實例A上運行， 2:00的時候可能在實例B上運行， 3:00的時候可能在實例C上運行。
也就是說，這三個實例部分地實現(xiàn)了負載均衡。
張大胖說：“這可就難辦了。難道讓這三個實例A,B,C之間互相通信？”
Bill說道：“那樣有點麻煩，就變成一個分布式系統(tǒng)下的通信問題了，我們要不用這個數(shù)據(jù)庫做點文章？ 反正這個數(shù)據(jù)庫已經(jīng)存了Job的信息，Trigger的信息，我們就多加一個表吧，就叫LOCKS，這個表里邊每一行記錄都可以當做一個‘鎖’來用。”
張大胖表示不太明白。
“很簡單，就是數(shù)據(jù)庫的‘行’鎖嘛， 比如SELECT * FROM LOCKS where LOCK_NAME='TRIGGER' FOR UPDATE ，這就把那一行記錄給鎖住了， 別的事務只能等待當前事務commit以后才能訪問。”
張大胖還是不太明白。
“比如，服務器A的實例A在一個事務中先執(zhí)行了上面SQL, 就把那一行給鎖住了，當服務器B的實例B也去執(zhí)行同樣的SQL的時候， 只能等待，對吧？ 這不就相當于實例A獲得了鎖嗎？”
“原來如此，以后任何一個調度器實例想要獲取Job的運行時間，設置Job的下一次運行時間的時候，都必須先獲得這個鎖。這樣這些分布式的調度器就不會沖突了，只會運行一個特定時間的Job。 我這就去做個詳細設計，再來匯報。”
開源
兩個月后，“大胖定時任務調度系統(tǒng) 3.0” 開發(fā)完畢，在Bill的大力支持和推動下，成功地應用在了公司的項目中。
靈活的設計和擴展性，加上持久化，集群等強大的功能， 系統(tǒng)受到了大家的歡迎。
考慮到很多公司都會有類似的需求，Bill決定把系統(tǒng)開源， 只是“大胖定時任務調度系統(tǒng)”這個名字有點俗，還有點長，Bill把它改名為“Quartz”。
Quartz從此流行開來。
（注：本文試圖講解Quartz的原理，其中的類圖并沒有和Quartz的真實類完全對應，這一點請大家知曉。）
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉載請通過作者微信公眾號coderising獲取授權】
