公司一個生產(chǎn)項(xiàng)目骂维，重度使用了多層混合MQ來作為異構(gòu)系統(tǒng)和微服務(wù)間的數(shù)據(jù)流轉(zhuǎn)稀轨，大概結(jié)構(gòu)如下圖：
1填物、C++模塊負(fù)責(zé)產(chǎn)生原始數(shù)據(jù)冰单，并推入ActiveMQ中（為什么不統(tǒng)一使用RabbitMQ幌缝，因?yàn)樵写a牽涉較多，不宜亂動诫欠，相信很多人有這樣的經(jīng)歷吧）涵卵；
2、JAVA模塊1作為ActiveMQ的消費(fèi)者荒叼，將數(shù)據(jù)接收后進(jìn)行清洗后轿偎，再作為生產(chǎn)者發(fā)到RabbitMQ中；
3被廓、下級JAVA微服務(wù)作為RabbitMQ的消費(fèi)者坏晦，接收清洗后的數(shù)據(jù)后再做各自的業(yè)務(wù)處理。
RabbitMQ中主要使用了Fanout Exchange和Direct Exchange兩種交換機(jī)嫁乘，為什么使用Fanout Exchange昆婿，是因?yàn)椴糠謹(jǐn)?shù)據(jù)需要平行分發(fā)給多個處理模塊各自處理。
在平時的運(yùn)行中蜓斧，系統(tǒng)運(yùn)行平穩(wěn)仓蛆，源頭C++模塊推送的數(shù)據(jù)在2000-3000條/秒之間，下級各平臺也能正常的消化處理挎春。
但在某一天的某個時候看疙，ActiveMQ開始出現(xiàn)數(shù)據(jù)堆積，下層消費(fèi)者無法像往常的速率處理消息搂蜓。我們檢查了JAVA模塊1的運(yùn)行日志狼荞，發(fā)現(xiàn)與ActiveMQ的連接是正常的，接收到的數(shù)據(jù)也是正常的帮碰，觀察CPU相味、內(nèi)存、線程的情況也是正常的殉挽，但就是無法消費(fèi)ActiveMQ中的消息丰涉。那再向下檢查，發(fā)現(xiàn)往RabbitMQ推送的速率明顯變慢了斯碌，但是與RabbitMQ有關(guān)系的生產(chǎn)者模塊和消費(fèi)者模塊一死，沒有發(fā)現(xiàn)程序有出錯。在沒有辦法的情況下傻唾，只有嘗試將JAVA模塊1的部分實(shí)例進(jìn)行了重啟投慈，結(jié)果發(fā)現(xiàn)在重啟后一段時間已旧，消費(fèi)速度有短暫恢復(fù)授霸，但很快就無濟(jì)于事片排。
這下無計(jì)可施盯蝴，只有翻看RabbitMQ的管理UI，從中仔細(xì)翻查哪里有問題抱既。先是在連接管理界面翻查了一下职烧，發(fā)現(xiàn)有部分連接的狀態(tài)(state)變成了flow（以下圖片是后續(xù)重抓的，flow狀態(tài)已經(jīng)不存在了）防泵，由此懷疑是被限流了蚀之，再對應(yīng)具體IP和服務(wù)地址核對，果真就是這幾個服務(wù)被限流捷泞，導(dǎo)致了生產(chǎn)者無法達(dá)到有效的速率發(fā)送消息足删，并因此導(dǎo)致上游的ActiveMQ消費(fèi)者變慢。在JAVA模塊1中肚邢，對應(yīng)ActiveMQ的Listener壹堰，在接收消息后，會立即清洗并直接推送到RabbitMQ中骡湖，而在推送中被限流就讓消息無法處理，進(jìn)一步無法被ACK峻厚，導(dǎo)致消費(fèi)變得緩慢响蕴，就產(chǎn)生了上游ActiveMQ的消息堆積。
下圖是我從官網(wǎng)上截的部分圖惠桃，就是中間的flow浦夷，代表連接已經(jīng)被限流了。
在發(fā)現(xiàn)問題所在后辜王，我們再向下梳理劈狐，去RabbitMQ的UI中的Queue界面看一下，這里有個重要的參數(shù)：Consumer utilisation（消費(fèi)者利用率呐馆，我不知道自己翻譯是否正確肥缔，暫且這樣定義吧）?需要關(guān)注。在排序后汹来，發(fā)現(xiàn)有一個隊(duì)列的消費(fèi)者利用率不高续膳，只在50%上下。再看它綁定的交換機(jī)收班，就是上面JAVA模塊1發(fā)消息的Fanout Exchange坟岔，賓果，就是它了摔桦。?在無法馬上優(yōu)化代碼處理的情況下社付，實(shí)時增加了兩個實(shí)例，消費(fèi)者數(shù)量從50變成了150后，消費(fèi)者利用率慢慢從50%攀升到了100%鸥咖，同時也觀察到上游的ActiveMQ消息開始在不斷的減少纪隙。由此，算是解決了生產(chǎn)者性能緩慢的問題扛或，生產(chǎn)環(huán)境又變得平穩(wěn)正常了绵咱。
但是這中間的機(jī)制還不算是非常清楚，所以在優(yōu)化完代碼后熙兔，也去官網(wǎng)了仔細(xì)查了相關(guān)的資料悲伶，算是勉強(qiáng)弄清楚了RabbitMQ的限流機(jī)制。RabbitMQ的流控制機(jī)制不僅在連接上住涉，還會在通道和隊(duì)列上都可以處于流控制狀態(tài)麸锉，我遇到這個問題是下游隊(duì)列消費(fèi)者導(dǎo)致，所以上游生產(chǎn)者連接被限流舆声。根據(jù)官方論壇上的員工回復(fù)花沉，大概可能以下幾點(diǎn)會造成流控制：
1、隊(duì)列正在全力工作媳握，沒有什么空閑時間
2碱屁、隊(duì)列實(shí)際上還有與消費(fèi)有關(guān)的工作(這一句我還沒能理解他的意思，可能指隊(duì)列還在等待消費(fèi)者蛾找，或是消費(fèi)者本身還在消費(fèi)中娩脾？）
3、消息被消費(fèi)的速率沒有達(dá)到它們被生產(chǎn)的速率的110%
而大部分的情況下打毛，都是消費(fèi)者本身消費(fèi)性能較低柿赊，產(chǎn)生了較低的消費(fèi)者利用率，從而導(dǎo)致被限流幻枉。因此碰声，我們可以著重從消費(fèi)者的處理邏輯上下手，找出可以優(yōu)化的地方去解決熬甫，提高消費(fèi)者本身的處理性能胰挑。
但這里也有一個辦法，直接啟用自動ACK罗珍，或是異步處理洽腺，這樣就能先在短時間解決問題，但是又將面臨數(shù)據(jù)可能會丟失的問題了覆旱。
當(dāng)然RabbitMQ不止因?yàn)橄M(fèi)者引起原因限流蘸朋，還會當(dāng)RabbitMQ主機(jī)的CPU、內(nèi)存扣唱、硬盤I/O或空間消耗（這里主要硬盤資源主要是持久化的時候）達(dá)到一個閾值后藕坯，也會引起限流团南。所以在RabbitMQ的管理界面發(fā)現(xiàn)有相應(yīng)的硬件資源消耗得差不多的時候，就應(yīng)該引起注意了炼彪，避免因?yàn)橛布Y源導(dǎo)致限流吐根，整個性能迅速下降。而稍注意的是辐马，這里關(guān)于內(nèi)存的使用拷橘，目前官方默認(rèn)內(nèi)存流控閥值設(shè)置為0.4，即RabbitMQ 進(jìn)程內(nèi)存占用到系統(tǒng)總內(nèi)存的百分之四十生產(chǎn)者會發(fā)生流控喜爷。?
由于 RabbitMQ 是基于Erlang 開發(fā)冗疮，RabbitMQ 將每個隊(duì)列設(shè)計(jì)為一個 Erlang 進(jìn)程，Erlang 進(jìn)程GC也是采用分代策略檩帐，當(dāng)新老生代一起參與Major GC時术幔，Erlang虛擬機(jī)會新開內(nèi)存，根據(jù)root set將存活的對象拷貝至新空間湃密，這個過程會造成新老內(nèi)存空間同時存在诅挑，極端情況下，一個隊(duì)列可能短期內(nèi)需要兩倍的內(nèi)存占用量泛源，所以內(nèi)存流控閥值設(shè)置為0.4相對是一個比較安全的值拔妥，設(shè)置太高，有可能系統(tǒng)內(nèi)存被全部占用導(dǎo)致系統(tǒng)進(jìn)程 kill RabbitMQ進(jìn)程俩由，設(shè)置過低導(dǎo)致內(nèi)存使用率不高毒嫡。
