分布式定時任務排程系統

一：我們先思考下面幾個業務場景的解決方案:

-  支付系統每天淩晨1點跑批，進行一天清算，每月1号進行上個月清算

-  淘寶整點搶購，商品價格8點整開始優惠

-  12306購票系統，超過30分鐘沒有成功支付訂單的，進行回收處理

-  商品成功發貨後，需要向客戶發送短信提醒

>類似的業務場景非常多，我們怎麼解決？

二：為什麼我們需要定時任務

    很多業務場景需要我們某一特定的時刻去做某件任務，定時任務解決的就是這種業務場景。一般來說，系統可以使用消息傳遞代替部分定時任務，兩者有很多相似之處，可以互相替換場景。如，上面發貨成功發短信通知客戶的業務場景，我們可以在發貨成功後發送MQ消息到隊列，然後去消費mq消息，發送短信。     但在某些場景下不能互換：     a)時間驅動/事件驅動：内部系統一般可以通過時間來驅動，但涉及到外部系統，則隻能使用時間驅動。如怕取外部網站價格，每小時爬一次     b)批量處理/逐條處理：批量處理堆積的資料更加高效，在不需要實時性的情況下比消息中間件更有優勢。而且有的業務邏輯隻能批量處理。如移動每個月結算我們的話費     c)實時性/非實時性：消息中間件能夠做到實時處理資料，但是有些情況下并不需要實時，比如：vip更新     d)系統内部/系統解耦：定時任務排程一般是在系統内部，而消息中間件可用于兩個系統間

三:任務架構需要考慮的點

單線程或多線程

任務延時時是丢失還是繼續延時

串行還是并行

異常是否影響

四：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

技術難點實作剖析: 實作解析