場景
一大批文件或者一批消息要推送到另外一個系統。以下以文件爲例，一批文件需要上傳到文件服務器，目前已經有文件表T_FILE裏面存儲了文件路徑等信息。
實現
方案一
文件表T_FILE新增一字段UPLOADSTATUS標識文件是否已經成功上傳。每天0點定時任務，上傳前一天新收到的文件和之前上傳失敗的文件到文件服務器中。對上傳失敗的文件，進行重試操作，每次重試間隔加一個週期(如30min)。
優點：不需要額外的表支持
缺點：任務一次執行，失敗後的重試操作需要的參數都在內存中維護，服務重啓後，需要間隔多個週期執行的任務，全部恢復爲一個週期後執行；同一個文件可能會被多次上傳(如果當天內始終未完成某些文件的上傳，第二天的任務會再次掃描到上傳失敗的文件，重新執行上傳，而前一天的任務也在執行這些文件的上傳)。
方案二
文件表T_FILE新增一字段UPLOADRECORDCREATED（0-未創建 1-已創建）標識文件是否已經在T_FILE_UPLOAD表中創建上傳記錄。
新增一個表T_FILE_UPLOAD來標識文件的上傳狀態等信息，
方案圖示：
啓動兩個任務，
文件上傳任務初始化任務 定時啓動，每天0點執行一次即可，掃描未在T_FILE_UPLOAD創建上傳記錄的數據，插入到T_FILE_UPLOAD表中，初始上傳狀態爲未上傳，重試上傳的次數爲0，下次重試上傳的時間爲創建時間即可。任務如果運行失敗，要進行報警通知。
文件上傳執行任務，每隔一段時間(如，30分鐘)啓動一次，掃描文件狀態爲0的，且下次重試上傳的時間小於當前時間的任務，進行文件上傳。成功上傳的文件更新上傳狀態爲成功，失敗的更新重試上傳的次數+1，當前下次重試上傳的時間+重試周期（30分鐘）*重試上傳的次數即可。重試超過10次後，要進行報警通知。
優點：邏輯清晰，實現簡單，與之前業務耦合性低。
缺點：同一個文件可能被重複上傳(本週期上傳一個文件沒有上傳完畢，下一週期又被執行上傳了)。
方案三
方案二基礎上，豐富文件的上傳狀態這一字段，更改爲0-init 1-上傳中 2-上傳成功 3-上傳失敗（也可考慮把上傳失敗的放到另外一個單獨的表裏面，這樣職責更清晰，也更容易處理）。任務每次運行時，對於狀態爲0、3的任務嘗試重新上傳，狀態更新爲1；對於狀態爲1的任務，需要先向接收方查詢狀態，如果明確查詢到狀態爲失敗，則重新嘗試上傳，否則下次繼續查詢，只有明確查詢到狀態爲失敗時，才能重試（如轉賬消息的場景，不能輕易重試，只有明確狀態爲失敗時，才能重試）。
結論
如果同一文件多次上傳時，文件服務器可以根據文件標識等信息識別是否爲同一文件，兼容新增或覆蓋場景，那麼上傳方案無需太關注同一文件的多次上傳問題。採用方案二即可。
如果文件服務器或者消息接收方要求不能重複推送文件或推送消息，或者業務不能重複推送消息，則採用方案三。
其他需要考慮的問題
- 任務的分佈式調度
- 推送失敗報警（任務生成失敗報警，重試次數超閾值報警）
- 安全機制，申請接入通知文件上傳模塊（或通知模塊）