在電商系統中，經常有這樣的場景：
訂單下單之后30分鍾后，如果用戶沒有付錢，則系統自動取消訂單。
上述類似的需求是我們經常會遇見的問題。最常用的方法是定期輪訓數據庫，設置狀態。在數據量小的時候並沒有什么大的問題，但是數據量一大輪詢數據庫的方式就會變得特別耗資源。當面對千萬級、上億級數據量時，本身寫入的IO就比較高，導致長時間查詢或者根本就查不出來，更別說分庫分表以后了。除此之外，還有優先級隊列，基於優先級隊列的JDK延遲隊列，時間輪等方式。但如果系統的架構中本身就有RabbitMQ的話，那么選擇RabbitMQ來實現類似的功能也是一種選擇。
如果我們利用RabbitMQ的延遲隊列來實現定時任務，就可以解決以上幾種問題。
那么如何實現呢？
RabbitMQ延遲隊列，主要是借助消息的TTL（Time to Live）和死信exchange（Dead Letter Exchanges）來實現。
1.消息的TTL（Time To Live）
消息的TTL就是消息的存活時間。RabbitMQ可以對隊列和消息分別設置TTL。對隊列設置就是隊列沒有消費者連着的保留時間，也可以對每一個單獨的消息做單獨的設置。超過了這個時間，我們認為這個消息就死了，稱之為死信。如果隊列設置了，消息也設置了，那么會取小的。所以一個消息如果被路由到不同的隊列中，這個消息死亡的時間有可能不一樣（不同的隊列設置）。這里單講單個消息的TTL，因為它才是實現延遲任務的關鍵。可以通過設置消息的expiration字段或者x-message-ttl屬性來設置時間，兩者是一樣的效果。
2.Dead Letter Exchanges
Exchage的概念在這里就不在贅述。一個消息在滿足如下條件下，會進死信路由，記住這里是路由而不是隊列，一個路由可以對應很多隊列。
①.一個消息被Consumer拒收了，並且reject方法的參數里requeue是false。也就是說不會被再次放在隊列里，被其他消費者使用。
②. 上面的消息的TTL到了，消息過期了。
③. 隊列的長度限制滿了。排在前面的消息會被丟棄或者扔到死信路由上。
Dead Letter Exchange其實就是一種普通的exchange，和創建其他exchange沒有兩樣。只是在某一個設置Dead Letter Exchange的隊列中有消息過期了，會自動觸發消息的轉發，發送到Dead Letter Exchange中去。
3.實現延遲隊列
注意：由於隊列的先進先出特性，只有當過期的消息到了隊列的頂端（隊首），才會被真正的丟棄或者進入死信隊列。所以在考慮使用RabbitMQ來實現延遲任務隊列的時候，需要確保業務上每個任務的延遲時間是一致的。如果遇到不同的任務類型需要不同的延時的話，需要為每一種不同延遲時間的消息建立單獨的消息隊列。