定時任務：
schedule與apscheduler與celery
量級： schedule < apscheduler < celery
三者都支持定時任務配置：
-- schedule相當於linux下的crontab，使用最簡單，但不支持動態添加任務和任務實例化，所以在實際項目中使用不多。
-- apschedule解決了schedule的不足，項目中定時任務使用最多
-- celery 的功能強點在異步隊列，定時功能只是一個附加功能，如果只為定時而使用celery則太過笨重，殺雞用牛刀。
想想定時任務需支持的幾個關鍵點：
1.觸發方式: 按照特定頻率/特定時間
2.調度方法：阻塞/非阻塞/異步
3.任務的實例化，為什么實例化？具體使用看應用場景：
-- 如果重啟了一切重來，就按照默認的任務存內存，簡單高效；
-- 當程序崩潰或應用重啟時，還需要保持定時任務的正常流程，比如（程序A每兩個小時運行一次，10點運行了，11點應用重啟，那么還會維持下次在12點執行，因為任務的調度已經實例化到數據庫），
實例化的時候又要考慮，任務重復添加到數據庫的問題，不急。有相關配置，是替換還是繼續添加，追加就會存在同時有多個任務同時進行。
4.任務的執行，是采用多線程還是多進程？看你是CPU密集型還是IO密集型，如果是后者就沒必要浪費進程數了，也可以二者結合使用。
當任務未執行完畢，下次調度又觸發了，是要多個一起執行還是只保留一個實例，或配置實現可以最多運行n個實例？
5.異常，當發生異常時如何第一時間知道
celery：
作為一個異步隊列，可以支持高並發，如百萬級別。當項目啟動時，遇到celery的 delay方法時，程序會直接跳過然后將該方法加入到配置的消息中間件（broker，如redis，rabbitMQ）中。
而啟動的worker則會進行消費任務。
集群與分布式：
集群是不同的機器運行相同的代碼，處理相同的事情，比如兩個廚師同時炒菜
分布式是不同的機器做不同的事，相互協作。比如廚師和切菜師