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