1. 消息隊(duì)列如何限流？

消息隊(duì)列限流是指在服務(wù)器面臨巨額流量時(shí)，為了進(jìn)行自保，進(jìn)行的一種救急措施。

因?yàn)榫薮蟮牧髁看碇浅６嗟南ⅲ@些消息如果多到服務(wù)器處理不過(guò)來(lái)就會(huì)造成服務(wù)器癱瘓，影響用戶體驗(yàn)，造成不良影響。

所以要進(jìn)行一次降級(jí)操作，把處理不了的流量隔絕在系統(tǒng)之外，避免它們打垮系統(tǒng)。

基本上任何一個(gè)消息隊(duì)列都有限流的功能，今天我們就來(lái)看看在RabbitMQ之中進(jìn)行限流具體應(yīng)該怎么做？

RabbitMQ提供了一種QOS(服務(wù)質(zhì)量保證)功能，即在非自動(dòng)確認(rèn)消息的前提下，如果一定數(shù)目的消息還未被消費(fèi)確認(rèn)，則不進(jìn)行新消息的消費(fèi)。

我們只需要配置一下rabbitmq.listener.simple下的prefetch屬性即可，為了演示方便我這里配置為兩條，語(yǔ)義即為：如果隊(duì)列中有兩條以上未簽收的消息，則不進(jìn)行新的消息消費(fèi)。

我往我的隊(duì)列中發(fā)送三條信息，并不進(jìn)行簽收，來(lái)看看效果：

發(fā)送完顯示我們系統(tǒng)中有三條Ready消息，這代表這三條消息還在隊(duì)列中沒(méi)有消費(fèi)端去消費(fèi)。

這時(shí)我打開(kāi)消費(fèi)端進(jìn)行消費(fèi)但依舊不進(jìn)行簽收，接著來(lái)看效果：

unacked=2，ready=1，這就代表有兩條消息在服務(wù)端消費(fèi)了但是沒(méi)有簽收，還有一條消息還在隊(duì)列中沒(méi)有往服務(wù)端推送，因?yàn)槲覀冊(cè)O(shè)置了prefetch=2，所以現(xiàn)在隊(duì)列的最大同時(shí)在消費(fèi)的消息數(shù)量為2，通過(guò)此種方式，我們就完成了消費(fèi)限流。

Tip : 這種方式下消息一定要進(jìn)行手動(dòng)簽收，因?yàn)橹暗奈恼轮形覀冎v過(guò)，自動(dòng)簽收是消息一達(dá)到消費(fèi)端就進(jìn)行簽收了，可能我們的業(yè)務(wù)邏輯還沒(méi)運(yùn)行就已經(jīng)進(jìn)行簽收了，所以自動(dòng)簽收狀態(tài)下開(kāi)啟限流幾乎沒(méi)有作用。

2. RabbitMQ控制臺(tái)

上一節(jié)我的截圖中，大家可以發(fā)現(xiàn)居然出現(xiàn)了可視化的界面，以往在我的截圖中一般都是DOS命令操作臺(tái)界面，但其實(shí)RabbitMQ是自帶了可視化界面的插件的，我們只需要開(kāi)啟即可。

在我們的RabbitMQ中輸入如下命令：rabbitmq-plugins.bat enable rabbitmq_management

就可以開(kāi)啟可視化頁(yè)面了，緊接著訪問(wèn)：http://localhost:15672/

默認(rèn)用戶名和密碼都是 guest，直接登錄即可。

很方便的控制臺(tái)，大家可以自己試一下~

3. TTL消息/隊(duì)列

TTL是Time To Live的縮寫，也就是生存時(shí)間的意思，RabbitMQ支持消息的過(guò)期時(shí)間，在消息發(fā)送時(shí)可以進(jìn)行指定，也支持隊(duì)列的過(guò)期時(shí)間，從消息入隊(duì)列開(kāi)始計(jì)算，只要超過(guò)了隊(duì)列的超時(shí)時(shí)間配置，那么消息會(huì)自動(dòng)的清除。

設(shè)置隊(duì)列的話就是整個(gè)隊(duì)列的消息到時(shí)都會(huì)過(guò)期，設(shè)置消息的話就是單條消息到時(shí)自動(dòng)過(guò)期。

上面的代碼就是演示如何創(chuàng)建一個(gè)TTL隊(duì)列，需要放入?yún)?shù)才行，隊(duì)列構(gòu)造中的其他參數(shù)我為了方便直接填了false。

設(shè)置消息的TTL也是設(shè)置參數(shù)即可。

以上就是RabbitMQ中關(guān)于TTL的知識(shí)點(diǎn)。

4. DLX死信隊(duì)列

DLX死信隊(duì)列雖然叫隊(duì)列，但其實(shí)指的是Exchange，或者說(shuō)指的Exchange和它所屬的Queue，他倆一塊構(gòu)成了死信隊(duì)列。

當(dāng)一條消息：

• 消費(fèi)被拒絕（basic.reject/basic.nack）并且requeue=false

• TTL過(guò)期

• 要進(jìn)入的隊(duì)列達(dá)到最大長(zhǎng)度

這三種情況，就可以判定一條消息死了，這種消息如果我們沒(méi)有做處理，它就會(huì)被自動(dòng)刪除。

但其實(shí)我們可以在隊(duì)列上加上一個(gè)參數(shù)，使當(dāng)隊(duì)列中發(fā)現(xiàn)了死亡的消息之后會(huì)將它自動(dòng)轉(zhuǎn)發(fā)到某個(gè)Exchange，由指定的Exchange來(lái)處理這些死亡的消息。

這個(gè)處理死亡消息的Exchange和之前我們講述的Exchange沒(méi)什么區(qū)別，依然可以綁定隊(duì)列然后進(jìn)行消息消費(fèi)。

如上代碼，就是設(shè)置了一個(gè)隊(duì)列中的消息死亡后的去處，就等于消息死亡后給它不把它刪掉而是做一次轉(zhuǎn)發(fā)，發(fā)到其他Exchange去。

那這樣搞有什么用呢？這就取決于業(yè)務(wù)需求了，不過(guò)下一節(jié)會(huì)用到它，接著往下看~

5. 延時(shí)隊(duì)列

RabbitMQ的基因中沒(méi)有延時(shí)隊(duì)列這回事，它不能直接指定一個(gè)隊(duì)列類型為延時(shí)隊(duì)列，然后去延時(shí)處理，但是經(jīng)過(guò)上面兩節(jié)的鋪墊，我們可以將TTL+DLX相結(jié)合，這就能組成一個(gè)延時(shí)隊(duì)列。

設(shè)想一個(gè)場(chǎng)景，下完訂單之后15分鐘未付款我們就要將訂單關(guān)閉，這就是一個(gè)很經(jīng)典的演示消費(fèi)的場(chǎng)景，如果拿RabbitMQ來(lái)做，我們就需要結(jié)合TTL+DLX了。

先把訂單消息設(shè)置好15分鐘過(guò)期時(shí)間，然后過(guò)期后隊(duì)列將消息轉(zhuǎn)發(fā)給我們?cè)O(shè)置好的DLX-Exchange，DLX-Exchange再將分發(fā)給它綁定的隊(duì)列，我們的消費(fèi)者再消費(fèi)這個(gè)隊(duì)列中的消息，就做到了延時(shí)十五分鐘消費(fèi)。真是super~~~簡(jiǎn)單呢

后記

收尾了收尾了，RabbitMQ結(jié)束了，雖然有些東西沒(méi)有講比如：鏡像隊(duì)列，因?yàn)槲覜](méi)用過(guò)而且一般輪不到自己來(lái)做這個(gè)，所以就懶了一下就不寫這個(gè)了，RabbitMQ畢竟不是一個(gè)天生的分布式消息隊(duì)列，弄鏡像什么的還是有點(diǎn)麻煩的。

本文轉(zhuǎn)載自博客園：

https://www.cnblogs.com/he-erduo/p/13605911.html