分散式定時任務排程系統
阿新 • • 發佈：2019-01-01
一：我們先思考下面幾個業務場景的解決方案:
- 支付系統每天凌晨1點跑批，進行一天清算，每月1號進行上個月清算- 淘寶整點搶購，商品價格8點整開始優惠
- 12306購票系統，超過30分鐘沒有成功支付訂單的，進行回收處理
- 商品成功發貨後，需要向客戶傳送簡訊提醒
>類似的業務場景非常多，我們怎麼解決？
二：為什麼我們需要定時任務
很多業務場景需要我們某一特定的時刻去做某件任務，定時任務解決的就是這種業務場景。一般來說，系統可以使用訊息傳遞代替部分定時任務，兩者有很多相似之處，可以相互替換場景。如，上面發貨成功發簡訊通知客戶的業務場景，我們可以在發貨成功後傳送MQ訊息到佇列，然後去消費mq訊息，傳送簡訊。三:任務框架需要考慮的點
單執行緒或多執行緒任務延時時是丟失還是繼續延時
序列還是並行
異常是否影響
四：java有哪些定時任務的框架
>單機 - timer：是一個定時器類，通過該類可以為指定的定時任務進行配置。TimerTask類是一個定時任務類，該類實現了Runnable介面，缺點異常未檢查會中止執行緒 - ScheduledExecutorService：相對延遲或者週期作為定時任務排程，缺點沒有絕對的日期或者時間 - spring定時框架：配置簡單功能較多，如果系統使用單機的話可以優先考慮spring定時器 優點:簡單缺點:無法高可用，即節點掛了，任務不能跑
>叢集 - Quartz：Java事實上的定時任務標準。但Quartz關注點在於定時任務而非資料，並無一套根據資料處理而定製化的流程。雖然Quartz可以基於資料庫實現作業的高可用，但缺少分散式並行排程的功能
優點:保證高可用，即節點掛了，其它節點仍然可以替代
缺點:同一次任務促發只能一個節點執行，其它節點將不執行任務，效能低，浪費資源
>分佈 - TBSchedule：阿里早期開源的分散式任務排程系統。程式碼略陳舊，使用timer而非執行緒池執行任務排程。眾所周知，timer在處理異常狀況時是有缺陷的。而且TBSchedule作業型別較為單一，只能是獲取/處理資料一種模式。還有就是文件缺失比較嚴重
- elastic-job：噹噹開發的彈性分散式任務排程系統，功能豐富強大，採用zookeeper實現分散式協調，實現任務高可用以及分片，目前是版本2，並且可以支援雲開發
- Saturn：是唯品會自主研發的分散式的定時任務的排程平臺，基於噹噹的elastic-job 版本1開發，並且可以很好的部署到docker容器上，實現正真的彈性
優點:可以實現高可用和高效能，將任務分片，分配到多個節點執行，並且支援彈性伸縮，節點可以動態增加刪除
缺點:複雜，依賴第三方分散式協調元件
五：學習使用 elastic-job
技術難點實現剖析: 實現解析