1 消息過載

假設RabbitMQ伺服器有上萬條未處理消息，随便打開一個消費端，會造成巨量消息瞬間全部推送過來，然而我們單個用戶端無法同時處理這麼多資料。

還比如說單個Pro一分鐘産生了幾百條資料，但是單個Con一分鐘可能隻能處理60條，這時Pro-Con不平衡。通常Pro沒辦法做限制，是以Con就需要做一些限流措施，否則如果超出最大負載，可能導緻Con性能下降，伺服器卡頓甚至崩潰。

是以，我們需要Con限流。

2 Con限流機制

RabbitMQ提供了一種qos (服務品質保證)功能，在非自動确認消息的前提下，若一定數目的消息 (通過基于Con或者channel設定Qos的值) 未被确認前，不消費新的消息。

不能設定自動簽收功能(autoAck = false)

如果消息未被确認，就不會到達Con，目的就是給Pro減壓

QoS
大廠如何用RabbitMQ做消費端限流（上）1 消息過載2 Con限流機制
請求特定設定“服務品質（quality of service）”。這些設定強加資料的伺服器将需要确認之前，為消費者發送的消息數量限制。是以，他們提供消費者發起的流量控制的一種手段。
大廠如何用RabbitMQ做消費端限流（上）1 消息過載2 Con限流機制

void BasicQos(uint prefetchSize, ushort prefetchCount,
                bool global);

prefetchSize: 單條消息的大小限制，Con通常設定為0，表示不做限制

prefetchCount: 一次最多能處理多少條消息

global: 是否将上面設定true應用于channel級别還是取false代表Con級别

prefetchSize和global這兩項，RabbitMQ沒有實作，不研究

prefetchCount在 autoAck=false 的情況下生效，即在自動應答的情況下該值無效，是以必須手工ACK。

void basicAck(Integer deliveryTag，boolean multiple)

調用該方法就會主動回送給Broker一個應答，表示這條消息我處理完了，你可以給我下一條了。參數multiple表示是否批量簽收，由于我們是一次處理一條消息，是以設定為false。