C#實作rabbitmq 延遲隊列功能

最近在研究rabbitmq,項目中有這樣一個場景：在使用者要支付訂單的時候，如果超過30分鐘未支付，會把訂單關掉。當然我們可以做一個定時任務，每個一段時間來掃描未支付的訂單，如果該訂單超過支付時間就關閉，但是在資料量小的時候并沒有什麼大的問題，但是資料量一大輪訓資料庫的方式就會變得特别耗資源。當面對千萬級、上億級資料量時，本身寫入的IO就比較高，導緻長時間查詢或者根本就查不出來，更别說分庫分表以後了。除此之外，還有優先級隊列，基于優先級隊列的JDK延遲隊列，時間輪等方式。但如果系統的架構中本身就有RabbitMQ的話，那麼選擇RabbitMQ來實作類似的功能也是一種選擇。 我們項目中用到了rabbitmq，可以做一個延遲隊列完美的解決這個問題。

     rabbitmq本身不具有延時消息隊列的功能，但是可以通過TTL(Time To Live)、DLX(Dead Letter Exchanges)特性實作。其原理給消息設定過期時間，在消息隊列上為過期消息指定轉發器，這樣消息過期後會轉發到與指定轉發器比對的隊列上，變向實作延時隊列。利用rabbitmq的這種特性，應該有了一個大概的思路。、

網上搜了一下  rabbitmq-delayed-message-exchange 這個插件也可以實作延遲隊列的功能。今天介紹的是如何用C#來實作。

首先了解一下TTL和DLX 

消息的TTL就是消息的存活時間。RabbitMQ可以對隊列和消息分别設定TTL。對隊列設定就是隊列沒有消費者連着的保留時間，也可以對每一個單獨的消息做單獨的設定。超過了這個時間，我們認為這個消息就死了，稱之為死信。如果隊列設定了，消息也設定了，那麼會取小的。是以一個消息如果被路由到不同的隊列中，這個消息死亡的時間有可能不一樣（不同的隊列設定）。這裡單講單個消息的TTL，因為它才是實作延遲任務的關鍵。

Exchage的概念在這裡就不在贅述。一個消息在滿足如下條件下，會進死信路由，記住這裡是路由而不是隊列，一個路由可以對應很多隊列。

1. 一個消息被Consumer拒收了，并且reject方法的參數裡requeue是false。也就是說不會被再次放在隊列裡，被其他消費者使用。

2. 上面的消息的TTL到了，消息過期了。

3. 隊列的長度限制滿了。排在前面的消息會被丢棄或者扔到死信路由上。

Dead Letter Exchange其實就是一種普通的exchange，和建立其他exchange沒有兩樣。隻是在某一個設定Dead Letter Exchange的隊列中有消息過期了，會自動觸發消息的轉發，發送到Dead Letter Exchange中去。

 首先我建了兩個控制台項目一個是生産者，一個是消費者。

生産者代碼如下 

消費者代碼如下：

　　

效果 ：

在等待了12秒後消費者等到了消息。

 這樣我們就實作了延遲隊列的功能了。