這篇文章將為大家詳細講解有關(guān)rabbitMq中延時機制的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名注冊、虛擬主機、營銷軟件、網(wǎng)站建設(shè)、吉安網(wǎng)站維護、網(wǎng)站推廣。

一： TTL機制

TTL機制其實就是給隊列 或者 消息設(shè)置過期時間，因為中間件的容量和堆積能力有限，有一些消息長時間消費不了，可使用過期來刪除。 用法如下：

1. 通過Queue屬性設(shè)置，隊列中所有消息都有相同的過期時間-單位毫秒。

2. 對消息自身進行單獨設(shè)置，每條消息的TTL 可以不同。

**二：死信隊列 **

死信隊列用來存放普通隊列中不能正常消費的消息，如超時的，拒絕的，返回nack的等…

普通隊列綁定了死信交換機就是死信隊列； 而死信交換機也是普通交換機，只是在別的隊列聲明屬性中，有個屬性叫做：x-dead-letter-exchange，它的value指定的交換機，就成了死信交換機。 具體如圖示：

當(dāng)消息過期后，就會根據(jù)指定的routingKey發(fā)送到交換機，最終根據(jù)綁定key路由到死信隊列。

三：應(yīng)用場景

明白以上的TTL和死信隊列后，我們可以做什么呢？ 比如，電商系統(tǒng)，用戶下了一個訂單后需要支付，支付時間為15分鐘，超時后將訂單的未支付改為已取消，該怎么做呢？

做法一： 使用定時任務(wù)不斷去掃描數(shù)據(jù)庫中未支付的訂單，看創(chuàng)建時間和當(dāng)前時間是否大于15分鐘，如果是改為已取消。

問題來了： 如果訂單表數(shù)據(jù)量很大，頻繁掃描會帶來性能問題。  如果不夠頻繁，誤差又會很大，不能及時更新狀態(tài)。

做法二： 比如TTL和死信隊列，生成訂單后往mq發(fā)送一條消息（不去消費它），設(shè)置15鐘過期，15分鐘后發(fā)送到死信隊列，監(jiān)聽死信隊列的消費端拿到消息后，去查詢訂單，如果還是未支付，則改為已取消。

四：延遲隊列

延遲隊列其實就是TTL和死信隊列的變相，只不過上面是把消息存在隊列里實現(xiàn)過期，延遲隊列是基于插件rabbitmq_delayed_message_exchange，把消息先發(fā)到x-delayed-message exchange延時交換機，到時間后再發(fā)送到隊列。

此插件需要去下載，用法這里不作描述了。

關(guān)于“rabbitMq中延時機制的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。