什麼是消費端的限流?
假設一個場景，首先，我們Rabbitmq服務器有上萬條未處理的消息，我們隨便打開一個消費者客戶端，會出現下面情況:
巨量的消息瞬間全部推送過來，但是我們單個客戶端無法同時處理這麼多數據!
RabbitMQ提供了一種qos (服務質量保證)功能，即在非自動確認消息的前提下，如果一定數目的消息(通過基於consume或者channel設置Qos的值)未被確認前，不進行消費新的消息。
void BasicQos(uint prefetchSize, ushort prefetchCount, bool global);
- prefetchSize:0
- prefetchCount:會告訴RabbitMQ不要同時給一個消費者推送多於N個消息，即一旦有N個消息還沒有ack,則該consumer將block掉，直到有消息ack
- global: true\false 是否將上面設置應用於channel,簡單點說，就是上面限制是channel級別的還是consumer級別
注：prefetchSize和global這兩項，rabbitmq沒有實現，暫且不研究prefetch count在no ask= false的情況下生效，即在自動應答的情況下這兩個值是不生效的。並且千萬不要使用AutoACK。一定要使用手動ack
消費端的手工ACK和NACK
消費端進行消費的時候，如果由於業務異常我們可以進行日誌的記錄，然後進行補償!
如果由於服務器宕機等嚴重問題,那我們就需要手工進行ACK保障，消費端消費成功!
消費端的重回隊列
消費端重回隊列是爲了對沒有處理成功的消息，把消息重新會遞給Broker!
一般我們在實際應用中，都會關閉重回隊列，也就是設置爲False。
TTL
- TTL是Time To Live的縮寫，也就是生存時間
- RabbitMQ 支持消息的過期時間，在消息發送時可以進行指定
- RabbitMQ 支持隊列的過期時間，從消息入隊列開始計算，只要超過了隊列的超時時間配置，那麼消息會自動的清除
死信隊列 DLX, Dead-Letter-Exchange
利用DLX,當消息在一個隊列中變成死信(dead message)之後,它能被重新publish到另一個Exchange, 這個Exchange就是DLX
- DLX也是一個正常的Exchange,和一-般的Exchange沒有區別，它能在任何的隊列上被指定，實際上就是設置某個隊列的屬性。
- 當這個隊列中有死信時，RabbitMQ就會 自動的將這個消息重新發布到設置的Exchange_上去，進而被路由到另一個隊列。
- 可以監聽這個隊列中消息做相應的處理，這個特性可以彌補RabbitMQ3.0以前支持的immediate參數的功能。
消息變成死信有以下幾種情況：
- 消息被拒絕(basic.reject/basic.nack) 並且requeue=false
- 消息TTL過期
- 隊列達到最大長度