RabbitMQ本身沒有延遲隊列的支持，但是基于其本身的一些特性，可以做到類似延遲隊列的效果：基于死信交換器+TTL。

以下介紹下相關(guān)概念及方法

Dead Letter Exchanges

消息在隊列滿足達到一定的條件，會被認(rèn)為是死信消息（dead-lettered），這時候，RabbitMQ會重新把這類消息發(fā)到另外一個的exchange，這個exchange稱為Dead Letter Exchanges.

以下任一條件滿足，即可認(rèn)為是死信：

• 消息被拒絕消費(basic.reject or basic.nack)并且設(shè)置了requeue=fasle
• 消息的TTL到了（消息過期）
• 達到了隊列的長度限制

需要注意的是，Dead letter exchanges (DLXs) 其實就是普通的exchange，可以和正常的exchange一樣的聲明或者使用。

死信消息路由

隊列中可以設(shè)置兩個屬性：

• x-dead-letter-exchange
• x-dead-letter-routing-key

當(dāng)這個隊列里面的消息成為死信之后，就會投遞到x-dead-letter-exchange指定的exchange中，其中帶著的routing key就是中指定的值x-dead-letter-routing-key。

而如果使用默認(rèn)的exchange(routing key就是希望指定的隊列)，則只需要把x-dead-letter-exchange設(shè)置為空（不能不設(shè)置），類似下面

死信消息的路由則會根據(jù)x-dead-letter-routing-key所指定的進行路由，如果這個值沒有指定，則會按照消息一開始發(fā)送的時候指定的routing key進行路由

Dead-lettered messages are routed to their dead letter exchange either:

with the routing key specified for the queue they were on; or, if this was not set, with the same routing keys they were originally published with.

例如，如果一開始你對exchange X發(fā)送消息，帶著routing key “foo”，進入了隊列 Q然后消息變死信后，他會被重新發(fā)送到 dead letter exchange ，其中發(fā)給dead letter exchange帶著的routing key 還是foo。但如果這個隊列Q本身是設(shè)置了x-dead-letter-routing-key bar， 那么他發(fā)送到 dead letter exchange的時候，帶著的routing key 就是bar。

需要注意的是，當(dāng)死信消息重新路由到新的隊列的時候，在死信目標(biāo)隊列確認(rèn)收到這條死信消息之前，原來隊列的消息是不會刪除的，也就是說在某些異常場景下例如broker突然shutdown，是有機會存在說一個消息既存在于原隊列，又存在于死信目標(biāo)隊列。具體可參考官方說明：

Dead-lettered messages are re-published with publisher confirms turned on internally so, the “dead-letter queues” (DLX routing targets) the messages eventually land on must confirm the messages before they are removed from the original queue. In other words, the “publishing” (the one in which messages expired) queue will not remove messages before the dead-letter queues acknowledge receiving them (see Confirms for details on the guarantees made). Note that, in the event of an unclean broker shutdown, the same message may be duplicated on both the original queue and on the dead-lettering destination queues.

Time-To-Live（TTL）

開頭我們說過，實現(xiàn)延遲隊列除了用死信消息外，還需要利用消息過期的TTL機制，因為只要消息過期了，就會觸發(fā)死信。

RabbitMQ有兩種方法讓設(shè)置消息的TTL：

直接在消息上設(shè)置

byte[] messageBodyBytes = "Hello, world!".getBytes();
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
.expiration("60000")
.build();
channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);

為隊列設(shè)置消息過期TTL

注意，隊列還有一個隊列TTL，x-expires，這個的意思是隊列空置經(jīng)過一段時間（沒有消費者，沒有被重新聲明，沒有人在上面獲取消息（basic.get））后，整個隊列便會過期刪除，不要混淆

如果同時設(shè)置了消息的過期和隊列消息過期屬性，則取兩個較小值。

設(shè)計延遲隊列：

例如，我們需要觸發(fā)一個推送新聞，30分鐘后統(tǒng)計這個新聞的下發(fā)情況，我們就需要一個延遲隊列，新聞推送后，往延遲隊列發(fā)送一個消息，這個隊列的消息在30分鐘后被消費，這時候觸發(fā)即可統(tǒng)計30分鐘的下發(fā)情況。我們可以這樣設(shè)計：

定義一個正常的隊列：ARRIVAL_STAT，統(tǒng)計程序監(jiān)聽此隊列，進行消費。

定義一個“延遲隊列”（RabbitMQ沒有這樣的隊列，這里只是人為的制造一個這樣的隊列）：DELAY_ARRIVAL_STAT，其中設(shè)置好對應(yīng)的x-dead-letter-exchange，x-dead-letter-routing-key。為了簡單說明，我使用默認(rèn)的exchange，那么配置如下：

x-dead-letter-exchange=“”
x-dead-letter-routing-key=“ARRIVAL_STAT”

意思是，消息當(dāng)這個隊列DELAY_ARRIVAL_STAT的消息變死信之后，就會帶著routing key “ARRIVAL_STAT”發(fā)送默認(rèn)的空exchange，即隊列ARRIVAL_STAT。

并且這個隊列不能有消費者消費消息。

這樣我們就實現(xiàn)了消息的死信轉(zhuǎn)發(fā)。下一步，只需要讓消息在這個DELAY_ARRIVAL_STAT在30分鐘后過期變死信即可。按照上文所說，有兩種方法，我們可以為隊列的消息設(shè)置30分鐘TTL，或者發(fā)送消息的時候指定消息的TTL為30分鐘即可。

示例如下：

“延遲隊列”的堵塞缺陷

由于設(shè)置了x-dead-letter-exchange的隊列本身也是普通隊列，其過期的順序是按照隊列頭部順序的過期的。也就是說，如果你隊列頭的消息A過期時間是5分鐘，后面對這個隊列發(fā)送消息B的帶著過期時間1分鐘，那么后面的隊列B要等隊列A過期了才會觸發(fā)過期：

Queues that had a per-message TTL applied to them retroactively (when they already had messages) will discard the messages when specific events occur. Only when expired messages reach the head of a queue will they actually be discarded (or dead-lettered).

所以，對于此類多延遲時間的，可以考慮設(shè)置多級延遲隊列。例如1分鐘，5分鐘，10分鐘，20分鐘這樣多級的延遲隊列，使得延遲相近的盡量放到同一個隊列中減少擁堵的最壞情況。