我們就直接進入正題：
系統的crontab解決不了的幾類問題：
-
任務的時間精度不夠
-
任務管理太臃腫
-
沒法設定任務的截止時間
-
沒有排程功能
-
沒法監控任務的執行情況
-
如果系統出問題，任務可能沒法執行
-
任務間的依賴沒法直接控制
而如果要接入任務排程平臺，會解決掉絕大多數的問題，不過很多人都會有類似的幾個顧慮：
1.如果排程平臺出問題，所有的任務都會失敗，影響巨大
2.一旦遷入平臺，就是一條“不歸路”，除非手工干預調整
3.任務的排程不夠優雅，如果任務多，比如有500個任務，需要在1:00~3:00之間執行，如果合理的規劃任務的執行情況，目前的很多解決方案還做不到靈活的控制和排程。
4.如果出現臨時的維護視窗，系統的crontab和平臺的排程任務都是整段垮掉。
所以說，任務排程有很多的痛點，也有解決這個問題的價值，這個問題具有通用性，而且結合不同的場景可以做針對性的實現。
所以在和同事溝通的過程中，我發現，任務排程其實有很多的亮點可以做，我們換個角色來看，如果你有很多的任務，現在飽受困擾，想遷入平臺，但是感覺不一定可控（尤其網路不穩定的時候，不是問題的都會成為問題的瓶頸），比較苦惱。
如果我來找你聊一下這個事情，如果我告訴你我們們這麼做好不好：
-
如果系統已有crontab，依然可以繼續使用，接入平臺只是對已有的crontab，把後設資料資訊儲存下來，然後對任務的執行情況做管理，比如檢視執行的任務日誌，任務的執行狀態（加入標示位），我想這對很多人來說，應該是可以接受的，缺點是這麼做，意義不是很大。
-
我們再加一層砝碼，如果在平臺裡支援任務排程，比如使用celery,我們可以無縫的把crontab切換到celery中，那麼這個事情的意義就很明顯了，我們可以選幾個系統crontab做試點，然後逐步開放
-
如果因為網路不穩定等原因，你需要在系統層繼續使用crontab，如果可以由celery的任務直接切換到crontab,那麼這個事情就可以說可控了。
-
如果我們在平臺中修改系統排程任務的時間，系統中的crontab會聯動變化，那麼crontab的維護就會方便許多。
-
如果有500個任務要執行，比如說備份任務，有的資料庫有50G,有的只有500M,如何合理的規劃備份任務，目前很容易看到的一種瓶頸就是瞬間有500個備份任務同時開始，不夠優雅，如果我們可以限定並行度，比如同時執行備份的任務有5個，就會對500臺伺服器做一個統一的排程，分成5組，每組的任務會根據資料量和時間來評估，如果後續需要調整備份任務的並行度，可以擴充套件也可以收縮，那麼這個事情幸福度就大大提高了。
以上幾點，是我對目前的排程任務的一個規劃，目前已經做了原型，其中的核心點和亮點應該是第五條，需要一個通用高效的演算法。
在這個基礎之上，我們能做更多的小細節，比如自動接入crontab,你只需要確認和微調即可。比如我們把任務排程的時間和週期做成視覺化的方式。
裡面的很多思想是和同事聊需求的過程中突然想到的，解決問你題有顧慮，解決了顧慮，那麼問題的價值就很明顯了。
還有就是我想到了Oracle的任務排程，其實已經很成熟了，我們要做的事情其實還是有些類似的。
比如scheduler,Oracle有很專業的設計和實現。
下面這個就是一個排程的設定，很多時間的設定都可以通過視覺化的方式來完成，和業務對接起來就有意義了。
