當RabbitMQ發佈消息速度快於消費速度或者系統資源不足時，RabbitMQ將降低或阻斷髮布消息速度，以免服務器資源飽滿而宕機，可以通過rabbitmqctl和web管理頁面查看連接的狀態爲flow，當服務器資源不足時，連接會被blocked。連接被流控後和正常使用沒有什麼區別，體現可網絡帶寬不足情況一樣。這個流控不需要配置RabbitMQ默認處理流控。
流控主要有一下幾個情況：
1.內存控制
RabbitMQ服務器在啓動時會計算系統內存總大小。然後會根據vm_memory_high_watermark參數指定的百分比，進行控制.可通過命令 rabbitmqctl set_vm_memory_high_watermark fraction 動態設置。默認下，vm_memory_high_watermark的值爲0.4,當RabbitMQ使用的內存超過40%時，系統會阻塞所有連接。一旦警報解除（消息被消費者取走，或者消息被寫到硬盤中）,系統重新恢復工作。32位系統的單進程內存使用最大爲2G,即使系統有10G,那麼內存警報線爲2G*40%.
在日誌中可以找到內存限制的相關信息
例如 ：/var/log/rabbitmq/
=INFO REPORT==== 28-Apr-2015::14:11:16 ===
Memory limit set to 3804MB of 7609MB total.
當vm_memory_high_watermark爲0時，不再有內存警報。並且所有的消息發佈都將停止。這個方法可用來，如果要禁止消息發佈的情況。
2.硬盤控制
當RabbitMQ的磁盤空閒空間小於50M（默認），生產者將被BLOCK，並且阻塞信息發佈前，會嘗試把內存中的信息輸出到磁盤上。持久化信息和非持久化信息都將被寫到磁盤（持 久化信息一進入隊列就會被寫到磁盤）。如果採用集羣模式，磁盤節點空閒空間小於50M將導致其他節點的生產者都被block。可以通過disk_free_limit來對進行配置。
如果磁盤的預設值爲50%，內存預設值默認是0.4，那麼就是當內存使用量達到20%時，隊列信息會被寫到磁盤上。
可以通過設置 vm_memory_high_watermark_paging_ratio （默認值爲0.5）來改變寫入磁盤的策略，例如：
[{rabbit, [{vm_memory_high_watermark_paging_ratio, 0.75}, {vm_memory_high_watermark, 0.4}]}].上面的配置將會在內存全用30%時將隊列信息寫入到磁盤，阻塞信息發佈是在內存使用40%時發生。建議vm_memory_high_watermark 不超過50%.
3.消息積壓
在RabbitMQ中，消息可能被存儲在多個不同的隊列，消息越早被消費，那麼消息經過的隊列層次越少，則平均每個消息處理的開銷就越小。但若發佈消息的速率過快，MQ來不及處理，這些消息就可能進入很深層次的隊列，大大增加平均每個消息的處理開銷，進一步使得處理新消息和發送舊消息的能力減弱，更多的消息會進入很深的隊列，循環往復，整個系統的性能就會極大的降低。另外若接收消息的速率過快還會實現某些進程的mailbox過大，可能會產生很嚴重的後果。爲此，RabbitMQ設計了一套流控機制。
RabbitMQ 使用了一種基於 credit 的算法來 限制 message 被 publish 的速率 。Publisher 只有在其從某個 queue 的 全部鏡像處收到 credit 之後才被允許繼續 publish 。在這個上下文中，Credit 意味着對 publish 行爲的允許。如果存在沒能成功發送出 credit 的 slaves ，則將導致 publisher 停止 publish 動作。Publisher 會一直保持停止的狀態，直到所有 slave 都成功發送了 credit 或者直到剩餘的 node 都認爲某 slave 已經從 cluster 中斷開了。Erlang 會週期性地發送 tick 到所有的 node 上來檢測是否出現連接斷開。 tick 的間隔時間可以通過配置 net_ticktime 的值來控制。
參考文章:
1.Memory and Disk Alarms
2.Blocked Connection Notifications
3.RabbitMQ進程結構分析與性能調優
4.通過流控機制分析rabbitmq性能（持久化）瓶頸
5.RabbitMQ中對Erlang進程的授信機制
6.消息隊列RabbitMQ和ActiveMQ的生產者流量控制