rabbitmq提供了一種qos(服務質量保證)功能, 即在非自動確認訊息的前提下, 如果一定數目的訊息(通過consumer或者channel設定qos的值)未被確認前, 不進行消費新的訊息.自動簽收要設定成false, 建議實際工作中也設定成false
void basicqos(int prefetchsize, int prefetchcount, boolean global) throws ioexception;
prefetchsize : 訊息大小限制, 一般設定為0, 消費端不做限制
prefetchcount : 會告訴rabbitmq不要同時給乙個消費者推送多於n個訊息, 即一旦有n個訊息還沒有ack, 則該consumer將block(阻塞), 直到有訊息ack
global : true/false 是否將上面設定應用於channel, 簡單來說就是上面的限制是channel級別的還是consumer級別
備註:prefetchsize和global這兩項, rabbitmq沒有實現, 暫且不關注, prefetchcount在autoack設定false的情況下生效, 即在自動確認的情況下這兩個值是不生效的
//限流方式 每次只推3條
channel.
basicqos(0
,3,false);
// 設定channel autoack一定要設定為false,才能做限流
channel.
basicconsume
(queuename,
false
,new
myconsumer
(channel)
);
ack是確認成功消費, nack表示訊息處理失敗, 會重發訊息
消費端進行消費的時候, 如果由於業務異常我們可以進行日誌的記錄, 然後進行補償
如果由於伺服器宕機等嚴重問題, 就需要手工進行ack保障消費端消費成功
消費端手動簽收ack
// 手動簽收
channel.
basicack
(envelope.
getdeliverytag()
,false
);
消費端限流
什麼是消費端的限流 假設乙個場景,首先我們rabbitmq伺服器上面有上萬條沒有處理的訊息,我們隨便開啟乙個消費者客戶端,會出現下面情況 巨量訊息瞬間全部推送過來,但是我們當個客戶端沒有辦法進行處理這麼多的資料,可能會造成伺服器宕機。rabbitmq提供一種qos 服務質量保證 功能,即在非自動確認...
RabbitMQ 消費端的限流策略
假設乙個場景,由於我們的消費端突然全部不可用了,導致 rabbitmq 伺服器上有上萬條未處理的訊息,這時候如果沒做任何現在,隨便開啟乙個消費端客戶端,就會導致巨量的訊息瞬間全部推送過來,但是我們單個客戶端無法同時處理這麼多的資料,就會導致消費端變得巨卡,有可能直接崩潰不可用了。所以在實際生產中,限...
大廠如何用RabbitMQ做消費端限流
假設rabbitmq伺服器有上萬條未處理訊息,隨便開啟乙個消費端,會造成巨量訊息瞬間全部推送過來,然而我們單個客戶端無法同時處理這麼多資料。還比如說單個pro一分鐘產生了幾百條資料,但是單個con一分鐘可能只能處理60條,這時pro con不平衡。通常pro沒辦法做限制,所以con就需要做一些限流措...