訊息佇列RabbitMQ和ActiveMQ的生產者流量控制

20120825 鄭昀

Q：MQ 們為什麼要做生產者流量控制？A：麻煩就在於：『像 Erlang 的虛擬機器實現和設計上都沒有阻止使用者往一個進程的訊息佇列裡扔訊息，當訊息的生產速度過快，超過進程的處理能力時，這些訊息就堆積起來，佔用越來愈多的記憶體，最終導致VM崩潰。』 Q：我為什麼要知道 MQ 在做生產者流量控制？A：當你發現自家的 Producers 動輒被掛起或被阻塞時，你要知道該調 Consumer 的消費速率，還是調 Memory Threshold of MQ 。 一，RabbitMQ 2.8.0+的流量控制

RabbitMQ 2.8.0+引入了一個新特性“internal flow control”。

至此 RabbitMQ 有三種流量控制：  1.1. Per-Connection Flow Control是面向每一個串連做的流量控制。即，RabbitMQ 會主動阻塞（Block）那些發布訊息太快的串連（Connections），無需做任何配置。如果串連被阻塞了，那麼它在 rabbitmqctl 控制台上會顯示一個blocked的狀態。RabbitMQ 的流量控制機制是基於信用證(Credit)的擁塞控制機制，後面鄭昀會在附錄A中列出這個古老控制機制的詳細介紹。  1.2. Memory-Based Flow ControlRabbitMQ 會在啟動時檢測機器的實體記憶體數值。預設當 MQ 佔用 40% 以上記憶體時，MQ 會主動拋出一個記憶體警告並阻塞所有串連（Connections）。你也可以通過修改 rabbitmq.config 檔案來調整記憶體閾值，預設值是 0.4，如下所示：

[{rabbit, [{vm_memory_high_watermark, 0.4}]}].

當 MQ 啟動時，該記憶體閾值也會寫入到  RABBITMQ_NODENAME.log 檔案裡，如下所示：

Memory limit set to 2048MB.

如果 MQ Server 不能識別你的系統，或者你在用 Windows 系統，那麼它會寫一個警告資訊到  RABBITMQ_NODENAME.log 檔案裡，如下所示：

=WARNING REPORT==== 29-Oct-2009::17:23:44 ===Unknown total memory size for your OS {unix,magic_homebrew_os}. Assuming memory size is 1024MB.

 

1.3. Disk-Based Flow Control預設情況，如果剩餘磁碟空間在 1GB 以下，RabbitMQ 主動阻塞所有的生產者。這個閾值也是可調的。  二，Apache ActiveMQ 的流量控制 2.1. ActiveMQ 的生產者流量控制的觸發條件有三個：

• 不管 mq 有無做持久化配置：
• ！ActiveMQ所使用的記憶體到達 memoryUsage 配置值，預設值64MB；
• 如果 mq 做了持久化配置：
• ！要開啟了useCache開關，表明要將持久化訊息緩衝起來以便快速存取，預設是True；
• ！緩衝在記憶體中訊息總位元組數到達 memoryLimit 配置值，預設值是1MB。

  2.2. 觸發之後會導致：生產者調用發送訊息函數時被Stuck（卡住）。（註：關鍵詞 activemq+stuck+producer  或 activemq+block+producer）   附錄A

一，基於信用證(Credit)的擁塞控制機制

1993年，ATM領域開始尋找一種可以動態分配頻寬並防止信元丟失的傳輸機制。因此提出了ABR（Available Bit Rate，可用位元速率）業務，ABR 不強制網路為其分配固定的頻寬，網路通過反饋資訊動態調整分配給每個 ABR 串連的頻寬。很多專家都投入到 ABR 業務的擁塞控制規範研究上。

基於 Credit 的方案由哈佛大學的H．T．Kung教授首先提出，採用鏈路級流控機制，以單一鏈路或虛電路VC作為基本的控制單位。每條鏈路有一個信元發送節點（可以是一個源端或一個交換節點）和一個接收節點（可以是一個交換節點或一個目的端系統），每個節點為每一條VC維持一個排隊隊列，信元接收端監視每條VC的排隊隊列長度，決定發送端可以發到VC上的信元數量（用信用證通知），信元發送端只能發送信用證值所允許的最大信元數量，如果只有一條VC，則信用證的值應足夠大，以充分利用鏈路的頻寬。一般來說，信用證值應滿足下列條件：信用證值大於等於 鏈路信元速率乘以鏈路來回程傳輸時延。

圖6-17 給出了基於信用證擁塞控制機制的基本工作原理。信元接收方首先發送信用證到信元發送方，通知可用的緩衝區容量，發送方收到信用證之後，就可決定發送的信元數量。 

它的最大缺點是實現複雜，在每一對相鄰的節點之間都需要維持這一信用證機制，同時也增加了信元的時延。

二，RabbitMQ 是如何?的

『實質上 RabbitMQ 就是通過監控每個進程的mailbox，當某個進程負載過高來不及接收訊息時，這個進程的mailbox就開始堆積訊息。

當堆積到一定量時，就會阻塞住上遊進程，讓其不得接收新訊息。從而慢慢上遊進程的mailbox也開始積壓訊息。

到了一定的量又會阻塞上遊的上遊的進程接收訊息，最後就會使得負責網路資料包接收的進程阻塞掉，暫停接收資料。

這就有點像一個多級水庫，當下遊水庫壓力過大時，上遊水庫就得關閉閘門，使得自己的壓力也越來越大，需要關閉更上遊的水庫閘門，直到關閉最最上遊的閘門。』——http://ybbct.iteye.com/blog/

參考資料1，http://www.rabbitmq.com/memory.html，RabbitMQ Flow Control2，http://hg.rabbitmq.com/rabbitmq-server/file/default/src/credit_flow.erl3，http://ybbct.iteye.com/blog/1562271，RabbitMQ流量控制機制簡單分析4，通過流控機制分析 RabbitMQ 效能（持久化）瓶頸5，http://activemq.apache.org/producer-flow-control.html6，http://working-with-activemq.blogspot.com/2012/05/performance-improvements.html 7，http://stackoverflow.com/questions/5291679/activemq-topic-flooding8，http://www.huaishao8.com/tag/activemq