Spring Framework 自帶定時任務，提供了cron表達式來實現豐富定時任務配置。新手推薦使用 / 這個網站來匹配妳的 cron表達式 。
單點的定時服務在目前微服務的大環境下，應用場景越來越局限，所以嘗鮮壹下分布式定時任務吧。
相較於之前兩種方式，這種基於Redis的實現可以通過多點來增加定時任務，多點消費。但是要做好防範重復消費的準備。
將定時任務存放到ZSet集合中，並且將過期時間存儲到ZSet的Score字段中，然後通過壹個循環來判斷當前時間內是否有需要執行的定時任務，如果有則進行執行。
具體實現代碼如下：
適用場景如下：
優勢是：
默認情況下Redis是不開啟鍵空間通知的，需要我們通過 config set notify-keyspace-events Ex 的命令手動開啟。開啟之後定時任務的代碼如下:
Spring會監聽符合以下格式的Redis消息
基於Redis的定時任務能夠適用的場景也比較有限，但實現上相對簡單，但對於功能冪等有很大要求。從使用場景上來說，更應該叫做延時任務。
場景舉例:
優劣勢是：
將定時任務作為單獨的服務，遏制了重復消費，獨立的服務也有利於擴展和維護。
依賴於MySQL，使用相對簡單，可多節點部署，通過競爭數據庫鎖來保證只有壹個節點執行任務。沒有圖形化管理頁面，使用相對麻煩。
依賴於Zookeeper，通過zookeeper的註冊與發現，可以動態的添加服務器。
依賴於Zookeeper，集群部署,可以動態的添加服務器。可以手動增加定時任務，啟動和暫停任務。
國產，依賴於MySQL,基於競爭數據庫鎖保證只有壹個節點執行任務，支持水平擴容。可以手動增加定時任務，啟動和暫停任務。
微服務下，推薦使用xxl-job這壹類組件服務將定時任務合理有效的管理起來。而單點的定時任務有其局限性，適用於規模較小、對未來擴展要求不高的服務。
相對而言，基於spring task的定時任務最簡單快捷，而xxl-job的難度主要體現在集成和調試上。無論是什麽樣的定時任務，妳都需要確保：
中間件可以將服務解耦，但增加了復雜度