來著csdn 麵包君123
方案1：統一的定時任務，每隔1分鐘執行一次。
缺點：每隔一分鐘處理一次，過於頻繁的請求，增加服務器的負擔。並且會有1分鐘的誤差，因為定時任務設置每隔1分鐘執行一次。
優點：實現簡單
方案2：利用mq的延遲發送特性處理+一個定時任務統一處理失敗的單子
下單後，發送一條消息給mq，並設置mq，30分鐘後再處理發送消息動作
優點：時間準確性相對高，一個單子只執行一次，併發高。
缺點：1.當大量消息堆積的時候，同樣存在延遲的問題。同時還可能存在消息丟失風險。（rocketmq號稱0丟失）
2.基本上的mq，都是默認不開啟延遲發送的，需要開啟mq延遲發送功能，且會增加mq的一部分性能負擔。
方案3：利用redis的過期key特性處理+一個定時任務統一處理失敗的單子
優點：時間準確性相對高，一個單子只執行一次
缺點：1，消息只發送一次，不管有沒有處理成功。
2，當很多key同時過期時，存在延遲問題。
3. 當負載多個實例的時候，要保證業務只被執行一次，要保證冪等性，不能重複被執行。
4，redis默認是不開啟這個功能的，需要開啟redis過期key的監聽訂閱，會增加redis的一部分性能負擔。
方案4：30分鐘後處理的定時任務+一個定時任務統一處理失敗的單子
當下單後，新建一個30分鐘後處理的定時任務
優點：時間準確性高，一個單子只執行一次。
缺點：1，需要再新建一個定時任務，刪除處理過，無用的定時任務。
2，併發數，依賴數據庫的併發，以xxjob來舉例，其實是往數據庫插一條定時任務的數據，所以併發受限於數據庫併發數。（需要優化插入的過程，比如如何提高插入速度，或者相應的削峰措施等）
上面四種方案，筆者認為在併發度不是特別高的情況下，第二種（rocketmq優先推薦）和第四種方案為較優方案。
分享到:
閱讀更多 編程小知識 的文章
