延遲佇列應用場景：
使用者生成訂單之後，需要過一段時間校驗訂單的支付狀態，如果訂單仍未支付則需要及時地關閉訂單。
使用者註冊成功之後，需要過一段時間比如一周後校驗使用者的使用情況，如果發現使用者活躍度較低，則傳送郵件或者簡訊來提醒使用者使用。
延遲重試。比如消費者從佇列裡消費訊息時失敗了，但是想要延遲一段時間後自動重試。
rabbitmq允許我們為訊息或者佇列設定ttl（time to live），也就是過期時間。ttl表明了一條訊息可在佇列中存活的最大時間，單位為毫秒。也就是說，當某條訊息被設定了ttl或者當某條訊息進入了設定了ttl的佇列時，這條訊息會在經過ttl秒後「死亡」，成為dead letter。如果既配置了訊息的ttl，又配置了佇列的ttl，那麼較小的那個值會被取用。更多資料請查閱官方文件。
剛才提到了，被設定了ttl的訊息在過期後會成為dead letter。其實在rabbitmq中，一共有三種訊息的「死亡」形式：
訊息被拒絕。通過呼叫basic.reject或者basic.nack並且設定的requeue引數為false。
訊息因為設定了ttl而過期。
訊息進入了一條已經達到最大長度的佇列。
如果佇列設定了dead letter exchange（dlx），那麼這些dead letter就會被重新publish到dead letter exchange，通過dead letter exchange路由到其他佇列。更多資料請查閱官方文件。
流程圖聰明的你肯定已經想到了，如何將rabbitmq的ttl和dlx特性結合在一起，實現乙個延遲佇列。
針對於上述的延遲佇列的兩個場景，我們分別有以下兩種流程圖：
延遲消費
延遲消費是延遲佇列最為常用的使用模式。如下圖所示，生產者產生的訊息首先會進入緩衝佇列（圖中紅色佇列）。通過rabbitmq提供的ttl擴充套件，這些訊息會被設定過期時間，也就是延遲消費的時間。等訊息過期之後，這些訊息會通過配置好的dlx**到實際消費佇列（圖中藍色佇列），以此達到延遲消費的效果。
延遲重試
延遲重試本質上也是延遲消費的一種，但是這種模式的結構與普通的延遲消費的流程圖較為不同，所以單獨拎出來介紹。
如下圖所示，消費者發現該訊息處理出現了異常，比如是因為網路波動引起的異常。那麼如果不等待一段時間，直接就重試的話，很可能會導致在這期間內一直無法成功，造成一定的資源浪費。那麼我們可以將其先放在緩衝佇列中（圖中紅色佇列），等訊息經過一段的延遲時間後再次進入實際消費佇列中（圖中藍色佇列），此時由於已經過了「較長」的時間了，異常的一些波動通常已經恢復，這些訊息可以被正常地消費。
RabbitMQ 延遲佇列實現
1 延遲佇列，可以通過rabbitmq自帶機制實現 ttl 死信佇列 通過設定訊息或者佇列的ttl，過期後進行訊息的投遞，從而達到delay的效果 但存在問題 1 設定佇列ttl 同乙個佇列的所有訊息從入佇列到ttl的時間，過期後會投遞到相應死信交換機。這樣如果訊息的過期時間不盡相同，會建立n個不同...
RabbitMQ如何實現延遲佇列？
延遲佇列儲存的物件肯定是對應的延遲訊息，所謂 延遲訊息 是指當訊息被傳送以後，並不想讓消費者立即拿到訊息，而是等待指定時間後，消費者才拿到這個訊息進行消費。場景一 在訂單系統中，乙個使用者下單之後通常有30分鐘的時間進行支付，如果30分鐘之內沒有支付成功，那麼這個訂單將進行一場處理。這是就可以使用延...
使用RabbitMQ實現延遲佇列
在專案中 1.使用者確認乙個訂單,若30分鐘之類沒有支付,則需要取消訂單,若用定時任務去掃瞄訂單表,第一,定時任務時間如何定義,有存在漏掃的風險,第二,訂單表資料龐大,掃瞄表非常消耗效能,這時候該功能可以引入rabbitmq延遲佇列來做 2.某條活動通知在指定的一天推送給使用者,可以用延遲佇列 延遲...