這個目前的解決方案，多數是quartz。有個spring的定時任務方案，說實話我沒研究明白，而且，網上大量資料指向，它的分布式定時任務也是指向的quartz。一直沒拆對出來功夫研究清楚，或許也反映了乙個問題，就是它太複雜了。我一直是討厭建立資料庫表的，這東西依賴太重。所以，我們這次的方案是使用rabbitmq的延遲佇列來做的。
先說業務概念，為了進行隔離，我們引入了定時任務組(group)的概念，不同組之間是沒有半毛錢關係的，組使用組鍵（group key）來唯一標誌。在組內，存放定時任務(task)，定時任務以定時任務鍵（task key）為唯一標誌，來進行區分。這裡有幾個重點需要解決的問題，我們依次說明：
這個問題，才是這個框架誕生的最終理由。我們如何在多程序的時候可以合理得排程定時任務，讓定時任務的計算可以分散，讓定時任務高可用，同時還不會重複進行。所謂的框架無非就是爭奪和**分發。我們這裡其實採用的是分發的模型，而這個**，我們用的是訊息佇列。目前還沒有進行廣泛的調研，我們這裡選用的是rabbitmq的延遲訊息的功能，不知道其它佇列有沒有。
所謂延遲訊息，並不是訊息本身可以被延遲。而是，訊息佇列可以被配置乙個死信佇列，而訊息在死亡的時候會被轉到死信佇列中。而訊息的其中乙個死亡條件，就是超時，於是就有了這個功能。這樣我們就是用訊息佇列本身對消費者的排程機制，完成了對定時任務執行的分布式排程。當然，這個也有乙個不可避免的缺陷，就是訊息可能會被延遲執行，因為訊息要等上乙個訊息消費完。這個問題，我個人認為目前是小問題，暫時先不考慮，把內容上了再說。
如上所述，我們使用延遲訊息，通過發乙個訊息來開啟乙個定時迴圈，在消費完成後再傳送下次的訊息。那麼這會有乙個問題，如果同乙個定時任務發重了怎麼辦；另乙個問題是，中間斷了怎麼辦。
對於第二個問題，其實最要命的是如何發現，因為只要發現了，重發乙個訊息就是了。但是，如果相信訊息佇列本身的可靠性，這件事情的概率是很小的，我們主要考慮的，還是訊息重複了怎麼辦。
同乙個任務發兩遍，如果我們在啟動應用程式的時候進行初始化，那麼啟動兩次就會有兩個迴圈，而我們現在是沒有任何業務邏輯會清掉迴圈的，這個，就是很大的問題。解決方案其實也問題不大，就是分布式鎖，我們在redis中存入乙個數，發乙個訊息+1，消費乙個訊息-1，以此來控制不重複消費。細緻的邏輯等我寫完了再補充吧。
定時任務排程
在業務複雜的應用程式中，有時候會要求乙個或者多個任務在一定的時間或者一定的時間間隔內計畫進行，比如定時備份或同步資料庫，定時傳送電子郵件等，我們稱之為計畫任務。定時任務排程實現方式 但是1,3可以實現在一定時間執行，2只能實現在一定時間間隔執行。1 thread方式 開啟執行緒 public cla...
Linux定時任務排程
linux定時任務 為當前使用者建立cron服務 1.鍵入 crontab e 編輯crontab服務檔案 例如 檔案內容如下 2 bin sh home admin jiaoben buy deletefile.sh 儲存檔案並並退出 2 bin sh home admin jiaoben buy...
java定時任務排程
預設單執行緒 pom.xml檔案中新增依賴 建立乙個可以被掃瞄到的類，給其中的方法加上 scheduled註解 啟動類中新增 enablescheduled註解 這樣就可以開始定時任務的啟動了。spring schedule中 scheduled註解有如下引數 第一次呼叫執行完後再間隔指定時間 10...